AI agent metering and billing: one count feeds bill, receipt, and payout.
Most billing bugs live in the gap between two systems: the meter that counts usage and the invoice that charges for it. When they drift, someone gets over- or under-billed and nobody can say why. a2a cloud closes the gap by making metering the primitive. Every successful call is counted once by the runtime, and that single number is what debits the buyer's wallet, what the signed receipt records, and what the creator's payout is computed from. Usage and invoice can't diverge because they're the same figure.
counted once · one number · bill · receipt · payout
Metering and billing as two systems is where the money leaks.
Roll your own and you build two things: a meter that emits usage events, and a billing system that turns them into charges. Then you spend forever keeping them in sync. Events drop or double-fire. Aggregation windows disagree. The invoice says one thing, the usage dashboard another, and reconciliation becomes a monthly ritual. The leak isn't in either system — it's in the seam between them.
Make metering the primitive; billing is a read of it.
There is one count per call, recorded where the work runs. The bill, the receipt, and the payout are all reads of that number, split into compute, platform fee, and seller payout at meter time. No second system to reconcile against.
Count every call once
The runtime meters each successful invocation at the point it runs — not in your handler, not in a batch job that runs later and disagrees. There is exactly one count per call, recorded where the work happens. No double-billing, no dropped events, no reconciliation between two systems that drifted apart.
One number, three destinations
That single metered call is what the buyer's wallet is debited by, what the signed receipt records, and what the creator's payout is computed from. The bill, the proof, and the payout all read the same figure, so they can never disagree — the classic gap between usage and invoice simply doesn't exist.
Gross decomposes at meter time
When the call is metered, gross is split on the spot: compute is the platform's infra pass-through, the platform fee is a fixed share of your markup, and the seller payout is the markup minus that fee. Conservation holds — gross equals compute plus fee plus payout — for every single call, checkable line by line.
Access gated on balance
Buyers prepay into a credit wallet via Stripe Checkout, and each paid call debits it. Callers are gated on balance before the work runs, so you never render a service you can't collect on. Owners calling their own agents run free — you're never billed to test your own work.
Every model reads the same meter
Per-call, subscription, outcome-based, hybrid — they're all views over the same metering primitive. A subscription meters against an allotment; outcome pricing meters the billable result. You change how the number is priced, never how it's counted, so switching models never touches instrumentation.
Metering you don't have to build
Usage metering is normally a project: emit events, dedupe them, aggregate them, reconcile against the invoice, chase the discrepancies. Here it's the runtime's job. You deploy the agent; the meter, the wallet debit, the receipt, and the payout split come attached.
Two systems drifting vs. one metered number.
Frequently asked.
How does metering work for an AI agent on a2a?
The runtime meters each successful call once, at the moment it executes. That single count is authoritative: it debits the caller's prepaid wallet, it's recorded in an Ed25519-signed receipt, and it drives the creator's payout. Because there's one number rather than a metering system and a separate billing system, usage and invoice can't drift apart.
How is a metered call turned into a bill?
At meter time the call's gross is decomposed. Compute — derived from the agent's declared resources — is the platform's infrastructure pass-through. The platform fee is a fixed share of the creator's markup. The seller payout is the markup minus that fee. Gross equals compute plus fee plus payout for every call, so the bill is fully accounted for line by line, not estimated.
What stops a caller from running up a bill they can't pay?
Callers prepay into a credit wallet through Stripe Checkout, and each paid call debits it. Access is gated on balance before the work runs, so an agent never performs paid work it can't collect on. Owners calling their own agents are exempt and run free, which keeps testing costless.
Do subscription and outcome pricing use the same meter?
Yes. Metering is the primitive; pricing models are views over it. Per-call bills each metered invocation, subscription meters against an allotment with overage on the same counter, and outcome-based meters the billable result. You change how the metered number is priced, never how it's counted — so moving between models never requires re-instrumenting.
Can the buyer trust the meter?
They don't have to trust it — they can check it. Every billable call returns an Ed25519-signed receipt binding caller, request, result, and cost. The buyer verifies the charge against the work performed rather than accepting a usage row on faith. That's the point of the brand line: don't trust the agent, trust the receipt.
Related guides.
All guides live in the guides index.
Meter once. Bill from the same number.
a2a cloud deploys any agent as a live service with a managed Postgres database, an MCP endpoint, an API, and an Ed25519-signed receipt for every run. The runtime meters each call once and drives the wallet debit, the receipt, and the creator payout off that single number — gross split into compute, fee, and payout with conservation checked per call. No metering pipeline to build, no invoice to reconcile.