AI agent cost has three parts: the build, the run and the keep-alive. The build is the system that can take a real task. The run is the model calls, tool calls and retries each task then spends, and the keep-alive is the work after launch, when a tool, a model or a document changes. A per-token price covers one line inside the run, and one combined number hides which of the three is about to move.
Key facts
Definition
The cost of a production AI agent splits into the build, the run, and the keep-alive, and the per-token price is one line inside the run.
How Bigcircle does it
- Bigcircle counts the build as the tools, credentials, eval set and failure path a real task needs, which on its DevOps agent took roughly four months.
- Bigcircle counts the run as every turn, tool call, retry and child agent, because each turn resends the transcript.
- Bigcircle counts the keep-alive as eval reruns, review and readable traces after launch, and puts a cap in the request path so a loop stops before the next paid call.
Comparison
Prompt caching cuts the worked ten-turn example from about $0.018 to about $0.006, while only a cap in the request path ends a runaway loop before the invoice.
Key number
In the worked example at October 2026 GPT-6 Luna rates, a ten-turn agent task costs about 24 times one reply, because every turn resends the transcript.
Our case studies show where the work went. On the DevOps agent, the build was mostly about reading the live AWS account, checking every template and putting a human review step before anything applied. On the chief-of-staff agent, the visible cost of tool definitions in the prompt turned out to matter less than the wrong tool choices that came with them.
The sections below take the build, then the run with a worked token calculation at prices as of 22 October 2026. The keep-alive and a way to compare two quotes come next. The last two sections cover the cap that ends a runaway loop before the next paid call, and the ledger of what each run spent. If a script or one query can do the job, agentic workflows vs AI agents comes first, and none of this bill starts.
How much does it cost to build an AI agent?
The build price follows the scope, and most of the scope sits around the model rather than in it. The build is everything that has to work before the first real task leaves the team: the tools the job needs, permission to call them, an eval set, and a path for the step that fails. Choosing a model is one decision inside that work, and usually not the long one.
The DevOps agent shows where the time goes. A raw model invents resource types, writes templates the account rejects for quota or region, and drifts between runs, and a failed stack can take minutes to unwind, so "apply and see" is not a usable loop.
The build therefore had to read live limits, quotas and existing resources before planning, check every template in a loop of structural and semantic checks, and show an engineer an architecture diagram before anything applied. Delivery took roughly four months.
The chief-of-staff agent spent its build on reach. It connects to more than a hundred systems, and a large share of an executive's work sits behind single sign-on and multi-factor login with no usable API. We argue that a routine the agent can finish 70 percent of still needs a person to hold the sequence, so it saves almost nothing. The 70 percent is an argument rather than a measurement, but it explains why reach costs build time on an agent like this.
Each integration is a tool contract, a login path and a failure the agent will meet in normal use. MCP authorization covers the check before each call, LLM evaluation covers the eval set, and how to build an AI agent puts those decisions in order. A build quote that lists model access and leaves out the access check and the eval set will be rewritten after the first real task fails.
How the build is bought is a separate question. AI pilot to production compares production hardening, a fixed-scope build and a studio-led programme. A fixed-scope build is priced against a scope agreed before work starts, so the useful comparison between two quotes is which of the three parts each one names.
Why does an AI agent cost more to run than one reply?
A run costs more than one reply because the agent decides how many steps to take, and each step sends the whole history again. A workflow pays one model call per step you wrote. An agent pays a number of calls that depends on the trace, and the input on each call grows with every tool result.
A worked example makes the shape concrete. The figures are assumptions for illustration, not measurements from any system of ours, and the prices are OpenAI's list rates for GPT-6 Luna as of 22 October 2026: $0.10 per million input tokens and $0.50 per million output tokens.
Take a system prompt and tool definitions of 6,000 tokens, a task of 10 turns, 300 output tokens per turn for the tool call, and 2,000 tokens of tool result added to the transcript after each turn.
| One reply | Ten-turn agent task | |
|---|---|---|
| Input tokens | 6,000 | 163,500 (6,000 on the first turn, 26,700 on the tenth) |
| Output tokens | 300 | 3,000 |
| Cost at the October 2026 Luna rates | about $0.00075 | about $0.018 |
Ten turns cost about 24 times one reply, not 10 times, because each turn pays again for every earlier turn's transcript. At 10,000 tasks a day that is about $179 a day on the run line.
Reasoning adds to it. OpenAI bills reasoning tokens as output tokens, and Luna defaults to reasoning effort medium. If each turn spent 1,000 reasoning tokens, another assumption, the same task would cost about $0.005 more, roughly 28 percent on top. The example also assumes reasoning from earlier turns is not sent again. Check that before you trust the figure, because the GPT-5.6 family carries earlier reasoning into the next turn by default. On a model that does, those tokens add to the input of every later turn. LLM model migration covers why a model change can move this line while the per-token price falls.
Tool definitions are part of the input on every turn, and the chief-of-staff agent found where listing all of them in the prompt stops working. Direct tool-calling with every tool listed worked up to roughly thirty tools. Past that, the model started choosing plausible but wrong tools, and we found that the context cost was the visible symptom while the selection error was the expensive one. The fix was to let the model query a tool registry and choose among a handful of relevant contracts, which kept the working context small at more than a hundred tools.
Prompt caching cuts that bill more than anything else in the example, because it discounts a repeated prefix, and an agent's growing transcript is one. As of 22 October 2026, caching is on by default on OpenAI's supported models, with a minimum prefix of 1,024 tokens on GPT-5.6 and later. On those models a cache read costs a tenth of the input rate and a cache write 1.25 times it.
An entry lasts 30 minutes by default, and each read refreshes it. OpenAI's caching rules do not name Luna, and Luna's model page lists cached input at $0.01 per million, the same tenth, so we assume the same write rate.
Applied to the example, if every turn after the first reads the earlier transcript from cache and writes only its new 2,300 tokens, the ten-turn task comes to about $0.006 instead of $0.018. That is 136,800 tokens read at the cached rate, 26,700 written at the write rate, and the same 3,000 output tokens. It assumes each turn arrives inside the cache lifetime with the whole prefix unchanged, so a retry that edits anything early in the transcript pays full price again from that point.
Caching at the application layer saves a different cost. Prospex, our own research engine, runs cache-first, so a rerun reuses earlier extraction and retrieval instead of calling external services again. By our estimate that cut repeated external API calls by 50 to 60 percent, and we watch the cache hit rate as its cost metric.
What does an AI agent cost after launch?
Keep-alive is the work after launch. It covers rerunning the eval set when a tool, a prompt or the model changes, a person who can act when a run stops, and traces that someone can still read when finance asks what happened. None of it shows on the launch invoice, and all of it is on the calendar afterwards.
Integrations are where it starts. We saw what point-to-point wiring does to maintenance on the chief-of-staff build: a vendor changes a response, and the break shows up somewhere unrelated days later. Our answer there was a uniform tool layer, where each tool is a typed contract with declared inputs, outputs and side effects.
Human review is the other running line. On the trademark drafting system, attorney corrections are the most valuable signal in the system, because they measure the gap automated scoring cannot see. That review does not end at launch. On the ESG filing pipeline, the slow failure is framework version drift, which is why the mapping version is recorded on each mapped fact.
Observability on an agent is the trace of each run, stored with the run. AI agent monitoring separates the quality of the answer from the health of the path that produced it. Name the person who owns the stop before launch. A stop with nobody assigned to it is only a log line, and the loop behind it keeps spending until someone reads the invoice.
How do you compare two AI agent quotes?
Compare two quotes part by part, or a missing line will look like a saving. Two proposals can describe the same agent and still leave out different parts, and the shorter one has often left off the keep-alive or the stop.
| Part | What moves it | What a thin quote skips |
|---|---|---|
| Build | Tools, credentials, evals, and the path for a failed step | Everything except a prompt and a happy path |
| Run | Turns, tool calls, retries, fan-out, and a transcript that grows | Every turn after the first |
| Keep-alive | Eval reruns, a person on the stop, review, and traces you can still read | A named owner after launch |
The figure repeats the three parts and adds the check on the request path. It is a framework for a scoping conversation and states no prices or shares. Green is the build, amber is the run, and blue is the keep-alive. The row underneath is the check before the next provider call, and the ledger under that is written where the agent's credential cannot reach it.
How do you enforce a budget in the request path?
A budget holds only when the check runs before the next provider call and a breach ends the run. A dashboard that climbs and an email that arrives later have already paid for every call between the threshold and the person reading it. The cap is code on that path, and it limits turns, tool calls, spend, and how many child agents one run may start.
Fan-out, where one run starts several child agents, is the case a per-call limit misses, because each child looks small on its own. If every child gets a fresh counter, together they spend the parent's allowance several times over. Make each child draw on what the parent has left, and have the parent refuse another child once the count or the allowance is gone. Multi-agent systems covers when the children are worth starting at all.
Retries need a bound of their own. We bounded them on the chief-of-staff build, because an agent that retries indefinitely against a broken vendor is worse than one that stops: it burns cost and time while looking busy. The DevOps agent bounds revision the same way, and a template that will not come clean after bounded revision is escalated as a request the agent cannot safely fulfil. Count failed calls in the total, because the provider already did.
A limit written into the prompt can be talked past, and a counter in code cannot. Guardrails that live only in the prompt can give way the first time a tool result or a user message argues for one more step.
Account-level caps from the cloud providers are a backstop behind that check. They act on a whole project after many runs have spent, they cannot tell a retry storm from a busy day, and a paused project takes your working runs down with the broken one.
AWS spend limits, introduced on 16 September 2026 and still rolling out to a limited set of customers, pause a project and stop its resources when its monthly usage reaches the limit. An opt-in control pauses the highest-cost resources about four days before the limit, chosen from five services that include Lambda and Bedrock.
Google Cloud's Spend Caps, in public preview since 29 July 2026, restrict further usage of one service in one project once the monthly cap is reached. Both are worth turning on, and the loop still needs its own check before each call.
Monitoring without a stop is the gap that costs most. In one incident Jatin Bansal collected, a team running four LangChain agents had monitoring and no enforcement. An analyzer and a verifier began looping with each other in November 2025, and the bill reached $47,000 over eleven days. The figures are as Bansal reports them.
Set each cap from runs you have already finished rather than from a framework default, which is calibrated to someone else's task. Leave room above the longest run that completed normally, so a stuck loop hits the cap and a normal task does not. A cap set on a guess either cuts good tasks or lets a loop run.
Where does the spend record live?
The ledger has to outlive the agent, or a loop can erase the only record of what it spent. Write the run id, the tool, whether the call was allowed or refused, the token counts and the stop reason for each call to a store the agent's credential cannot delete or rewrite. Include the calls that failed and the calls each child made, or your meter will sit below the invoice.
Reconcile your meter with the provider bill every month as two sums: billed spend from the invoice, and the cost of every attempt from your own traces, including retries, timeouts, cancellations and outputs you rejected.
A gap left after failed attempts are included is work you are not tracing, such as an eval job, a warm-up call or a second service on the same key. Close that gap before you call either number the cost of a successful task.
Common questions
How much does an AI agent cost?#
AI agent cost has three parts, the build, the run and the keep-alive, and each moves for a different reason. The build is tools, credentials, evals and the path for a failed step. The run is turns, tool calls, retries, fan-out and a transcript that grows. The keep-alive is eval reruns, review and traces after launch. A price per token covers one line inside the run.
How much does it cost to build an AI agent?#
The build price follows the scope, and most of the scope sits around the model: tools, permissions, an eval set and the path for a failed step. Bigcircle's DevOps agent took roughly four months, spent mostly on reading the live AWS account, checking every template and a human review step. Compare quotes on which of those parts each one names.
Why does an agent task cost so much more than one reply?#
Each turn resends the whole transcript, so input grows with every tool result. In this guide's worked example at GPT-6 Luna's October 2026 rates, a ten-turn task with a 6,000-token prompt and 2,000-token tool results costs about 24 times one reply, not 10 times. Reasoning tokens are billed as output and add to that.
Does prompt caching fix the run cost?#
It helps on a repeated prefix and nowhere else. On OpenAI's API as of October 2026, caching is on by default, with a 1,024-token minimum on GPT-5.6 and later, where a cache read costs a tenth of the input rate and a write 1.25 times it. In this guide's example that takes the ten-turn task from about $0.018 to about $0.006. A retry that edits the early transcript pays full price again.
How do you stop a runaway agent before the invoice?#
Put a hard cap in the request path and check it before the next provider call. Cap the turns, the tool calls, the spend and the number of child agents, and make each child draw on the parent's remaining allowance. When any cap breaks, end the run and keep the partial result. An alert after the threshold has already paid for the calls in between.
Are cloud spend caps enough on their own?#
No. AWS spend limits and Google Cloud Spend Caps, both announced in 2026, pause a project or a service once a monthly amount is reached. They are a useful backstop, but they act after many runs have spent, they cannot tell a retry storm from normal load, and they stop healthy runs along with the broken one.
How do you reconcile your meter with the provider bill?#
Sum what the provider invoiced for the period, and sum what your traces recorded for every attempt, including retries, timeouts and outputs you rejected. Compare the two before you call either one the cost of a successful task. A remaining gap is work you are not tracing, such as an eval job or a second service on the same key.
Further reading
- Agentic workflows vs AI agents. The test that keeps this bill from starting.
- How to build an AI agent. The build decisions in the order we make them.
- AI pilot to production. How the build is bought.
- LLM model migration. Why a model change can raise the run line while the per-token price falls.
- MCP authorization and LLM evaluation. Two parts of the build a thin quote leaves out.
- DevOps agent on a live AWS account, executive operations agent and prospect intelligence engine. The builds this guide draws on. None of them publishes a price.
- OpenAI, GPT-6 Luna, reasoning models and prompt caching, read 22 October 2026. Token prices, reasoning billed as output, reasoning carried across turns, and the cache threshold, read and write rates.
- AWS, Create a spend limit, and Google Cloud, Spend Caps on Google Cloud Budgets, 29 July 2026.
- Jatin Bansal, Agent Budgets and Runaway Prevention, 26 May 2026. The author-reported $47,000 incident.