AI Billing: The Complete Guide

Updated July 2026

AI companies price four ways: per token, per credit, per seat, or per outcome. Most start with the first, most regret it within a year, and almost none of them planned the billing infrastructure before they picked the model. Mistral bills token usage across 14 frontier models shipped in 18 months, with a prepaid wallet that tops itself up automatically. Cerebrium meters GPU, CPU, and storage usage down to the millisecond for inference workloads. Blacksmith went from zero to 700+ paying customers in year one billing CI compute by usage, not seats. None of that ran on a homegrown system built for something else. It ran on infrastructure built for metering, not invoicing. If you want the full breakdown of pricing strategy, not billing mechanics, see our guide to AI pricing models; this piece is about what has to be true underneath whichever one you pick.

That's the argument of this guide. Pricing is a decision. Billing is the system that makes the decision survive contact with real usage. Most AI companies get the first part right and the second part wrong, and the second part is where the margin goes to die.

TL;DR

How do AI companies price their products today?

Four models, in order of how most AI companies actually adopt them, not how analysts rank them.

Token pricing. Charge per input and output token, usually with different rates for each, and usually different again for cached tokens. OpenAI's GPT-5.5 API prices input at $5 per million tokens and output at $30 per million, with cached input at $0.50; the smaller GPT-5.4 mini runs $0.75 input and $4.50 output. Anthropic runs the same structure across its own model tiers: Opus 4.8 at $5 input and $25 output per million tokens, Sonnet 5 at $2 and $10 (introductory, reverting to $3 and $15 later in the year), Haiku 4.5 at $1 and $5, each with its own separate cache write and cache read rate on top. Mistral prices its base APIs the same way, per model, per token direction. It's the default because it maps directly to compute cost: more tokens, more GPU time, more bill. The problem shows up downstream, not at the API layer. A platform built on top of a token-priced model has to decide whether to pass tokens through directly (transparent, but confusing to non-technical buyers) or wrap them in something friendlier.

Credit pricing. Convert tokens, compute time, or API calls into an abstracted unit: credits. This is where the category is drifting away from the word "credits" itself, even as the mechanic stays the same. Cursor's current plans bundle an included amount of model usage into the subscription, then bill on-demand usage in arrears once that's consumed, no separate credit currency, just metered overage on top of a seat. Replit still frames its usage in checkpoints. Either way it's the same pattern: decoupling the unit customers see from the unit the infrastructure consumes. You can change your underlying model provider, mix five different LLMs behind one feature, and the customer never has to know the token math changed. The trade-off: someone still has to reconcile the abstracted unit back to real cost, and that reconciliation is where a lot of AI companies discover their margin is thinner than the pricing page implied.

Seat pricing. License per user, independent of usage. GitHub Copilot does this at the individual tier. It's the easiest model to bill, because it's the oldest one, the one every subscription billing tool was built for. It's also the worst fit for AI products where usage varies 50x between a light user and a power user. Seat pricing on an AI product either overcharges the light users or undercharges the heavy ones. There's no third option.

Outcome-based pricing. Charge for the result, not the resource. A support AI charges per resolved ticket, not per token spent resolving it. This is the model everyone in AI wants to move toward and almost nobody has actually shipped at scale, because it requires the billing system to know what "resolved" means in your product, then bill against that definition reliably enough to survive a customer audit. We cover what that actually takes in the outcome-based pricing section below.

Most companies don't pick one. They start with token or credit pricing at launch, because it's the only thing they can meter on day one, then bolt on seat-based tiers for the enterprise buyers who want predictability, then spend the next eighteen months trying to retrofit outcome-based pricing onto a system that was never built to track outcomes in the first place. We've written up the specific ways that retrofit goes wrong in common AI pricing mistakes.

What's the difference between token pricing and credit pricing?

Token pricing bills the resource. Credit pricing bills an abstraction of the resource. That's the entire difference, and it matters more than it sounds.

When you bill tokens directly, your price list is your cost list with a markup. A model provider's own pricing page and your invoice look structurally identical, down to the per-model line items. OpenAI alone prices GPT-5.5, GPT-5.4, and GPT-5.4 mini at three different input and output rates. Anthropic runs four tiers, Fable 5 through Haiku 4.5, each with its own input rate, output rate, cache write rate, and cache read rate, sixteen numbers for one provider. This is fine until you want to change providers, blend models, or price a feature that touches three different LLMs with three different token costs. At that point token-for-token billing turns every pricing change into an infrastructure change.

