The Real Cost of an Agent: A Token Economics Field Guide

Danny Portman · June 16, 2026 · 5 min read

← All essays

When teams estimate what an LLM agent feature will cost, the usual method is to look up the per-token price, multiply by a guess at tokens per request, and arrive at a number that's wrong by 10x. Always in the same direction, too. The error isn't in the price sheet. It's in the mental model: per-call pricing tells you almost nothing about what an agent costs, because agent spend is dominated by two things no price sheet shows. Context growth, and retries.

Anatomy of an agent's token bill

An agent is a loop, and the defining property of the loop is that every step re-sends the conversation so far. Cost is quadratic-ish in steps, not linear. Three mechanisms do the damage.

Context accumulation. Step 1 sends the system prompt and the task. Step 10 sends the system prompt, the task, and nine steps of tool calls and results, and pays for all of it again. A 12-step run isn't 12 calls at demo prices. It's 12 calls whose average size is several times the first one.

Tool-result bloat. In the bills I've actually audited, this is the single biggest line item. A tool "returns the customer record": all 40KB of it, of which the agent needed four fields. That blob rides along in context for every remaining step, billed each time. One chatty tool can quietly double the cost of every run it appears in, and nobody notices because each individual call looks normal.

Retry storms. A malformed tool call triggers a retry. A validation failure triggers a re-plan. A stuck agent tries "one more approach" four times. Every retry re-sends the full accumulated context. Failure modes and cost modes turn out to be the same thing, which has a useful corollary: a cost spike is one of the best production alarms for an agent bug you haven't found yet.

The four levers

The levers compound. Pruning shrinks what tiering's cheap models have to read. Caching pays off more when the stable prefix is a bigger share of each call. Teams that pull all four routinely land 5–10x below their naive baseline with no measurable quality loss, and the reason is worth understanding: none of these levers touch the model's reasoning. They only reduce what it's forced to re-read and re-say.

One rule before touching any of them: instrument first. Per-step token accounting in your traces, before optimizing anything. Every agent bill I've looked at had one dominant term. It was a different term each time, and it was never the one the team guessed in the meeting.

The back-of-envelope worksheet

Before building an agent feature, estimate its unit economics honestly:

cost_per_run ≈ steps
             × (avg_context_tokens × input_price
                + avg_output_tokens × output_price)
             × retry_factor        # 1.2–1.5 if you're honest

monthly     = cost_per_run × runs_per_day × 30

Worked example. A 10-step agent averaging 8K context tokens per step and 300 output tokens per step, on a frontier model at $3 per million input tokens and $15 per million output, with a 1.3 retry factor, comes to about $0.37 per run. At 2,000 runs a day, that's roughly $22K a month, for a feature everyone in the planning meeting eyeballed at "a couple thousand." Now rerun the numbers with pruning bringing average context to 3K, half the steps moved to a model at a tenth the price, and caching on the prefix. It lands around $4K. Same feature, same quality bar, maybe an afternoon of engineering.

When the numbers say "don't build the agent"

Sometimes the worksheet delivers a verdict nobody wants: the agent costs more per run than the task it automates is worth. Before abandoning the feature, question the loop. A surprising fraction of "agent" workloads are pipelines wearing an agent costume. The same three tools, called in the same order, on nearly every run, with a frontier model improvising the sequence each time at ten times the cost of hardcoding it.

The test I use: if the p90 successful trace shows the same tool sequence, build that sequence as a plain pipeline with a model call only at the genuinely uncertain points, and keep the full agent loop for the tail of cases the pipeline can't classify. This pairs naturally with the step caps from the boundaries essay: the traces that keep hitting the cap and the traces that should have been a pipeline are usually the same ones.

Agents earn their cost when they handle genuine variability. Spend the money there. Not on re-reading a 40KB customer record eleven times.