What an Agent Actually Costs

In June I put a day-old frontier model in my autonomous development platform's orchestrator seat and let the fleet run. One day of that fleet, at list prices, billed out around 1,450 dollars. The line item that matters: 92 percent of it was the model reading, not writing. The fleet read 1.06 billion cache tokens in a single day. Output for the same day was 2.2 million tokens, roughly 110 dollars at the model's launch pricing of 10 dollars per million input tokens and 50 per million output. Everything else was the reading.

The bursts are what actually catch you. The hottest twenty minutes of data-heavy work billed about 108 dollars at list. The hottest hour, about 289. Inside that hour was a ten-minute stretch that produced 196,880 output tokens, a 1.18-million-token-per-hour pace, during which I watched most of a five-hour usage window disappear.

I am publishing these numbers because almost nobody does. Vendors publish capability demos. Analysts publish adoption percentages. The actual unit economics of agents in production, what a task costs, where the money goes, what stops the spend, stay private, so every budgeting conversation happens in the dark. Here are mine, with the parts that are estimates labeled as estimates.

The bill was not the model being expensive. The bill was my harness failing to make cost explicit. The new orchestrator passed an explicit model parameter on zero of its 15 subagent spawns, so every builder silently inherited frontier pricing from the orchestrator seat. The previous orchestrator, on the same harness, had tagged 62 of its 96 spawns to a mid-tier model and 20 more to a standard one. Nothing about the new model's behavior was wrong. The default was wrong, and the default was mine.

It compounded fast. At one point I rejected a dispatch wave mid-flight because an earlier swarm of 37 agents had already eaten nearly three quarters of a usage window on its own. The untagged-spawn problem was visible on the usage graph the same afternoon it started, and the fix, a spawn-path rule forcing explicit cheaper-model delegation, shipped the same day. Cost of the wrong turn: most of a day of frontier spend doing work a mid-tier model handles fine, plus the afternoon it took to see it. Cheap, as tuition goes. It stayed cheap only because the telemetry to catch it already existed.

Break the day apart and the shape of agent economics gets clear.

Two things in that table run against the standard mental model. First, output, the thing everyone prices in their head, was eight percent of the bill. In a matched 101-minute window, the orchestrator's own writing was 155,575 tokens, call it eight dollars at list. The writing was never the problem. Second, verification, the part people assume is expensive overhead, rounds to zero model spend, because verification in my system is deterministic harness layers and scripts, not another LLM re-reading everything it can find.

Per outcome, honestly labeled: the day ran up to five concurrent orchestrator sessions, and feature build windows on this fleet run from 18.6 to 201 minutes. My internal estimate puts a delivered feature at 300 to 400 dollars of model spend at list, dominated by reading, before the delegation rules landed. That is an estimate, not telemetry. Features overlapped sessions, and some of the day's reading served analysis rather than shipping. I expect the number to fall by multiples now that builders run on cheaper models and subagents return summaries instead of raw data dumps, and I will publish the follow-up number when I have it.

The lesson I operationalized is that cost has to be a compile-time concern: a set of numbers the platform enforces before and during every run, rather than a dashboard you check after the invoice arrives. Here is the current constitution, defaults straight from the code.

Hard stop is the default, not the option: the budget policy ships with hard_stop_on_budget set to true, and the budget decrement is a single atomic UPDATE with the authorization in the WHERE clause:

UPDATE app_state.agent_identities
SET budget_remaining_usd = budget_remaining_usd - :amount,
    total_cost_usd = total_cost_usd + :amount
WHERE agent_id = :agent_id
  AND is_active = true
  AND budget_remaining_usd >= :amount

If the remaining budget cannot cover the spend, the update matches zero rows and the call fails. The agent cannot spend money it does not have, even under concurrent access, because the arithmetic and the authorization are the same statement. And one loop carries a stranger rule I have grown fond of: it is required to get cheaper as it learns. Cost per resolved case at the third iteration must come in at or below 85 percent of the first, or the test fails. That gate currently proves itself on synthetic rows, which I have said plainly before: it proves the gate fires, not that a live loop hit the 15 percent in production.