Credits solve that by adding a layer of indirection. One credit equals some blend of tokens, compute seconds, or API calls, and the exchange rate lives in your billing system, not your product code. This is why credit-based AI products can swap model providers overnight without touching a customer-facing price. It's also why credit pricing is quietly a metering problem before it's a pricing problem: you need to know, per feature, per model, per customer, exactly how many credits an action actually consumed, in real time, or you're pricing off guesses.

The companies that get burned here aren't the ones who chose token pricing or credit pricing wrong. They're the ones who chose credit pricing correctly, then discovered their metering pipeline couldn't tell them what a credit actually cost until the invoice was already sent. That's not a pricing mistake. That's a billing infrastructure gap, and we go deep on exactly this gap in AI billing is mostly token plumbing. The same reconciliation problem shows up in how OpenAI structures its own credit system, covered in OpenAI credits, explained.

How do you price an AI product before you've shipped it?

Cheap to answer, expensive to get wrong. Two questions decide the model, not one.

First: does usage vary a lot between customers, or a little? If a little, seats work fine, and you should stop reading this section and go build product. If a lot, seats are the wrong model on day one, full stop.

Second: can you meter the unit you want to charge for, reliably, before you launch? This is the question most AI companies skip. Outcome-based pricing sounds better than token pricing in every pitch deck, and it is, but only if you can already tell, programmatically, whether an outcome happened. If you can't yet, price on the unit you can actually measure today, and build toward the unit you want to measure eventually. Pricing ahead of your metering capability is how companies end up disputing their own invoices internally before a customer ever sees one.

What is outcome-based pricing for AI, and when does it make sense?

Outcome-based pricing charges for a result: a resolved support ticket, a booked meeting, a qualified lead, a shipped pull request. It's the pricing model AI companies most want, because it aligns price with value instead of price with cost, and it's the hardest one to bill correctly, because "outcome" has to be defined precisely enough to survive a customer disputing it.

It makes sense when three things are true. The outcome is unambiguous: either the ticket resolved or it didn't, there's no partial credit that needs a judgment call. The outcome is attributable to your product specifically, not to a human who did most of the work after your AI made a suggestion. And you can log the event that constitutes the outcome at the moment it happens, with enough detail to reconstruct it later if a customer asks why they were billed.

It doesn't make sense as a first pricing model for a product that hasn't proven its outcome definition holds up across real customers yet. Every AI company that has shipped outcome-based pricing successfully shipped token or credit pricing first, used that period to learn what "outcome" actually means across their customer base, and only then moved the price to the outcome once the definition stopped changing every quarter.

The billing requirement underneath outcome-based pricing is an audit trail, not a meter. A meter counts units. An audit trail proves, after the fact, that a specific outcome happened, when, and why the customer is being billed for it. If your billing system can't produce that trail on demand, outcome-based pricing is a promise you can't back up when a customer asks. We cover the mechanics of building that trail in outcome-based pricing for AI products.

How do you bill for AI agents, not just API calls?

An API call has a clean shape: one request, one response, one thing to meter. An agent doesn't. It calls tools, retries on failure, spawns sub-tasks, sometimes calls other agents, and can run for minutes or hours before it produces anything a customer would recognize as a result. Billing for agents means billing for a process, not a request.

This breaks the assumption underneath most billing systems, which is that a billable event has a start and an end you can capture in one transaction. An agent's billable event might be a chain of forty tool calls across three model providers, half of which failed and got retried, and the customer should be billed once, correctly, for the parts that mattered. Get the metering wrong here and you either bill customers for your agent's retries, which is a fast way to lose them, or you eat the retry cost yourself, which is a fast way to lose your margin.

The infrastructure answer is event-level metering with idempotency built in: every tool call, every retry, every sub-agent spawn logged as its own event, tagged to the parent task, deduplicated so a retried call doesn't double-bill, and rolled up into whatever unit you're actually charging for, whether that's tokens, credits, or the outcome the agent was trying to produce. This is exactly the gap covered in why vibe-coding platforms monetize their users, and their users can't: platforms that let users build AI agents inherit this metering problem the moment their users start monetizing what they built, and most of those platforms weren't built to solve it. See also AI agent monetization for the pricing side of this same problem.

How do I price my AI product when the unit economics keep changing?

Model costs drop. Model costs also spike, when you switch providers or a new model version changes its pricing structure entirely. An AI product's unit economics are less stable in year one than almost any other software category, which is a specific argument against hardcoding your pricing logic into application code.

