What an Agent Actually Costs

Two ratios, and the reason the price list is not the story

The prompt is everything you hand the model to work from: the instruction, the question, the documents you retrieved, and the running conversation. The token is the unit the model reads and writes in, a chunk of text smaller than a word, roughly three-quarters of a word. A page runs several hundred tokens. Tokens matter for one blunt reason. They are the unit you pay in and the unit the model's attention is spent on.

Every call has a cost going in and a cost coming out, and those are not the same size. Two ratios carry almost all of the practical content, and unlike absolute prices they have held across vendors and across three years of price movement. Carry the ratios, not the cents.

Three takes from that table, and they outlast the numbers in it. The output-to-input ratio is five to six times everywhere, across three vendors and four tiers, which is why it is safe to build a mental model on. Price is a tier-selection criterion, not a vendor-selection one. Within a tier the vendors sit within noise of each other, so choosing a provider on cents is optimizing a rounding error. Choose on eval performance for your task and on latency, then take cost out by moving work down a tier. And the step between adjacent tiers is roughly five times and the span from top to bottom is roughly ten, like for like, which means the decision that moves your bill is not which flagship you use. It is how much of your traffic never needs one. The larger multiples quoted around this market, thirty or fifty times, are almost always comparing one tier's output price against another tier's input price. Check the units before you repeat one.

Where the platform exposes a reasoning-effort setting alongside the model choice, treat the pair as the unit of the decision. A mid-tier model at high effort and a flagship at low effort are different points on the same curve, and for a task class you have eval coverage on, the cheaper point is often good enough.

Two things do not show up on any price list and cost real money. Reasoning tokens: a reasoning model, or a standard model set to extended thinking, generates an internal chain of thought billed at full output rates that the user may never see; some providers expose the trace, all of them bill it. A dispute requiring the agent to work through contract terms, transaction history and policy exceptions can generate thousands of invisible tokens before a single visible word. And images: a scanned invoice is processed as an image, not as text, often equivalent to several hundred to several thousand text tokens depending on resolution. A customer who uploads a photo, a PDF and a handwritten note has consumed an order of magnitude more input than a text-only interaction before the agent has reasoned at all.

An agent does not call the model once

Reasoning depth. Extended thinking is not a free quality upgrade. It is an output-rate multiplier, and it should be decided per task class rather than set once for the product.

Context accumulation. Retrieved documents are billed as input on every call in the session. Retrieve a ten-page policy at the start of an eight-turn conversation and you pay for it eight times. Retrieval-augmented generation is not free retrieval; it is paid context injection, and the bill compounds with every turn.

Multimodal inputs. See above. The failure pattern is a business case modeled on text conversations meeting real customer behavior, which increasingly involves attachments.

Retries. The failed attempt usually stays in the context stream, so the second attempt costs more than the first and the third more than the second. The expensive part of a retry storm is the model re-invocation, not the failed downstream call.

Coordination. Published figures put roughly thirty-seven percent of tokens in a multi-agent system into coordination: re-establishing context, handing off state, resolving disagreement. A four-agent system can run about three and a half times the tokens of a single-agent system for the same outcome. Adding agents does not divide the work.

These do not arrive one at a time. A reasoning model handling a complex dispute across ten turns, with retrieved documents, customer attachments and a retried tool call, operates at a cost per interaction that bears no resemblance to the average anyone modeled. Model the compound case as a named scenario with its own frequency, not as a tail you will notice later.

What actually moves the number, and whose call each one is

Four of these are worth a sentence more, because they are the ones a PM decides rather than reviews.

Caching pays on traffic shape, not on architecture alone. The saving is real for sustained interactive sessions and largely absent for bursty, low-frequency work, because caches expire on short windows measured in minutes. The arithmetic is worth checking rather than taking on trust: cached reads run at roughly a tenth of base input price, while writing to the cache costs a premium over it, a little above list for a short window and roughly double for a long one, which is what puts break-even at the first or second read. It also requires a stable prefix: a system prompt that interpolates a timestamp, session ID or user name at the top invalidates the cache on every call. Put volatile content at the end, and do not book the saving in an estimate before someone has checked your inter-call gap.

Shortening the loop has the highest ceiling and no vendor. Nobody sells it. It requires reading the trace of one real task, naming every model re-entry, and arguing with each one. Classification steps often do not need a model. Formatting steps almost never do. Steps that exist because an earlier step returned something unusable are a schema problem wearing a cost costume.

How you write the success criterion is a cost driver. An unmeasurable or unachievable goal is a loop generator: an agent told to reach a target it cannot verify will keep trying, and an agent told to reach one that is unattainable will keep trying forever. Make the criterion measurable, make sure the agent has a tool that can measure it, and give it an explicit budget, because the agent has no price model and cannot self-regulate on cost. This is Executable Brief work, and it belongs to you.

