You shipped an AI agent, priced it at a flat monthly fee that felt generous, and then the first invoice from your model provider arrived. Most customers cost you almost nothing. A handful cost more than they pay you. Nobody did anything wrong; the agent simply worked harder for some of them.
The short answer to pricing AI agents without losing money on API costs is this: stop pricing off your average cost per customer and start pricing off your cost per task at the 90th percentile, then choose a billing unit that moves with that cost. Flat seats can still work, but only with usage limits attached. Everything else in this article is how to get those two numbers and act on them.
Why agent costs behave differently from chat costs
A chatbot answers once. An agent plans, calls a tool, reads the result, calls another tool, and re-sends its growing context to the model every time it does. Each loop is a fresh bill for input tokens, and the input keeps getting longer.
Anthropic published figures from its own systems on this: agents typically used about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. That is the gap between a pricing model designed for a chat feature and one designed for an agent.
The bigger problem is variance. Cost per task is not a number. It is a distribution with a long tail, because a clean request finishes in three steps and a messy one wanders for twenty-five.
Work out the real cost of one task
Here is a hypothetical support agent running on Claude Sonnet 5, which Anthropic lists at $2 per million input tokens and $10 per million output tokens.
A routine ticket: six model calls, each sending about 8,000 input tokens (system prompt, tool definitions, conversation so far) and returning about 400 tokens.
- Input: 48,000 tokens × $2/M = $0.096
- Output: 2,400 tokens × $10/M = $0.024
- Total: about $0.12
A messy ticket: the customer is vague, a lookup fails, the agent retries. Twenty-five calls averaging 20,000 input tokens and 600 output tokens.
- Input: 500,000 tokens × $2/M = $1.00
- Output: 15,000 tokens × $10/M = $0.15
- Total: about $1.15
Same product, same customer, nearly ten times the cost. Put the messy ticket on a premium model such as Opus 5 ($5 input, $25 output per million) and it is roughly $2.90. Now imagine a customer whose data is simply messier than everyone else’s. Every one of their tickets looks like the second example.
So before touching a price page, log tokens per task in production and look at the median, the 90th percentile and the worst 1%. If you only have an average, you do not yet know your cost.
Cut the cost before you set the price
Many teams jump to repricing when the cheaper fix is engineering. Four levers usually matter most.
Prompt caching. Your system prompt and tool definitions are identical on every call. Anthropic charges 1.25 times the input price to write a 5-minute cache and 0.1 times to read it. In the routine ticket above, if 6,000 of the 8,000 input tokens are a stable prefix, input cost falls from about $0.096 to about $0.045, and the whole task from $0.12 to roughly $0.07. That is more than a third off with no change to what the customer sees. OpenAI and Google offer their own caching discounts, with different rules, so check the provider you actually use.
Model routing. Not every step needs your best model. Classifying intent, extracting fields or summarising a tool result can often go to a small model; Anthropic lists Haiku 4.5 at $1/$5 per million. Keep the expensive model for the steps where quality visibly changes the outcome, and test that claim rather than assuming it.
Batch anything that is not live. Overnight enrichment, report generation and bulk document review do not need an instant reply. Anthropic’s Batch API is 50% cheaper on both input and output tokens.
Hard budgets per task. Cap steps, cap total tokens, and trim old context instead of re-sending the full history. When an agent hits its cap, hand off to a human or ask the user a clarifying question. A runaway loop should cost you a known maximum, not an unknown one. (Stress-testing for exactly these loops is part of breaking your agent before a customer does.)
The four ways to charge, and where each one breaks
| Model | What the customer buys | Works when | Breaks when |
|---|---|---|---|
| Seats | Access per user | Usage per user is predictable and capped | One power user runs the agent all day |
| Credits / usage | Units of work (actions, runs) | Buyers can see and forecast the unit | Units feel abstract and bills surprise finance |
| Outcomes | A result (a resolved ticket, a booked lead) | The outcome is clearly defined and measurable | Failed attempts still cost you tokens |
| Hybrid | Platform fee plus included usage plus overage | Most B2B agents, most of the time | The included allowance is set off averages |
Two public examples show how large vendors moved. Salesforce launched Agentforce at $2 per conversation, then in May 2025 introduced Flex Credits at $500 per 100,000 credits, with a standard action costing 20 credits, or $0.10. That is a shift from charging per conversation to charging per unit of work, which tracks cost far more closely.
Intercom went the other way, toward outcomes. Its Fin agent is billed at $0.99 per outcome, where an outcome includes a resolution (no further help requested after Fin’s last answer) or a completed handoff to a human. Intercom states that a conversation simply passed to the team without an outcome is not charged. Note what that means: Intercom absorbs the model cost of every attempt that fails. Outcome pricing is only safe if your success rate is high and your cost per failed attempt is small relative to the fee.
Neither choice is universally right. They reflect different bets about who should carry the variance: the vendor or the buyer.
A pricing approach that survives a bad month
For a small SaaS team with a real but young agent product, this sequence is a sensible default.
- Measure cost per task at p50 and p90 for at least a few hundred real tasks, after caching and routing are in place.
- Pick a billing unit the customer already thinks in. Tickets, documents, calls, qualified leads. Tokens are your unit, not theirs.
- Price the unit off p90 cost, not p50, with enough headroom for your target gross margin plus support and infrastructure. If the price looks absurd at p90, the product needs cost work, not a braver price.
- Sell a plan with an included allowance and a published overage rate. This gives finance teams a predictable baseline while protecting you from the tail.
- Add a fair-use cap per task in your terms and in the code, so one pathological job cannot consume a month of margin.
- Show usage inside the product. Customers accept overage bills far more readily when they watched the meter move.
- Re-check quarterly. Model prices change, sometimes sharply, and a new model can change both quality and token usage. A price that was thin in January can be healthy by June, or the reverse.
If you only do one thing this week, set a hard token budget per task and alert when a customer’s p90 cost crosses a threshold. That turns an invoice surprise into a dashboard warning.
Questions founders usually ask next
Should I just pass API costs straight through to customers?
Pure pass-through with a markup is honest but hard to buy. Most business buyers cannot forecast tokens, and it invites them to compare your bill against the provider’s price list. Pass-through works better as an enterprise option for customers who bring their own API key.
Will falling model prices fix this on their own?
Partly. Cheaper tokens help, but agents tend to use the savings on longer context, more tool calls and more ambitious tasks. Plan for per-token prices to fall and per-task token counts to rise.
Is outcome-based pricing risky for a small team?
It can be. You carry the cost of every failure, and defining “outcome” in a contract is harder than it looks. Start with usage or hybrid pricing, collect data on success rates, then offer outcome pricing on the workflows where you are confident.
Building an agent that is cheap to run, not just impressive in a demo
Most margin problems with AI agents are decided in architecture, long before anyone writes a pricing page: which model handles which step, what gets cached, how context is trimmed and where a human takes over. If that is where you are stuck, AB7 Solutions builds AI agents, AI workflow automation and RAG systems with cost per task treated as a design requirement. That includes instrumenting token usage per task, adding model routing and caching to agents that already exist, and designing human-in-the-loop handoffs for the cases an agent should not keep grinding through. If your current agent is already profitable at p90, we will say so rather than sell you a rebuild. For more on budgeting the build itself, see what it costs to hire AI agent developers, or if you are still at the first version, how to build your first AI agent without it falling over.
Send us a description of your agent and a rough view of your usage, and we will tell you where the cost is going.
Email: ab@ab7solutions.com | director@ab7solutions.com
Phone: +91 9878067778 | +1 321 341 7733
Website: www.ab7solutions.com
Sources: Anthropic, Claude API pricing; Anthropic Engineering, How we built our multi-agent research system; Salesforce, Flexible Agentforce pricing (May 2025); Intercom Fin pricing. Prices as published in September 2026; check current rates before modelling.