In its official cost guide, Anthropic offers a strategy for model selection: do not compare models by price per token, but rather look at the cost per solved task. From this perspective, you will find that models that look expensive on the price list are often cheaper in practice. For instance, on the software engineering benchmark SWE-bench Pro, setting Fable 5.1’s effort to low solves 88.6% of the problems at a cost of $0.54 per problem. In contrast, using Sonnet 5 with default settings only solves 77.4% of the problems, yet costs $0.84 per solved problem. Although the unit price differs by roughly 5 times, overall, the more expensive model is cheaper.
When bills get high, many teams’ first reaction is to swap certain steps to a model with a lower unit price. This intuition assumes that cost stems from unit price. However, in real agent workloads, this assumption does not hold. More capable models often accomplish the same task with fewer turns, fewer tool calls, and fewer retries, and the saved workload directly offsets the difference in unit price.
When thinking about inference costs, people intuitively check the unit price on the pricing table. But when you ask an agent to fix a bug or generate a report, you are buying a concrete result, not characters billed by word count. An agent’s workload is entirely different from a standard text completion API; the bill should be calculated by results, not by unit price.
A set of data in Anthropic’s cost and intelligence optimization documentation illustrates this point. When viewed per solved task, a completely different picture emerges. Under the default configuration, Opus 5.5 can solve 92.8% of the tasks at only $0.22 per solved task. Fable 5.1 can also solve 92.3% of the tasks, but requires $1.19 per solved task. Note that Fable 5.1’s price per token is noticeably higher ($10 / $50 compared to Opus 5.5’s $4 / $20). Yet here, within the noise margin of accuracy, the more expensive model yielded no better results—instead, the cost per task was roughly five times higher.
Model iterations follow the same pattern. According to tests in the documentation, switching from Sonnet 4.6 to Sonnet 5 improved the solve rate by 5 percentage points, while reducing the average cost per solved task by 15%; upgrading from Fable 5 to Fable 5.1 delivered comparable problem-solving performance while cutting the cost per solved task by 43%.
However, switching to a stronger model does not mean your bill will drop automatically. On another benchmark in the documentation, DeepResearch Bench II, setting Fable 5.1’s effort to high resulted in an accuracy 2-3 percentage points higher than the previous generation, but the cost per solved task increased by 41%. Whether single-task cost can be reduced depends not on how capable the model is, but on whether the model’s workload in such tasks can be contained.
Expensive models can beat cheap models on cost per task because the way agents operate neutralizes the impact of the nominal rate. With every turn an agent runs, it accumulates a layer of state, and in the next turn, the entire conversation history, tool definitions, and system prompts must be resent to the model. A task that runs for 40 turns effectively sends the first turn’s content 40 times. Without optimization, input tokens grow quadratically with the number of turns.
In production environments, prompt caching carries the vast majority of repetitive content. Anthropic published a dataset from its first-party API: observing over 100,000 organizations across 14 consecutive days, in agent loops, the median share of tokens read from the prompt cache among all input tokens was 84.2%, with the upper quartile at 91.7%. In coding organizations, the median was 88.5%, rising to 90.9% when single-task tool calls exceeded 25, and exceeding 95.9% in the top decile of organizations. Once a task reaches deep stages, less than 1% of input tokens in a well-designed agent loop need to pay full price.
However, cache reads are substantially cheaper. For standard models, a cache read generally costs only one-tenth of the input price; for Opus 5.5 and Sonnet 5.5, it is one-twentieth, and for Fable 5.1, it is even just one-fortieth. Because cache defaults to living for only 5 minutes, while agent turns are often just seconds, virtually every turn benefits from this discount. Consequently, that intimidating input unit price on the price list is, in practice, mostly multiplied by a decimal discounted to 10% or even 2.5%. What truly determines the bill is how many turns the model runs and how many tools it calls, not the sticker price.
Therefore, switching models mid-session to save money often backfires. Because prompt caching requires prefixes to be byte-for-byte identical, swapping to a cheaper model or changing system settings midway invalidates the entire cache immediately.
Anthropic conducted an experiment: breaking a prefix of 100,000 tokens once requires recalculating the entire volume at the write price. On Fable 5.1, this single hit costs $1.25, whereas a single read originally cost only $0.03—a 50-fold difference; on Opus 5.5 and Sonnet 5.5, the difference is also 25-fold. Switching models to save on the rate for a single step results in a cache break that incurs a rewriting cost tens of times higher.
In contrast, adjusting the model’s workload is a far more convenient lever. Anthropic’s effort documentation provides five tiers: low, medium, high, xhigh, and max, controlling how much effort the model spends on thinking, writing text, and calling tools. More crucially, effort can be modified mid-session simply via a request header, without breaking the cache at all.
Combining the two, the intuition becomes clear: to save money, dialing down effort on the same model is vastly more economical than switching to a cheaper model, because switching models triggers a cache break, whereas tuning effort does not.
If adjusting effort on a single model is both convenient and cache-preserving, should we always set effort to the minimum? No. In empirical testing, the effect of effort exhibits two completely different behaviors across different tasks.
The first category involves research and knowledge extraction tasks. Anthropic tested Fable 5 across several retrieval and analysis benchmarks: WideSearch, DeepWideSearch, BrowseComp, and GDPval. The official default tier for these benchmarks is high; dialing effort downward leaves accuracy virtually unchanged, while costs steadily decrease.
For such research and knowledge extraction tasks, dialing effort from high to low only reduces accuracy by 1-3 percentage points, but saves one-third to one-half of the cost per solved task. The medium tier yields virtually the same accuracy as the default, at only 70%-87% of the default cost. Across all four benchmarks, the default high offers no measurable precision benefit compared to medium. Lowering effort is also faster: on DeepWideSearch, the time per question shrank from the default 7.9 minutes to 4.5 minutes. Forcing high effort on these tasks is purely a waste of compute.
The second category covers long-horizon engineering and complex coding, where the curve is steep. In tests with Opus 5.5 resolving code defects on SWE-bench Pro, the model’s default tier is medium, and its accuracy is heavily dependent on how much thinking and compute it is allocated. Medium is about 2.5 percentage points lower than high, with a cost that is 70% of high; dropping to low causes the solve rate to plunge by about 8 percentage points, from 95.3% on high down to 87.4%, while cost drops to about one-third, namely $0.11 versus $0.29; raising to xhigh adds about 1.4 percentage points to reach 96.7%, but the cost surges to $0.74, which is 2.5 times that of high.
Fixating on a single effort tier on a model wastes budget on research tasks, while suppressing it too low on long-horizon coding causes widespread failures.
For these steep tasks, if there is a clear verification signal (e.g., whether unit tests pass or code compiles), a clever approach is: run everything with low first, and re-run only the failed problems with high. On SWE-bench Pro, running all problems on high yields 95.3% at $0.29 per problem; running low first and then re-running failed problems brings accuracy up to 97.0% at only $0.17 per problem. The trade-off is running failed problems twice, but the benefit is passing most routine problems with cheap compute while reserving high effort strictly for genuinely difficult branches—saving nearly half the total cost while achieving slightly higher accuracy.
Since adjusting effort within a single model achieves the effects of cache and compute regulation, why bother with a model tiering architecture at all? Anthropic establishes a hard criterion in its documentation: for a model tiering architecture to be justified, it must first prove to be more cost-effective than lowering effort on the same model. Many seemingly sophisticated model tiering schemes turn out, upon simple mathematical comparison, to actually be more expensive than lowering effort on a single model.
Take the advisor pattern as an example. A lightweight executor runs the main loop, calling upon a smarter high-tier model as an advisor for guidance when stuck. To be effective, the capability gap between the two must be large enough, and the executor must actually ask for help.
The problem, however, is whether the executor will actually ask. This turns out to be the weakest link. Across the 198 questions of GPQA Diamond, the documentation tested Haiku 5.5 (running solo at 85%) and Sonnet 5.5 (running solo at 91%) as executors, with Opus 5.5 as the advisor. Across two rounds totaling 396 opportunities, the executor never asked once (0/396). Simply attaching the advisor tool definition added about 1000 input tokens per request, driving up Haiku’s cost per question by 12% and Sonnet’s by 25%, while scores remained identical to each executor running solo.
Worse still, once the executor is dialed to a lower effort tier in an attempt to cut costs, it often fails to even realize it is stuck, asks even less frequently, and performs worse than running solo. On another internal coding benchmark of 370 questions, the documentation tested Opus 5.5 as the executor and the frontier-tier Fable 5.1 as the advisor: it scored 1.7 percentage points higher than Opus 5.5 running solo on high effort, but the cost per attempt was 2.1 times higher ($2.92). This minor improvement is comparable to simply setting Opus 5.5 to xhigh, meaning the added architectural complexity did not yield better price-performance.
Another approach is the orchestrator pattern: using the most capable model for planning and decomposition, then handing off bulk granular tasks to cheaper workers. On routine tasks, however, this breakdown is equally uneconomical. On DeepWideSearch, running Fable 5 alone under low effort yielded identical accuracy to a composite architecture where it directed Sonnet 5, yet was 29% cheaper. The documentation’s conclusion was that simply lowering effort outperformed the entire architectural redesign.
According to official tests, the orchestrator pattern genuinely saves costs in only two scenarios:
First, buying insurance against the long tail of everyday costs. In many open-ended search or troubleshooting tasks, strong models occasionally get stuck in loops or overthink routine questions, and a tiny handful of these turns can consume the lion’s share of the billing cycle. Having the orchestrator offload routine tasks to cheaper models chops off that expensive long tail. In a test slice of BrowseComp, using Fable 5 plus 1 Sonnet 5 cut average costs roughly in half, dropped the 90th percentile from $33 to $12, and eliminated the extreme case where a single model ran up $84 only to arrive at the wrong answer.
Second, when the task is simply too large to fit in a single context window. Facing a massive defect triage across 14 public code packages and 21.6 million tokens, relying on Fable 5.1 alone would take 15-20 hours and cost $468-552; switching to 1 Fable 5.1 managing 25 Sonnet 5 models in parallel finished in 2.3 hours, reducing total cost by about 50% at the expense of a score 10-12 points lower.
If your work consists of a dependency chain, fits within a single context window, or is already satisfied by lowering effort on a single model, do not build multi-model architectures. The first step in model selection is always to sweep effort on your current model; only when a genuine capability gap is discovered should you price a stronger model running solo at low effort, treating that number as the benchmark threshold for all subsequent model tiering proposals.
This line of reasoning is sound, but its underlying conditions must be kept in mind: the data originates from Anthropic’s official technical guide, using their internal benchmarks, prevailing list prices at the time, and a 5-minute cache TTL. The documentation also explicitly states that these measurements are merely directional; do not apply them blindly to your own business without retesting on your own real traffic.
On another level, while the article provides technical advice, it also reflects the vendor’s own perspective. Anthropic notes in its official model selection guide that tuning effort is often more economical than switching models (“Tuning effort is often a better lever than switching models”). There are two layers behind this statement.
From an engineering perspective, the analysis of nominal rates versus activity levels, cache reads and writes, and cross-model cache breaks is sound. It accurately captures the primary drivers of agent bills and explains why downgrading models in long-turn contexts often costs more than it saves.
Yet from the platform vendor’s business perspective, effort is merely a compute dial defined inside their own product. Whether you tune it to low or high, your compute and traffic remain within Anthropic. Recommending their own model ensures you spend less, your system runs well, and you stay locked in. What genuinely harms the vendor is not when you dial a model’s effort from high to low, but when you migrate your entire orchestration to other models or even open-source alternatives.
How should this be put into practice? Do not blindly accept the conclusion of “no tiering, just tune effort.” Accept the reality that bills are determined by workload, and before building multi-model orchestration or routing traffic to cheaper models, map an effort curve for your primary model within your own workload. Treat its cost per task under low effort as a baseline; any model tiering proposal must first prove on your real balance sheet that it can beat this single-model baseline without paying the penalty of a cache break.