How Much Does an AI Agent Cost? The Hidden Bill
Key Takeaways
- The price per token is not the cost of an agent. The cost is the price per completed task, including every call, every retry and every failed attempt.
- Agents re-send their growing context on every step, so input tokens — not output tokens — usually dominate the bill, and costs grow faster than the number of steps.
- Caching the repeated prefix (system prompt, tool definitions, early conversation) is the single biggest lever, because that text is re-sent on every call.
- A cheap model that needs three attempts can cost more than an expensive model that succeeds once, so compare models on cost per completed task, not cost per token.
- Build, subscription and API pricing are three different bills: build once and maintain forever, subscribe per seat and accept limits, or pay per use and accept variance.
Ask “how much does an AI agent cost?” and most answers will quote a price per million tokens. That number is real, and it is almost useless on its own. An agent does not make one call. It plans, calls tools, reads results, retries, and re-reads its whole accumulated context on every step. The bill is the sum of all of that, divided by the tasks that actually finished. Change the unit, and the whole budgeting conversation changes.
Why token price alone misleads
A chatbot exchange is roughly one prompt in and one answer out. An agent task is a loop. On each step, the model is sent the system instructions, the tool definitions, the conversation so far and the latest tool result, then it produces a short reasoning step or a tool call. The next step sends all of that again, plus the new result. The context therefore grows with every step, and every step re-bills the context that came before it.
That is why input tokens dominate. The model’s visible output per step is often only a few hundred tokens, but the input it re-reads can be tens of thousands. Analyses of agent workloads published in 2026 describe exactly this shape: tool-calling loops re-sending the full accumulated context on every step, so token use compounds with every action. One guide’s measurement found most of a run’s tokens were data already sent in an earlier step, and trimming tool output cut total cost substantially without changing the outcome.
Retries multiply the bill a second time. If each step succeeds 95% of the time, a 10-step chain finishes only about 60% of the time on the first attempt (0.95 raised to the 10th power), and the failed attempts are billed too. A realistic budget therefore divides total spend by tasks completed, not by tasks attempted. Until you separate those two numbers, you cannot see the “cheap model that keeps retrying” problem.
A worked example, with its assumptions stated
The table below is an illustrative calculation, not a vendor quote and not a calculator tool. It uses round, invented unit prices so the arithmetic is easy to follow, and it exists to show how the pieces combine. Replace the unit prices with your provider’s actual list prices before using it for a real budget.
| Assumption (illustrative only) | Value |
|---|---|
| Steps per task | 8 |
| Average input tokens per call, growing with context | 12,000 |
| Average output tokens per call | 400 |
| Illustrative input price | $1.00 per million tokens |
| Illustrative output price | $5.00 per million tokens |
| Attempts per completed task | 1.4 (some tasks need a retry) |
Per call, the illustrative cost is (12,000 × $1.00 + 400 × $5.00) / 1,000,000 = $0.014. Per task, that is 8 calls × $0.014 = $0.112, and per completed task, including retries, $0.112 × 1.4 = $0.157. At 10,000 completed tasks a month, the illustrative model bill is about $1,570. The lesson is not the dollar figure, which will differ with real prices. The lesson is which inputs move it: steps per task, context growth, and the retry rate move the total far more than a small change in the per-token price.
Now change one assumption. Cut the average input per call from 12,000 to 7,000 tokens by trimming tool output and summarising old turns, and the per-call cost falls to $0.009, the per-completed-task cost to about $0.10, and the monthly illustrative bill to about $1,000. That is why the boring work — trimming context — beats shopping for a cheaper model in most real budgets.
Build vs subscription vs API: three different bills
| Route | What you pay for | Best when | Watch out for |
|---|---|---|---|
| Build it yourself | Engineering time, hosting, model tokens, maintenance | The workflow is core to your business and will run for years | You own uptime, security, updates and every failure mode |
| Subscribe to an agent product | Per seat or per plan, usually with usage limits | You want a working product this week, not a project | Limits, seat costs and lock-in; check what counts against the limit |
| Pay per use via API | Tokens actually consumed, plus your own hosting | Volume varies, or you already have a product to embed agents in | Variance: a bad week of retries is a real bill, so set caps |
Subscriptions look predictable until you hit a limit, and then they look expensive. API billing looks cheap until a loop runs away, and then it looks terrifying. Building looks free until you count engineering time. The honest comparison prices all three over the same period, including the maintenance year, not just the launch month.
The hidden bill: oversight, review and failure
The model bill is only part of the cost. Agents that act in real systems need human review of consequential actions, logging that lets you reconstruct what happened, and someone on call when a run goes wrong. Those are people costs, and they do not shrink when token prices fall. A task that saves an hour of staff time but needs 20 minutes of careful review has saved 40 minutes, not an hour, and a task that needs review by a senior specialist may save nothing at all.
Failure has its own price. A runaway loop that re-feeds a bloated session every few minutes until credits run out is not a theoretical risk; public postmortems describe exactly that shape of incident. The controls are unglamorous and essential: a maximum number of steps per run, a maximum number of retries per tool, a maximum token budget per run, and a kill switch that stops the run and saves the partial result. Set those limits before the first production run, not after the first surprise bill.
How to cut the bill without cutting quality
- Cache the fixed prefix. Keep the system prompt and tool definitions identical at the start of every call, and put changing content at the end. Cached reads are priced far below fresh input on major providers, and the fixed prefix is usually most of the input.
- Trim tool output. Drop the 400-line dump after extracting the one line you needed. Summarise old turns instead of replaying them. Every token you stop re-sending is a token you stop paying for on every later step.
- Route by difficulty. Use a smaller, cheaper model for simple steps and reserve the strongest model for steps that actually need it. A cheap model that succeeds once beats an expensive model that succeeds once, but only if you measure success per task.
- Cap the loop. Maximum steps, maximum retries, maximum tokens per run, per user and per day. When a cap is hit, the run stops and a human sees it.
- Measure cost per completed task. Track total spend divided by tasks completed, including failures. If that number is not falling as you optimise, your optimisations are not working.
For how agents connect to tools in the first place, see what AI agents are and how they work, and for the governed-action pattern in enterprise systems, see how OpenAI and ServiceNow connect workflows to ChatGPT. For a vendor view of making AI spend visible, see Claude Enterprise’s cost tools.
Limitations
The worked example uses illustrative unit prices and assumed step counts, not a real vendor quote, and real costs will differ with your provider, model, task shape and retry rate. The mechanism described — re-sent context, retries and caching — is well documented in the sources below, but the specific multipliers reported by analysts vary by workload and should not be quoted as universal constants. This article is budgeting guidance, not a pricing guarantee, and it is not a calculator tool: run your own measurements on your own tasks before committing to a budget.