Behind the enforcement sits a rate card, six model families with Decimal per-thousand-token prices for input and output, so estimated cost is computed the same way everywhere and quantized to six places. One known wart, disclosed rather than hidden: a model the rate card does not recognize estimates to zero dollars. That is a blind spot I have already been burned by once, and it is on the list. A cost model with a documented hole beats a cost model that does not exist, but only if you keep the hole documented.

The other half of cost control is routing, and the principle is visible in one file. The platform's model configuration maps nine chat use cases to models, and every single default is a local open-weight model served on my own hardware. Complex reasoning defaults to a 35B mixture-of-experts model. Fast processing, lightweight classification, and SQL generation share a 26B model, partly to reduce model swaps under memory pressure, with SQL forced to temperature zero. Frontier models enter as overrides, per use case or per invocation, through an explicit priority chain. You opt into expensive. You never drift into it.

That default is earned, not ideological. My 84-prompt planner-intent eval, three passes per model: the best frontier model won at 99.6 percent accuracy and 0.368 dollars a run; a small paid model hit 97.0 percent at 0.047; my free local model hit 96.7 at 0.00; and the most expensive model in the cohort scored 94.6 percent at 0.524 a run with five times the latency. On that task, paying ten times more bought nothing. The eval engine also refuses to blend its verdicts: it reports a quality winner and a cost winner separately, because the decision of which to ship should be a visible trade, not a weighted average that hides one.

The routing principle and the budget principle meet in one sentence from the orchestrator experiment: frontier tokens are for judgment, cheap tokens are for volume. The frontier model keeps the orchestrator seat because judgment compounds through everything below it. Builders, sweeps, classification, formatting, extraction run on the cheap tier because their failure modes are caught by verification anyway. Getting that split wrong in either direction is expensive: frontier everywhere burns money on work a 26B model does fine, and cheap everywhere puts a weak model in the one seat where its mistakes multiply.

Go back to the 92 percent. If reading dominates the bill, then context policy is cost policy, and most teams have neither. My compiler carries per-model context budgets: 180,000 tokens for the large frontier tier, 90,000 for the small tier, 120,000 for the mid family, 30,000 for local serving, and 90,000 as the unknown-model default. When accumulated history exceeds the budget, a guardrail trims the oldest conversational turns deterministically, always preserving the system prompt, tool-call rounds, and the ten most recent turns. It exists to trip before the provider throws a context-overflow error, and it doubles as a spend ceiling per call.

The fleet rules that came out of the 1,450-dollar day point the same direction. Subagents must return summaries and outcomes, never raw data dumps into frontier context. Mechanical sweeps, log parsing, transcript grepping, aggregate queries, go to deterministic scripts or lighter agents that produce the same answer at a fraction of the price. Frontier context is for judgment. Everything else is a reading bill you chose not to prevent.

I will close with the failure that started this whole accounting discipline, because it is the least flattering number I have. I pointed a token-accounting harness at 3,898 of my own agent transcripts. It reported that cache reads were 95.32 percent of all token volume, consistent with everything above. Then it reported one more line: archives with explicit cost records, zero. The system was spending money it was not writing down. Every meter described in this article exists because that number was zero once, and the audit callback now counts every agent LLM call and logs an estimated cost to four decimal places when the session closes.

For the board slide: agents are opex with a throttle, and they should be budgeted like metered infrastructure, not licensed like seats. A seat is a fixed cost that bills whether or not work happened. A governed agent identity on my platform has a worst case: 25 dollars a day, hard-stopped, about 775 dollars a month if it maxes the cap every single day, with an audit trail showing exactly what it produced for the money. That inverts the conversation from how many licenses to what an outcome costs: cost per delivered feature, per generated insight, per resolved case. MIT's NANDA group made headlines saying 95 percent of GenAI pilots show no P&L impact. I believe it, and I suspect most of those pilots could not name a single cost-per-outcome number either. You cannot show P&L impact in a unit you never measured.

So the position I will defend: cost is a compile-time concern. Budgets belong in the manifest, enforcement belongs in the runtime, and a spend number nobody enforces before dispatch is just an invoice with a delay. I would no more deploy an agent without a hard-stop budget than deploy a service without a memory limit. An agent without a kill-price is not production software.