The practical answer is separating the price a customer sees from the cost your infrastructure incurs, with a margin layer in between that you can adjust without shipping a product release. This is the same argument for credit pricing over token pricing, generalized: whatever unit you bill in, the exchange rate between that unit and your actual infrastructure cost should live in configuration, not code. Companies that hardcode "1 credit = 1000 tokens" into their billing logic find out the hard way that renegotiating a model provider contract now requires an engineering sprint instead of a config change.

This is also where margin visibility becomes a billing feature, not a finance nice-to-have. If you can't see, per customer, per feature, what your actual margin is right now, you're pricing blind. Given the frequency with which underlying compute costs move in this category, waiting for the monthly finance close to find out you're bleeding margin on your top customer is not a viable feedback loop. We call this failure mode the AI margin cliff: the gap between what you thought a customer cost you and what they actually cost you, discovered too late to do anything but eat it.

How do you prevent unpaid or unmetered AI usage?

Usage that isn't metered isn't billed. This sounds obvious until you count the ways AI products generate usage outside the request path your billing system is watching: background jobs, retries, webhook-triggered actions, agent sub-tasks, cached responses that still consumed compute the first time. Every one of those is revenue if you catch it and margin loss if you don't.

The failure mode isn't usually fraud. It's architecture. A metering pipeline built for one code path (the main API request) misses usage generated by every other path, and nobody notices until finance reconciles infrastructure spend against billed revenue and finds a gap that's been growing for months. This is a structural version of the problem addressed in how to deal with massive unpaid AI bills: the bill wasn't unpaid because the customer refused to pay it. It was unpaid because nobody billed for it in the first place.

The fix is metering at the event layer, not the API layer: every unit of billable work emits an event when it happens, regardless of which code path triggered it, and those events get aggregated into invoices independent of which feature or service generated them. It's more infrastructure than "count the API calls," and it's the only version of metering that doesn't leak.

What does AI billing infrastructure actually need to handle?

Four things, and most billing tools built for SaaS subscriptions handle zero of them well.

Real-time, high-cardinality metering. An AI product can generate thousands of billable events per customer per minute, each one small, each one needing to be captured, deduplicated, and attributed correctly. Subscription billing tools were built to handle one event per customer per month: a renewal. That's a different order of magnitude entirely.

Multi-model cost reconciliation. If a feature routes across three model providers based on load or cost, the billing system needs to know what actually got used, not just what got charged to the customer, or margin visibility disappears.

Flexible unit definitions that don't require a deploy to change. Tokens today, credits next quarter, outcomes the quarter after. The billing infrastructure has to support all three without a rewrite each time the pricing model evolves, because at the rate this category moves, it will evolve.

An audit trail granular enough to answer "why was I billed this" for any single event, months later. This matters for disputes, for compliance, and increasingly for agent-driven billing where the customer wants to see exactly what an autonomous system did that generated a charge. Anthropic's own per-model, per-context-window pricing structure is a useful case study in how granular this can get; we break it down in Anthropic's finger-based pricing.

This is the underlying reason the common AI pricing mistakes keep repeating across the category: companies pick the right pricing model, then build it on infrastructure designed for a fundamentally different metering problem, and the mismatch surfaces three to six months later as margin they can't explain.

How are real AI companies solving this today?

Mistral shipped 14 frontier models in 18 months and bills token usage across all of them, per model, with a prepaid wallet that tops itself up so usage never outruns payment. They went live in 52 days and have since sent more than 32,000 invoices. That speed only works because the billing logic lives in configuration, not in a codebase that needs a deploy every time a new model ships.

Cerebrium tracks GPU type, CPU, memory, and storage usage down to the millisecond for inference workloads, then reflects all of it in one invoice per customer, per environment. Before switching, they ran this on a homegrown system built on DynamoDB, which worked until the query patterns needed for accurate cost breakdowns stopped being something DynamoDB was built for.

Blacksmith went from zero to 700+ paying customers in year one, now at eight figures in ARR, billing CI/CD compute by usage instead of seats. As a team of former infrastructure engineers, they evaluated building it themselves and chose not to, specifically because usage-based billing with enterprise overrides and add-ons is a second full-time engineering problem on top of the one they were already solving.

None of these are subscription businesses wearing a metering feature. They're usage-native from the ground up, which is why they didn't reach for a billing tool built for subscriptions and try to make it stretch. They built on infrastructure designed for the metering problem first.

Frequently asked questions

What's the best pricing model for a new AI product?

There isn't a single best model, there's a best-fit model for how much your usage varies and what you can already meter. If usage is roughly flat across customers, seats work. If it varies a lot, which is true for most AI products, start with token or credit pricing, because it's the only thing you can meter accurately on day one.

How do I price my AI product before I have real usage data?

