The multiplier hiding in plain sight
A chat session sends one prompt, gets one answer, done. An agent sends the same opening prompt, then resends the entire transcript so far on every tool call: the original prompt, every file it read, every command output, every partial diff. By the time it finishes a task, the model has re-read its own history a dozen or a hundred times. Chat pricing per million tokens tells you nothing about what that costs.
The shape is predictable once you see it. At 5 tool-call steps, a typical agent loop bills roughly 3x what a single chat turn would cost for the same amount of new information. At 50 steps, that multiplier is past 30x. Push into a long autonomous session, the kind that debugs a test suite or refactors a module over 100+ tool calls, and you’re past 100x. None of that shows up on a $/M token comparison, because the token count itself is what’s exploding, not the rate.
Why steps multiply cost, not add to it
Say each tool call appends roughly 600 tokens of new material: a diff, a test failure, a file listing. Step 1 bills 600 tokens of input. Step 2 bills the first 600 plus the new 600, so 1,200. Step 40 bills roughly 24,000 tokens of input, just for that one call. Sum that across all 40 steps and the session bills something close to 480,000 input tokens, even though the user only ever reads one final patch. The output tokens barely move. The input tokens are what’s growing, quadratically-ish with step count, because every step re-reads all the previous ones.
This is why cost-per-completed-task is the only unit worth tracking for agent workloads. A model that’s cheap per million input tokens but needs 80 steps to finish a task loses to a pricier model that finishes in 25. The step count is the exponent; the per-token rate is just the base.
Caching changes the exponent, not the incentive
Prompt caching is supposed to fix this. If the provider recognizes that steps 2 through 40 share an identical prefix with step 1, it should bill the repeated part at a fraction of the fresh-token rate, turning the quadratic growth back toward linear. But caching is a provider-side feature, not a model-side one, and support is inconsistent even for the same open model across different hosts. Check the provider comparison before assuming your agent framework is getting cache discounts at all. If it isn’t, the growing-transcript math above is exactly what you’re paying, in full, every step.
Compaction caps the growth, caching doesn’t have to
The other lever is context compaction: instead of resending the raw transcript forever, the agent periodically summarizes the last N steps into a shorter note and drops the raw tool output. This caps context size at a ceiling instead of letting it grow with every step, which converts an unbounded multiplier into a flat one. It’s an architecture decision in your agent framework, not a provider setting, so it doesn’t show up in any pricing table. It’s also the single biggest lever you control directly, more than model choice.
The trap: cheapest per-token isn’t cheapest per task
The instinct is to route agent traffic to whatever model has the lowest input price on the model comparison tables. That’s backwards if the cheap model needs more retries to get a tool call right. Every failed tool call is a step, and every step rebills the whole transcript. A model that’s 20% pricier per token but reliable enough to finish in 30 steps instead of 45 wins on total task cost, even before you touch caching or compaction. This is the actual reason agent-tuned models like Kimi K2.7 Code, GLM-5.2, and DeepSeek V4 Flash get recommended for tool-heavy workloads: not the sticker price, but tool-call reliability that keeps step counts down.
Provider spread makes this worse if you’re not careful. As of this writing, the cheapest-to-priciest gap for models like GPT-OSS 120B runs past 20x on this site’s live tables. Layer a 30x agent multiplier on top of a 20x provider spread and picking the wrong host for your agent traffic isn’t a rounding error, it’s the difference between a workload that’s sustainable and one that isn’t.
What this guide can’t tell you
Your actual step count and transcript growth rate depend on your framework, your task complexity, and how aggressive your compaction settings are. Nobody’s pricing table captures that, because it lives in your traces, not the model’s spec sheet.
The rule
Before switching agent models to chase a lower $/M rate, pull real traces from your current workload: average steps to completion and average transcript growth per step. Run those numbers through the breakeven calculator against candidate models and providers. If your step count is under 10, per-token rate dominates and the cheapest reliable model wins outright. If it’s past 30, reliability and cache support dominate and per-token rate barely matters, because you’re paying that rate dozens of times over on every session.