The bill arrives and a customer who expected forty dollars owes three hundred and forty. Another one burned their entire credit balance on three runs that failed and returned nothing useful. You pull the numbers and find your heaviest users are also your worst-margin accounts.
Usually the root cause is the same. Someone picked "per API call" early because it was the easiest thing to instrument. Easy to instrument and easy to understand are different problems, and only one of them shows up in a churn report.
Why does seat-based pricing break for agents?
Because an agent does not do the same amount of work twice. A traditional SaaS tool does roughly the same thing on every login. One agent run calls three tools and finishes in seconds. The next chains fifteen steps, hits three external APIs, and burns ten times the tokens. Same product, same seat, wildly different cost to serve.
That leaves two bad options under a flat rate. Absorb the variance and watch margins erode, or price for the worst case and lose everyone who is not the worst case.
Usage-based pricing is the model that maps to how the product actually consumes resources. But choosing usage-based pricing settles almost nothing. The real decision is which unit you meter, and that is a product decision no billing system can make for you.
Choosing the usage metric
The metrics available to most agent products trade off against each other in a fairly predictable way.
| Metric | Tracks cost | Customer can reason about it | Notes |
|---|---|---|---|
| Tokens | Closest to actual cost | Hardest | Customers cannot forecast token counts and do not want to learn |
| Messages | Loosely | Easy | Hides enormous variance between a one-line reply and a fifteen-step chain |
| Tasks or workflows | Moderately | Easy | Strongest alignment with what the customer is buying |
| API calls | Moderately | Fine for developers | Weak for business buyers who do not think in requests |
| Seats plus usage | Partially | Easy | Adds the predictability finance teams ask for |
The test that cuts through the table: when usage goes up, can you point to something concrete that got better for the customer?
If usage rose because they automated more work, that is a healthy signal and they will not resent the invoice. If it rose because your prompts got longer, retries increased, or a model upgrade made outputs chattier, they are paying more for the same outcome. Your metric should move when customers win, not when your infrastructure gets noisier.
Decide what you will not charge for
This is a credibility decision more than a pricing one, and it is worth making explicitly and early.
Do not bill for failed retries, system errors, model warmups, or internal orchestration. If your system caused the cost, you absorb it. Customers pay for usage they intended, not for cleanup work happening behind the scenes.
The reason to draw the line early is that it is very hard to draw later. Once a customer notices they were charged for a retry storm your service caused, the conversation is no longer about pricing.
Pick a structure your buyers and your board can both live with
Three structures cover most agent products.
Pay-as-you-go suits APIs and experimentation. Revenue is unpredictable, which is a real cost you pay for the low friction.
Base plus usage gives finance a floor and makes enterprise procurement much easier. Most sales-led motions land here.
Hybrid, meaning a platform fee with a metered layer on top, is the common shape for AI SaaS.
Two questions decide it. How much invoice variance can your buyer tolerate before they stop budgeting for you, and how much revenue volatility can your own business survive? A model that is honest about cost but leaves both sides unable to forecast is not a model either side keeps.
Making it real: from product event to billable unit
Once the strategy is settled, this becomes engineering work, and the failure mode is vagueness. Every billable unit should map to one concrete event in your system.
Define events like agent.run.completed, workflow.finished, or tool.executed. Avoid units like "interaction" or "session" that nobody can define twice the same way. The rule is simple: if a customer disputes a charge, you should be able to pull the exact events that produced it.
An event carries the customer, the unit, and the dimensions you might want to price or report on later:
{
"event_name": "agent.run.completed",
"external_customer_id": "cust_123",
"properties": {
"credits": 2,
"model": "gpt-4",
"workflow": "invoice-reconciliation"
},
"event_id": "run_8f21c",
"timestamp": "2025-08-22T07:05:49.441Z",
"source": "worker"
}
Two details do real work here. event_id is your own identifier, so a retried send deduplicates instead of double-charging, which matters because agent workers retry constantly. And properties carries dimensions you are not pricing on yet. Recording the model and the workflow costs nothing now and is the only way to answer "which workflows are unprofitable?" in six months.
Emitting it from a worker is one call on the path that already knows the result:
import os
import requests
def record_run(customer_id, run_id, credits, model, workflow):
response = requests.post(
"https://api.cloud.flexprice.io/v1/events",
headers={
"Content-Type": "application/json",
"x-api-key": os.environ["FLEXPRICE_API_KEY"],
},
json={
"event_name": "agent.run.completed",
"external_customer_id": customer_id,
"event_id": run_id,
"properties": {
"credits": credits,
"model": model,
"workflow": workflow,
},
"source": "worker",
},
)
return response.json()
Call it only on success. That is how "we do not charge for failed runs" stops being a policy in a document and becomes a property of the code.
Track cost drivers even when you do not bill on them
You may price on tasks. You are still exposed to tokens.
Track input tokens, output tokens, tool calls, embedding generation and storage, and background jobs. Then watch what happens to those numbers when you change a model or a prompt. A prompt tweak that improves quality can quietly double cost per run, and if you are not measuring at the model layer you will find out from a margin report a quarter later.
Recording cost dimensions in properties on the same event you already emit is the cheap way to do this. Flexprice's AI cost tracking documents the pattern for keeping per-model cost attached to the customer who caused it.
Guardrails before the spike, not after
AI traffic is bursty. One customer's automation loop can multiply volume overnight, and the two possible outcomes are a bill that destroys the relationship or a cloud invoice that destroys the quarter.
Layer the controls:
- Soft alerts at a usage threshold, delivered by email, Slack or in-app, while the workload continues.
- Hard caps that pause execution at a contracted ceiling.
- Internal anomaly detection for spikes that fit no configured threshold.
- Rate limits and loop-depth limits at the agent layer.
Thresholds have to be evaluated against streaming usage. A nightly job that notices an overage is a job that notices it too late. Spend alerts covers the threshold model, and configuring them per line item lets you alert on the specific workflow that ran away rather than the account total.
Entitlements and limits are different things
Entitlements define what a customer may do. Limits define how much.
Premium model access, background agents, elevated concurrency: those are entitlements, and they are product decisions enforced by billing. Monthly token caps and maximum concurrent runs are limits, and they are the safety rails.
Both need to be evaluated synchronously, before the expensive operation starts. When an agent picks up a job, the system should already know whether that customer is permitted to run it and whether they are inside budget. That means a centralized check your services call, not plan-name conditionals scattered across your codebase. Entitlement grants covers how access ties to plans without hardcoding it.
Give customers the numbers before the invoice does
If a customer first sees their usage on an invoice, you have designed a dispute into the product.
Live usage, broken down by agent, workflow or project, plus projected spend and configurable budget thresholds. AI-native buyers expect this the way they expect logs. Transparency here reduces support load and makes expansion conversations easier, because the customer already knows what they are using and why.
What the infrastructure actually has to do
Bolting usage pricing onto a subscription stack produces delayed data, confused customers, and a finance team reconciling spreadsheets at month end. The layer you need has to ingest events in real time, keep them queryable for audit and simulation, apply pricing rules that live outside your application code, enforce entitlements and limits synchronously, manage wallets and credits, and produce invoices with line items traceable to real consumption.
Vendors in this space differ mostly by how much of that list they cover. Metronome is a metering point solution built for engineers: it measures usage and leaves billing, invoicing and pricing iteration to other systems. Flexprice covers the full path, including invoicing, reporting and pricing experimentation, with pricing agility and simulations built in rather than bolted on. Orb handles straightforward self-serve usage pricing well, and the friction tends to appear once pricing and go-to-market motions get more complex, which is when teams move to an enterprise-ready billing platform.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.
In practice it sits between your product and your payment stack. You send raw usage events, agent runs, tokens, tool calls, background jobs. It aggregates them, applies your pricing rules, manages credits and limits, and produces invoice-ready output. Your services stop carrying monetization logic and start emitting facts.
Trials are a metering problem
Worth calling out because it is usually solved badly. A trial for an agent product should be metered usage with a hard cap, not a demo mode with fake data. Prospects need to run real workflows against real cost. A prepaid credit grant with an expiry does this cleanly, and it uses the same wallet primitive you already need for enterprise commitments. Prepaid and promotional credits covers the balance types and how they stack.
The rule worth keeping
Do not ship usage pricing until you can defend every charge with a product event, explain any invoice without hedging, and state what a marginal unit of usage does to both customer ROI and your own unit economics.
Teams that get this right treat pricing as part of the product architecture. They choose metrics that move with outcomes, exclude their own inefficiency from the bill, build guardrails before the first spike, and put the usage data in front of the customer continuously.
Getting started
The metering, entitlement and invoicing path is open source, so you can model your agent's event shape against it before committing to a pricing structure: docs.flexprice.io.
