AI Agent Pricing: Usage-Based Models for AI Agents and API Calls

Usage-based pricing for AI agents means charging by tokens, tool calls, or resolved outcomes instead of a seat or a flat fee. In practice, AI agent pricing comes down to picking a unit that reflects cost and value together, then metering it accurately enough to bill on. Get the unit wrong and you either bleed margin on every heavy user or price out the customers who'd become your best ones.

Why flat pricing breaks first for agents

A SaaS seat costs roughly the same to serve whether someone logs in once a day or fifty times. An AI agent doesn't work that way. A support agent that resolves a hard ticket might burn 40,000 tokens across a dozen tool calls and three model retries; the same agent resolving a one-line question might burn 400. Charge both the same flat fee and you're either overcharging the easy case or losing money on the hard one, and your heaviest, most successful customers are exactly the ones costing you the most to serve. That's the core reason token-based and usage-based pricing showed up in AI products years before they became standard everywhere else: the underlying cost structure is usage-shaped, so the price has to be too.

Even seat-based AI products end up backing into usage limits for this reason. Cursor's $20/month Pro plan and $40/user/month Business plan are nominally per-seat, but both are gated by "Agent request" limits underneath, because a flat seat price can't absorb the cost spread between a light user and someone running agents constantly.

Picking the billing unit: tokens, calls, or outcomes

There are three broad places to draw the line, and each trades accuracy for simplicity differently.

Tokens are the most cost-accurate unit because they map almost directly to what you pay the model provider. They're also the least intuitive to a buyer: nobody outside an ML team has real intuition for what 100,000 tokens buys them, which is why most consumer-facing and mid-market products translate tokens into an abstracted credit behind the scenes rather than billing raw token counts directly.

API calls or tool invocations are easier to explain and easier to cap, but they compress a wide range of actual cost into one unit. A single tool call that triggers a 200-token lookup and one that triggers a 50,000-token multi-step reasoning chain both count as "one call," which means your pricing and your cost curve start to diverge as agents get more complex.

Outcomes (a resolved ticket, a completed booking, a generated report) are the unit customers actually want to pay for, since it's the closest thing to value rather than effort. It's also the hardest to define cleanly and the hardest to bill on with certainty, since "resolved" often needs a business rule, a confirmation step, or a time window before it counts.

Most mature AI pricing models end up blending these. It's why coding agents increasingly price on a hybrid: a flat monthly base plus a metered unit underneath it, similar in shape to a subscription with committed credits and overage, rather than picking tokens, calls, or outcomes exclusively.

Metering the parts a flat plan can't see

Whatever unit you pick, it only works if the metering underneath it is accurate at the level of an individual agent run, not just a monthly aggregate. That means capturing, per event: which customer or workspace triggered it, which model and provider handled it, prompt and completion tokens broken out separately (since providers price them differently), which tools or sub-agents were invoked, and whether the run succeeded, retried, or failed, the same job billable metrics and usage event ingestion are built to do. Multi-step agents make this harder than a single API call ever was, because one user action can fan out into a dozen billable sub-events across multiple providers, and if you're not deduplicating and attributing all of them correctly, you're either billing customers for your own retries or eating the cost of a failed run silently. This is the same problem metered billing solves for usage-based pricing generally, agents just generate the events faster and in more places at once.

The pitfalls that show up after launch, not before

Three mistakes account for most of the post-launch pricing pain teams run into.

The first is billing for retries and failures. If your agent calls a model three times because of a rate limit or a malformed response, and you're metering every call regardless of outcome, you're charging the customer for your own infrastructure's flakiness. Decide up front whether failed attempts are on you or on them, and meter accordingly.

The second is ignoring provider price changes. Every major model provider has repriced, deprecated a model tier, or changed its token-counting method at least once in the past year. A pricing model hardcoded against today's per-token cost from one provider becomes a margin problem the next time that provider adjusts rates, which is exactly the plumbing work that ends up eating engineering time better spent on the product itself.

The third is no visibility for the customer. If a business buyer can't see, in near real time, how many tokens or calls their team burned and why, the first oversized invoice becomes a trust problem, not a revenue win. A usage alert that flags an account approaching an unusual spend, or a usage dashboard or customer portal, isn't a nice-to-have on usage-based AI pricing, it's the thing that keeps a legitimately larger bill from feeling like a billing error.

A simple framework for setting AI agent pricing

Once metering is solid, the pricing decision comes down to matching the unit to the buyer, not just to your cost structure.

The unit doesn't have to be the same across tiers. It's common to sell developers on raw usage and sell the same underlying product to a business buyer as a credit-based plan built on top of the exact same metering, which is effectively what Cursor does between its per-seat Pro plan and its pooled, invoice-billed Enterprise tier.

Where this fits with the rest of your billing stack

None of this pricing design work matters if the underlying event capture can't keep up with how fast agents generate billable activity, or if every provider update means rewriting your metering code. That's the specific problem Lago's Agent SDK (see the SDK docs for setup across providers) is built to remove: it normalizes token usage across OpenAI, Anthropic, and Bedrock automatically, so the pricing model above can change without a corresponding engineering project every time a provider ships an update. For the deeper mechanics of how usage becomes an invoice line at all, see what metered billing actually is, and if you're still deciding whether to build this metering and pricing layer yourself, should you build or buy usage-based billing walks through that tradeoff directly.

Want to see how this looks with your actual token volumes and provider mix? Book a demo or explore Lago's open-source billing engine.

FAQ

Should I bill for failed or retried AI agent calls? Generally, no. If a retry happens because of your own infrastructure, a rate limit, a timeout, a malformed response, that's your cost to absorb, not the customer's. Meter and bill only on completed, successful runs, and treat retries as an internal cost signal instead.

Is token-based pricing the same as usage-based pricing? No. Usage-based pricing is the pricing strategy (charging by consumption); tokens are just one possible unit of consumption to charge on. API calls, tool invocations, and resolved outcomes are the other common units, each with different tradeoffs between cost accuracy and buyer intuition, covered above.

How do I price an AI agent if usage varies wildly between customers? Match the unit to the buyer rather than picking one unit for everyone: developers usually want raw per-call or per-token pricing, business buyers want a subscription with included credits and metered overage, and enterprise buyers want committed usage tiers with a true-up. The same underlying metering can support all three.