the metric
DIY meter
Log usage in your handler, then hope the export matches what you invoiced.
a2a
Each successful Agent API paid call creates one receipt-linked economics record.
metered once, billed once
Usage-based billing for AI agents: execution and economics, linked.
Usage-based billing works when each charge resolves to a real run without blurring what was cryptographically signed. The authenticated Agent API checks known buyer credit before execution, then the control plane signs and persists successful run evidence and stores native per-call economics in a separate row keyed to that receipt ID.
meter once · debit a balance · reconcile to receipts
0×
meter per call
0
counters to reconcile
0%
calls with a receipt
the problem
Hand-rolled metering drifts from the invoice.
The hard part of usage-based billing is not deciding to charge per unit — it is making the meter and the invoice agree. Teams instrument usage in the handler, pipe events to a billing system, and then spend the month reconciling the two. Retries double-count, dropped events under-count, and by the invoice date nobody is sure which number is true. Meanwhile the usage was already served, so anything you can't collect is written off.
An app-side counter and a billing-side counter diverge silently over time.
Retried or duplicated calls double-count unless you dedupe events by hand.
Dropped metering events under-count, and you bill less than you served.
Usage is served before payment, so uncollected usage becomes a write-off.
the a2a way
One verified run, two records that reconcile.
The Agent API checks known credit before paid work; after success, the control plane signs execution facts and writes one idempotent economics entry per receipt ID. Invoices and money fields remain in the billing layer.
One native Agent API billing recordCost you can decomposeChecked before work, debited after successIdempotent debitsReceipt and line item stay separateNative per-call, external alternatives
One native Agent API billing record
Each successful authenticated Agent API paid call creates one receipt-linked economics record and one idempotent debit. Public `/invoke` and standard MCP gateway executions remain signed evidence with zero platform economics.
Cost you can decompose
The control plane stores platform compute derived from declared resources plus the price_per_call_usd markup. That gross-cost breakdown lives in a ledger row keyed to the verified receipt ID, not in the signed receipt payload.
Checked before work, debited after success
For authenticated Agent API paid calls, the control plane checks a non-owner buyer's known credit before execution. It signs and persists the successful run, then applies an idempotent debit by receipt ID. Direct gateway receipts record zero economics.
Idempotent debits
Each ledger row is keyed to a verified receipt ID, so ingesting the same receipt twice does not duplicate the debit. A retry that actually executes again produces a new receipt and can be billed as a separate run.
Receipt and line item stay separate
The control plane signs and persists evidence for authenticated Agent API paid calls. The credit ledger stores cost and payout separately and links them by receipt ID. An invoice can reference both records, but its amount is not covered by the execution signature.
Native per-call, external alternatives
The agent card natively supports price_per_call_usd. Subscription, outcome-based, and hybrid pricing require an external billing and entitlement layer, which may consume a2a's receipt-linked usage rows as inputs.
side-by-side
Hand-rolled metering vs. usage-based billing on a2a.
drift
DIY meter
Two counters — app-side and billing-side — quietly diverge over a month.
a2a
One Agent API receipt ID links the signed execution record to its separate charge.
retries
DIY meter
Duplicate ingestion creates duplicate billing events unless you dedupe them.
a2a
One verified receipt ID creates one row; a newly executed retry has a new receipt.
collection
DIY meter
Meter now, chase payment later, write off what you can't collect.
a2a
Known-credit preflight before Agent API paid work; idempotent debit after success.
audit
DIY meter
Usage reports the customer has to take on faith.
a2a
Signed execution evidence and the separate economics row reconcile by receipt ID.
dimension
DIY meter
a2a
the metric
Log usage in your handler, then hope the export matches what you invoiced.
Each successful Agent API paid call creates one receipt-linked economics record.
drift
Two counters — app-side and billing-side — quietly diverge over a month.
One Agent API receipt ID links the signed execution record to its separate charge.
retries
Duplicate ingestion creates duplicate billing events unless you dedupe them.
One verified receipt ID creates one row; a newly executed retry has a new receipt.
collection
Meter now, chase payment later, write off what you can't collect.
Known-credit preflight before Agent API paid work; idempotent debit after success.
audit
Usage reports the customer has to take on faith.
Signed execution evidence and the separate economics row reconcile by receipt ID.
questions
Frequently asked.
What is usage-based billing for an AI agent?
It charges the buyer per invocation rather than as a flat fee. On a2a cloud, authenticated Agent API paid calls check known credit before execution. A successful run anchors persisted signed evidence and a separate ledger row containing declared per-call markup, derived compute, fees, payout, and debit. Invoices are generated separately.
How is usage metered without me instrumenting it?
Declare price_per_call_usd on the agent card. For authenticated non-owner Agent API paid calls, the platform derives the quoted gross from declared resources and markup, checks known credit before execution, then writes one receipt-linked debit and economics row after success. Direct gateway routes record zero economics.
Won't retries or duplicate requests double-charge?
Duplicate ingestion of the same verified receipt ID is idempotent and does not create a second ledger row. That is not the same as retrying execution: if the agent runs again and produces a new receipt, the retry is a separate billable invocation.
How does the customer verify a usage charge?
For each authenticated Agent API billable call, the control plane signs and persists caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing. The charge is stored separately in the ledger. A customer can reconcile the two by receipt ID, but the receipt signature does not authenticate the amount.
Can I switch pricing models later?
The agent card natively supports only price_per_call_usd. You can build subscription, outcome-based, or hybrid offers with an external billing and entitlement service and feed it a2a usage records where useful, but those are not pricing modes you switch on in the agent card.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Sign the run. Bill from the linked ledger.
a2a cloud deploys any agent with managed Postgres, MCP, and an API. Declare price_per_call_usd for authenticated Agent API paid calls, whose post-run economics live in separate receipt-linked rows. Public `/invoke` and standard MCP gateway receipts carry zero platform economics.