What a run really costs

The bill is never the model. It is the retry you did not notice, the context you resent forty times, and the planning step that runs a frontier model to decide which of three tools to call.

Attribute cost to steps

A per-run total tells you that something is expensive. Per-step attribution tells you which loop to fix. In practice the distribution is brutally uneven — one step is usually most of the bill, and it is rarely the one you would guess.

The four things that actually cost money

• Resent context. Every step replays the conversation. A run with thirty steps and a fat system prompt pays for that prompt thirty times. Trim it, or summarise the middle of long runs.
• Silent retries. A tool that fails intermittently can triple a run's cost while the success rate looks fine. Count retries in your metrics, not just outcomes.
• Over-modelled planning. Choosing between three tools does not need your most expensive model. Route per step.
• Re-derivation. Agents recompute things they already worked out. Cache tool results by argument hash within a run and the same lookup stops being billed twice.

Route models per step

The single biggest saving available to most teams: use a small fast model for planning, classification, and extraction, and reserve the expensive one for the step that writes or decides something. This is usually a three-to-five-times reduction with no measurable quality loss, and it takes an afternoon.

Set a ceiling and mean it

Give every run a hard budget. When it hits, halt and park rather than continue. Runs that hit the ceiling are almost always stuck in a loop, so the budget doubles as your best early-warning signal for a broken prompt.

Measure the thing you actually care about

Cost per run is the wrong denominator. Cost per successful run is the right one — an agent that is cheap and wrong is not cheap. Track both, and watch the gap: when it widens, something has started failing quietly.