Price on the unit you can already measure reliably, not the unit you wish you could measure. Most companies start with token or credit pricing for this reason, then move toward outcome-based pricing once they've watched enough real usage to know what "outcome" should mean for their specific product.

Is outcome-based pricing better than usage-based pricing?

It's more aligned with customer value, not automatically better. Outcome-based pricing requires an audit trail precise enough to survive a customer disputing a charge, which usage-based pricing doesn't need to the same degree. Most companies that ship outcome-based pricing successfully ran usage-based pricing first to learn what "outcome" means across real customers.

Why do credits exist if tokens already measure usage?

Credits add a layer of indirection between what a customer buys and what your infrastructure actually consumes. That lets you swap model providers, blend multiple LLMs behind one feature, or change your cost structure without changing a customer-facing price. The cost is that something in your billing system has to reconcile credits back to real infrastructure spend, accurately, or your margin numbers are guesses.

Why does seat-based pricing fail for AI products specifically?

Because usage per seat varies far more in AI products than in traditional SaaS, often by 50x or more between a light user and a power user. A flat seat price either overcharges the light users or undercharges the heavy ones. There's no seat price that's fair to both.

How is billing for AI agents different from billing for API calls?

An API call is one request and one response, a clean unit to meter. An agent is a process: it calls tools, retries on failure, and can spawn sub-tasks across multiple model providers before producing a result. Billing for it means metering every step of that process, deduplicating retries, and rolling everything up into one correct charge, not billing the request and hoping the process behind it matches.

What happens if I don't meter all my AI product's usage?

Usage that isn't metered isn't billed, and it doesn't announce itself. Background jobs, retries, webhook-triggered actions, and agent sub-tasks all generate real infrastructure cost outside the main request path most metering pipelines watch. That gap usually surfaces months later, when finance reconciles infrastructure spend against billed revenue and finds a number that's been growing quietly.

Can I change my AI pricing model without a full rebuild?

Only if the exchange rate between your billing unit and your actual infrastructure cost lives in configuration, not in application code. Companies that hardcode a fixed token-to-credit ratio into their billing logic find that changing model providers later requires an engineering sprint instead of a settings change.

What's the difference between AI billing and standard SaaS billing infrastructure?

Standard SaaS billing tools were built for one event per customer per month: a renewal. AI products generate thousands of small billable events per customer per minute, often across multiple model providers, and need real-time metering, multi-model cost reconciliation, and an audit trail granular enough to explain any single charge months later.

How often do AI companies change their pricing model?

Often enough that hardcoding a pricing model into your product code is a mistake. Model costs move, provider contracts get renegotiated, and companies that started on token pricing routinely add credit or seat layers within the first year. Billing infrastructure that treats the unit definition as configuration survives those changes; infrastructure that treats it as code doesn't.

Do I need an audit trail if I'm not using outcome-based pricing yet?

Increasingly, yes. Beyond disputes and compliance, customers are starting to expect visibility into what an autonomous agent did that generated a specific charge. Building the audit trail after you need it is much harder than building it into the metering layer from the start.

Should I build AI billing infrastructure myself or use an existing platform?

That's a build-versus-buy decision like any other piece of critical infrastructure, and it depends on how much of your engineering time you want to spend on metering pipelines instead of your core product. I'll be direct about where I sit on this: it's the decision Lago is built to be one answer to, not the only one.

Key takeaways

AI pricing has four real models: token, credit, seat, and outcome, and most companies move through them in that order whether they plan to or not. The pricing decision is the easy part. The billing infrastructure underneath it, real-time metering, multi-model reconciliation, flexible unit definitions, and an audit trail that survives a dispute, is where the actual engineering problem lives. Agents make this harder, not easier: a billable event stops being a single request and becomes a process with retries, sub-tasks, and no clean start-and-end shape. Mistral shipped 14 models in 18 months and sent 32,000 invoices without a finance team drowning in reconciliation. Cerebrium tracks usage down to the millisecond across four different cost dimensions in one invoice. Blacksmith went from zero to 700+ customers billing pure usage, not seats. All three built usage-native billing before they needed it, not after a finance close revealed the gap. That's the pattern worth copying, independent of which vendor you use to do it.

If you're building this yourself: token or credit pricing first, outcome-based pricing only once your event definitions stop changing quarter to quarter, and margin visibility per customer from day one, not from the first finance close that surprises you. If you're deciding whether to build that infrastructure or embed it, that's a build-versus-buy decision like any other piece of critical infrastructure. I'll be direct: it's the decision Lago is built to be one answer to. Not the only one. But worth putting on the list before you write the first metering pipeline yourself.