Agent-first Billing: A Field Guide | Polar

How we’re building the most ambitious metering and billing engine for AI software.
Three ideas run through everything that follows. Every number comes from events, agents are customers like any other, and billing answers next to your code without waiting on Polar.
Every number Polar shows is computed from the events you send.
Usage is recorded as events and nothing else. Each one says who did what, when, and how much.
Meters, credit balances and invoice lines are all computed from the events, so there is no second count to drift out of sync.
Any number can be rebuilt from the events behind it, so a line on an invoice leads back to what happened.
Agents do the legwork, and people make the call.
Customers hold their agents, and every event says which one acted. Usage rolls up to whoever pays.
Agents in your editor, your chat or your own stack read usage and margins through Polar’s MCP server and draft changes. A draft is a branch, checked like any other change.
Someone on your team reviews the draft and approves it, or asks for another. Nothing reaches customers on its own.
Checks are answered next to your code, without waiting on the network.
Checks are answered by Outpost inside your app, from state kept in your own Redis. There is no round trip to Polar.
Outpost answers from the state it holds, so a slow or dropped connection never holds up a check.
Events flow to Polar in the background, and Polar’s numbers settle the local ones as they arrive.
The catalogue is a file. Products, prices, meters and entitlements are declared once, reviewed as a diff, and applied to an environment, so a pricing change goes through the same review as any other code.
A product is a file you review and apply.
A product’s events, meters and prices live in one typed file, beside the code that emits the events, and the types flow from the event schema to the meter to the price.
The file goes through the same pull request as everything else. A price change is a diff that a reviewer reads, and the build type-checks it against the schemas before anyone can apply it.
The CLI compares the file with what is deployed and applies the difference: new products and prices are created, changed ones updated, the rest left alone. The file stays the source of truth.
The CLI reads the file, shows the plan, asks, and applies it.
The CLI reads the file, computes the diff against what is deployed, and shows it before anything changes. The dashboard still works too, and the next plan picks up whatever was changed there.
On yes, it applies the plan. What is deployed then matches the file, and the next plan starts from there.
An unprofitable price fails the build.
Polar runs in your pipeline next to your tests. Every change to the billing definition is priced against what it costs to serve before it can merge.
Events carry their cost, so Polar knows what a million tokens on each model costs you. Here, the plan charges $2.00 and serving it costs $2.36.
That is 18% under water, below the 20% floor you set. The check fails and nothing is applied, the same as a failing test.
An event is a fact: at this time, this customer, through this actor, did this thing, this much. The event log only grows, and every usage number is derived from it.
Who did what, when, and how much.
The timestamp is when it happened, so a late event still lands in the right period.
The customer is who pays. The actor is who did it on their behalf: a teammate, an API key, or one of their agents.
The name says what happened, like llm.completion. Meters pick the events they count by name.
The metadata holds the numbers, like 3,120 input and 1,240 output tokens, in any shape you like. Meters add them up.
Append only. Events are added, never changed or removed.
The event log only grows. A new event is added to it, and nothing already in it is ever edited or deleted.
Every usage number, a meter reading, a credit balance, an invoice line, is computed from the event log, so it can be traced back to the events behind it.
An event counts at the time it happened.
Events can arrive late: a retry, a queue that backed up, a batch sent at the end of a job. Each carries the time it happened, and Polar uses that time.
A meter over the event log gives the same answer whether an event took a millisecond or a day to arrive. A late event slots into its place in time.
Model calls through an AI gateway are metered with no extra code.
If your model calls already go through an AI gateway, Polar connects to it and records every call as an event.