Last year we argued that billing must be open source, and the case was about your team: billing logic spreads across your stack, migrations become projects, and closed systems slow down how fast you can change your pricing.
A year on, a lot of billing code is being written by coding agents, and there is a second argument we did not make. Open source does not make an agent smarter. It makes an agent checkable, and in billing that is the only thing that matters.
Agents are confident about billing in a way billing does not reward
Ask an agent to wire up metered billing against a popular closed API and you will get code that looks right. It will use real-sounding method names, plausible parameter shapes, and a comment explaining the proration logic.
Some of it will be from the current API. Some of it will be from a version that changed two years ago, reconstructed from blog posts and Stack Overflow answers in the training data. The agent cannot tell you which is which, because from the inside both feel identical.
That failure mode is survivable in most domains. A summarizer that gets 2% of a paragraph wrong produces a slightly worse paragraph. Metering that gets 2% wrong produces a revenue restatement, a support queue, and a finance team that no longer believes your numbers.
Billing is one of the few places in a product where plausible output is worth nothing.
What open source actually changes
Four things, in rough order of how much they matter.
1. The agent reads the implementation instead of recalling the docs
Billing behaviour lives in the edge cases. What happens to a balance when a subscription is cancelled mid-cycle and then reinstated. Which grant drains first when two expire on the same day. How a mid-cycle plan change prorates against usage that was already metered.
Documentation describes the happy path, because that is what documentation is for. The source describes all of it, including the branch someone added after a production incident in 2023.
With the source in the repo, an agent greps. Without it, an agent remembers. Those are very different reliability profiles.
2. You can run it locally, so the agent gets a real feedback loop
This is the one that changes outcomes most, and it is worth being concrete about why.
An agent is only as good as the loop it can close. Give it a failing test and a command to run and it will iterate until the test passes. Give it an API it can only describe and it will produce something that compiles and stop, because there is nothing left for it to check against.
A self-hostable meter gives you a loop. The agent can start the stack, ingest synthetic usage events, run a billing cycle, and compare the generated invoice against an expected one. When the number is wrong it can change the meter definition and run it again.
That is the difference between an agent writing billing code and an agent verifying billing code.
3. The types and the spec are a contract the agent cannot argue with
We moved our API definitions to TypeSpec to generate clients, types and validators from one source. The side effect in the agent era is that a generated client turns a category of hallucination into a compile error.
An agent that invents a field name gets a red squiggle instead of a silent bug that surfaces on the first invoice of the month.
4. You can answer "why is this invoice $4,182.19?"
Finance asks this. Auditors ask this. Your largest customer asks this on a call where you would prefer to have an answer.
An agent working against open source can trace the number: the events that were ingested, the meter that aggregated them, the rate card that priced them, the grants that drained in which order. Against a closed system the best it can do is report what the API returned, which is not an explanation. It is the same number again, restated.
This matters more as agents do more of the investigating. An agent that can only read outputs cannot debug a billing discrepancy. An agent that can read the aggregation can.
The honest limits
Open source is not a free upgrade and it would be dishonest to sell it as one.
More code to read is more context to spend. An agent pointed at a large codebase with no guidance wanders. Point it at the specific packages that matter, the spec, and the test suite, rather than at the repository root.
The agent can now break things that used to be somebody else's problem. A self-hosted stack it can start is also a stack it can misconfigure. Keep the loop in a sandbox with disposable state.
Reading source is not the same as understanding intent. The source tells the agent what the system does. It does not say which of two correct behaviours your finance team expects. That part is still a conversation with a human.
How we would set it up
If you are pointing a coding agent at billing work, this is the setup that has worked for us:
- Vendor or submodule the source so the agent can read it in-repo rather than fetching pages. Grep beats recall.
- Point it at the API spec, not the marketing docs. The spec is the contract.
- Run the stack locally in the agent's sandbox, with throwaway state, so it can ingest events and close a billing cycle without touching anything real.
- Write the assertion first. Not "implement usage-based billing" but "given these 400 events and this rate card, the invoice total is $X, with these line items." An agent with a number to hit behaves completely differently from an agent with a description to satisfy.
- Make the invoice the test. Billing is correct or it is not. The invoice is the only assertion that covers metering, aggregation, entitlements, grants and pricing at once.
Point 4 is the whole post, really. The reason open source helps is that it lets you hand the agent a checkable claim instead of a description of intent. Everything else follows from that.
OpenMeter is Apache 2.0 and self-hostable, which is why we keep writing about this. But the argument is not about us. If you are building billing with an agent, the question to ask about any component is simple: can the agent close a loop against it, or can it only describe it?
