The refactor that took 22 turns
A coding agent given a 40-file refactor task runs 22 tool-call turns before it produces a mergeable diff. Turn 1 sends the original prompt and repo context. By turn 14, the transcript being resent on every call has grown to several times that original size, because every prior tool result, every file read, every failed attempt stays in context. Turn 14 also happens to be where a tool call returns a parse error on a malformed file path. The agent retries the whole turn.
That single retry rebills the entire accumulated transcript up to that point. Depending on how fast the context grew, that one retry can cost more in tokens than the first ten turns combined. Nobody sees this in the listed per-million rate on either model’s page. It shows up only when you tally the actual run.
This is the gap between the number on a pricing table and the number on your invoice, and it’s why comparing Grok 4.6 against Claude Opus 5 on headline rates tells you almost nothing about which one is cheaper for an agent workload.
Where the multiplier comes from
Chat-style pricing assumes one prompt in, one completion out. Agent loops break that assumption three ways:
- the transcript resent on every turn grows monotonically, so input token count compounds across the run, not just once
- reasoning models spend hidden tokens on chain-of-thought before producing a visible tool call or answer, and those tokens usually bill at the output rate
- failed tool calls, malformed JSON, and validation errors force retries that rebill whatever context had already accumulated
None of this is specific to Grok 4.6 or Claude Opus 5. It applies to any reasoning-capable model doing multi-step tool use. What’s specific to these two is how each one trades off the three factors, and that tradeoff is exactly what a listed per-token rate can’t show you.
Grok 4.6 and Claude Opus 5 both default to extended reasoning on tasks that look complex, and neither publishes a fixed cap on how many hidden reasoning tokens a given request burns. That ratio isn’t static metadata you can look up once. It’s telemetry that comes out of your own traffic, and it moves with prompt complexity, tool count, and how aggressively each provider tunes reasoning effort this month. Pull current per-token rates for both from the model comparison page before running any of this math, because whichever number you memorized last quarter is already stale.
Fast tier isn’t automatically cheaper
The trap is assuming Claude Opus 5 Fast wins by default because its listed rate sits below full Opus 5. That’s true per token. It’s not necessarily true per completed task.
A faster, shallower reasoning tier finishes each individual turn cheaper, but on a task hard enough to need deep reasoning, it’s also more likely to misread a diff, miss a dependency, or return a tool call that doesn’t validate, which means more turns and more retries to reach the same mergeable diff. If Opus 5 Fast needs 30 turns to do what full Opus 5 does in 22, and each of those extra turns rebills a transcript that’s already grown large, the cheaper-per-token tier can lose on total task cost. Same mechanism as the parse-error retry above, just spread across more of the run instead of concentrated in one turn.
The fix isn’t picking a side. Measure your own turns-to-completion and retry rate for the specific task class you run, then multiply that against current rates for both tiers using the breakeven calculator.
What differs between Grok 4.6 and Claude Opus 5
Where Grok 4.6 and Claude Opus 5 genuinely diverge is in how their input and output rates are split, and how each provider prices long context. A model with a wide input-output rate gap rewards workloads with lots of short tool calls against a long resent transcript, since most of the bill sits on the input side. A model with output priced closer to input rewards workloads with heavy generation, like long reasoning traces or big diffs. Which pattern your refactor task falls into depends on how much of each turn is context versus generation, and that split is exactly what you should be logging already.
Provider spreads for the same open models routinely run past 20x between cheapest and priciest host, visible on any model’s page on the model index and tracked over time on the trends page; closed frontier models like these two don’t carry that same multi-provider spread, since each is generally sold by a small number of API vendors rather than an open marketplace. Check current provider listings for both before assuming either one only has a single source.
What this guide can’t know is your own reasoning-token ratio and retry rate on your actual task class this week, because that number is a function of your prompts, your tool schema, and whichever reasoning-effort default each provider ships today, not something derivable from a spec sheet.
The decision rule
Log turns-to-completion and retry count for your last 50 agent runs on whichever model you’re running now. Multiply that turn count against current input and output rates for both Grok 4.6 and Claude Opus 5 (and the Fast tier if it’s in scope) through the calculator, using your measured transcript growth per turn rather than a single prompt-and-completion estimate. Route to whichever model wins on total tokens billed per completed task, not per token. If your retry rate on the cheaper tier is anywhere near your retry rate on the pricier one, the pricier one is probably winning already and you just haven’t measured it yet.