Deciding not to use an agent is the largest number here. Deterministic automation costs about a tenth of a cent for routing against ten to twenty cents for an agent. When a problem can be written down in advance, writing it down is not the lesser solution. This applies inside a product as well as to the build decision: a hybrid that handles the predictable eighty percent deterministically and routes the residue to an agent is usually the correct shape, and it is rarely the shape a demo produces.

Two things you cannot model. Volume and committed-use discounts are negotiated case by case and unpublished, so treat any you win as margin rather than as an assumption. And pinning inference to a data-residency region costs about ten percent more, which is the one place a governance choice shows up as a line on an invoice.

The bill has no ceiling unless you build one

Two agents in a production research system started talking to each other. One analyzed, the other verified, and a misclassified error taught the pair to treat "we disagree" as "retry with different parameters" rather than "stop." They retried week after week, passing the full conversation back and forth, the weekly bill climbing from pocket change into five figures. Nothing malfunctioned and every dashboard stayed green, because the system was doing exactly what it was built to do at a rate nobody had capped.

An agent is not a batch job that runs a bounded operation and halts. It is a loop that re-enters the model, carries growing context, retries on failure, and calls tools that fail in ways that make it retry harder. Uncapped, it spends faster than a human review cycle can react.

A budget read after the call is an accountant. A budget checked before the call is a brake. Every runaway shares one mechanic: hundreds or thousands of paid calls go out before a human sees an alert.

Be precise about what the platforms do and do not give you, because the loose version of this claim is easy to refute. They do offer account-level monthly spend ceilings and budget alerts, and on two of the large clouds a budget policy can deny further calls once a threshold is crossed. What none of them ships is a per-agent, per-window ceiling evaluated before the call executes, which is the only control that stops one misbehaving agent rather than the whole account after the money is gone. Platforms enforce throughput, requests and tokens per minute; cost and consequence controls need business logic only you can write, because only you know what this agent is worth and what number should make a phone ring. The danger is not the gap. It is assuming the infrastructure is protecting you, shipping on that assumption, and finding out on a Saturday. A useful tell at a launch review: ask what the daily ceiling is and who gets paged when hourly burn triples. "We have a monthly budget alert" and a shrug means the agent has no brakes, only a receipt.

The comparison that decides it, in six lines

The break-even. An agent is worth its cost when the value of the task, times how often it runs, exceeds the fully loaded per-task cost: tokens times the architecture multiplier, plus the human supervision the agent still requires. Teams compare sticker price to an hourly rate and conclude the agent is obviously cheaper. Often it still wins. Sometimes, counted properly, it does not, and that is a finding worth having before you build.

The comparison is against the best alternative, not against nothing. The alternative might be traditional automation, a constrained non-agentic AI feature, or a human with better tooling. The agent has to beat that, not beat the empty field.

Which line dominates depends on volume, and it flips. At low volume the year-one floor dominates and the token bill is noise; arguing about model choice on a thousand tasks a month is arguing about the wrong line, and the real question is whether the fixed cost of running an agentic product properly is worth carrying at all. At high volume the multiplier dominates and the floor amortizes to nothing; there, architecture is the entire decision. Run the case at your projection and at half of it, because the two halves of that sentence give opposite advice and you need to know which side of the crossover you are on.

The 1.5x correction. Actual total cost of ownership runs forty to sixty percent above the initial case in typical deployments, because teams anchor on the vendor quote and miss orchestration, oversight, eval maintenance, and the model-update cycle that arrives every three to six months and costs a re-validation each time. Multiply before you present. If that makes the case fail, it was already failing and you found out cheaply.

Count the downstream rework. This is the line most often missing entirely. Where the agent's output requires more verification, correction or refactoring than the alternative's, that cost is real, it lands on a team that did not sign the business case, and no token meter reports it. For code-generating agents it can exceed the generation cost. Put a number on it or state explicitly that you have assumed it to be zero.

The multiplier does not transfer between task classes. Five to fifty for ordinary work, one hundred to five hundred for code. Benchmark your classification agent, extrapolate to your drafting agent, and you can be wrong by an order of magnitude. Measure per class. This mistake looks like diligence, which is why it survives review.

The brownfield inversion. In greenfield the floor is whatever the agent costs to run. In brownfield, replacing a step in a system that already works, the agent must beat the marginal cost of the human step and justify integration, change management and supervision that a greenfield build never paid. Meanwhile the licence component of that floor has been falling as platform vendors fold AI capability into base subscriptions, so the licence question and the loaded-cost question now move in opposite directions and have to be modeled separately.

Outcome-based pricing, where a vendor bills per resolved case rather than per token, simplifies the question to: at what resolution rate does this vendor stay profitable, and does that match what the workflow can accept? Where it is not on offer, you are holding the failure cost yourself, and that is its own line.

What to ask, and when

At the launch review

• The three ceilings, as three numbers: tokens per run and per window, requests per window, wall-clock per run. Enforced before the call or logged after it?
• Does the kill switch live outside the agent's runtime, and who is paged when hourly burn triples, by name?
• What is per-task cost at the trajectory level, including coordination overhead and human review time? If nobody can produce it, that is a finding about a surface nobody designed.