Cost per task,
not per token
Anthropic's official documentation attaches a measured result to every cost lever. Once the unit of account becomes cost per completed task, several widely used ways to save money reverse: where outcomes are checkable, running everything at a low effort setting and re-running only the failures reaches the same pass rate for about half the cost; multi-model architectures saved money in only two measured situations; and lowering max_tokens saves nothing.
The documentation puts the free wins first
Anthropic's official platform documentation divides its cost controls into two groups: free wins that preserve quality, and tradeoffs that exchange cost for intelligence. Most of what it measures is an agent loop, where a model works through many turns with tools, though a few of the benchmarks are question answering. The page ranks prompt caching first by a wide margin.
A token is the unit used for metering and billing, roughly a word or half a word, with separate input and output prices. Every turn resends the system prompt, tool definitions, and all prior messages. A 40-turn task sends its first turn 40 times, so total task cost grows with roughly the square of turn count.
Caching does not stop this repetition. It changes its price. The cached material must form a prefix, the request content beginning at the first token, and matching is byte-for-byte, so a change invalidates that point and everything after it. A cache read, meaning a hit on stored content, is billed at 0.1x the input price. A five-minute cache write, which stores new content, is billed at 1.25x; a one-hour cache write costs 2x. The default cache lifetime is 5 minutes, and an agent loop's turns are seconds apart, so the discount applies to most tokens on every turn.
The issue-triage experiment makes the mechanism concrete. The model was claude-sonnet-5, running on a frozen snapshot of a large public repository and working through 20 real bug reports containing screenshots. Caching alone cut 83%, and caching plus input trimming reached 88%.
A longer variant processed 2.6x the tokens: its baseline cost $8.56, caching reduced that to $1.34, and one compaction event brought it to $0.83, a further 38%. Compaction summarizes earlier conversation once it grows too long so the loop can continue with a shorter history, and it needs a session long enough to trigger. The 20-issue run never reached the 50,000-token floor once its inputs were trimmed.
Three mid-task changes break the cache: changing effort, changing a task budget, and running context editing. The documentation puts all three at natural boundaries, followed by confirmation that cache reads have not dropped, and it sets a task budget once on the first request rather than changing it later. The request-structure design behind stable caching is covered elsewhere on this site and is not repeated here.
The Batch API is the next free lever for work that does not require an immediate response. It discounts every token by 50%, including cached tokens, with results delivered any time within 24 hours. It is unavailable for sessions on Claude Managed Agents, Anthropic's hosted agent runtime where sessions, sandboxes and billing sit on the platform side, because those sessions are interactive by design.
Context editing clears stale tool results to make room in the context window, but each clearing pass rewrites the cached conversation and works against prompt caching. In the run measured, it cost more than it saved. Its purpose is making room, not saving money, and the documentation favors a few large clearing passes over many small ones.
A prompt written for a previous model is a standing tax
Each model generation responds to prompts differently, so a prompt accumulates instructions added for a model no longer in use, typically "verify twice," "be maximally thorough," a mandatory step-by-step procedure, or a hand-rolled reasoning scratchpad. A newer model follows those to the letter, adding tool rounds and output without improving accuracy.
Anthropic measured this on a support-desk evaluation: 44 tickets, six prompts written for the older models, deterministic grading, with accuracy movements under about 5 points treated as noise.
| Configuration | Accuracy | Cost per ticket | What the step bought |
|---|---|---|---|
| Claude Opus 4.8 + old prompt | 89.5% | 2.52 cents | starting point |
| Claude Opus 5 + the same old prompt | 91.8% | 3.43 cents | 36% more no change in accuracy |
| Claude Opus 5 + audited prompt | 97.0% | 2.93 cents | 14% cheaper accuracy rose to 97% |
| Claude Sonnet 4.6 + old prompt | 81.1% | 1.72 cents | starting point |
| Claude Sonnet 5 + the same old prompt | 83.9% | 1.61 cents | accuracy difference within noise |
| Claude Sonnet 5 + audited prompt | 85.6% | 1.39 cents | 14% less same accuracy |
Swapping in the new model while keeping the old prompt cost 36% more per ticket than the old model on the old prompt, for no change in accuracy. After the audit, Claude Opus 5 was 14% cheaper than its unaudited version and accuracy rose from 92% to 97%, a gain outside the noise with a 95% confidence interval of 3 to 8 points. On the Claude Sonnet 4.6 to Claude Sonnet 5 migration the audit removed 14% of the cost at the same accuracy.
The two kinds of stale text have different costs, and the per-pattern measurements support that split: instructions the new model follows too literally cost money, while text that no longer fits the model costs accuracy.
Removing "verify twice" cut Claude Opus 5's cost per ticket by a third, and removing "be maximally thorough" almost as much. The retired thinking setting, the contradictory rules, and the hand-rolled scratchpad each restored 7 to 11 accuracy points on Claude Opus 5 when removed. The documentation notes that the same patterns appear in tool descriptions and skills, and are worth removing there too.
With the free levers exhausted, every remaining control trades quality for cost.
The unit of account changes the ranking
Price lists are written per token, and per token the frontier model looks expensive: Claude Fable 5's per-token price is several times Claude Sonnet 5's. What is paid for, though, is completed tasks rather than tokens. A more capable model finishes a task with less work: fewer turns, less searching, less re-reading of its own context, less backtracking. That reduction routinely overwhelms the per-token premium.
Anthropic measured this directly on a research-report benchmark. The DeepResearch Bench II 50-task subset was run three times and graded by Claude Opus 4.6.
| Configuration | Rubric score | Cost per completed task |
|---|---|---|
Claude Fable 5 · low effort | 60.2 | $0.76 |
| Claude Sonnet 5 · default | 56.0 | $0.84 |
The frontier model at low effort was more accurate and about 10% cheaper per task than the mid-tier model at its default, despite about 5x the per-token price. These runs predate Claude Opus 5, so this comparison contains no Claude Opus 5.
The reversal is not universal. On this page's SWE-bench Pro subset, where models edit real repositories and must pass their tests, Claude Opus 5 alone scored 91.7% and Claude Fable 5 alone 91.3%, a difference inside run-to-run noise, and Claude Opus 5 cost about 60% as much. The documentation therefore recommends Claude Opus 5 as the starting point for most agent workloads rather than the frontier model: per token it is half of Claude Fable 5 and 2.5 times Claude Sonnet 5, and on that coding subset it matched Claude Fable 5's accuracy.
The ranking flips by workload and no price list says which way, so every candidate has to be priced in cost per completed task on real traffic, including Claude Opus 5 and the frontier model at reduced effort.
The documentation puts pricing on the hardest tenth of the workload, not the typical task. On the typical task every model looks similar and the cheapest looks best, but the bill is decided by the tasks the cheaper model fails, because a failed task still bills its tokens, then the retry, then whatever the failure costs downstream.
Even with nothing failing, spending concentrates in the tail. Across 20 WideSearch problems run three times with Claude Fable 5, total cost was $421.
The first question is therefore not which model, but where the effort setting on one model should sit.
The effort dial has two shapes
effort is the most direct cost control inside a single model. It governs how much thinking, tool calling and self-verification the model performs at low, medium or high, and the default is served as high rather than as a separate setting. Cost rises with all of that activity, while accuracy rises only with the part a task needs. Below the model's capability ceiling, the highest settings pay for depth the task never uses.
The sweep produced two curve shapes, with opposite conclusions. The first is nearly flat, across research and knowledge work; the second, on long-horizon coding, is steep.
| Benchmark | low | medium | default |
|---|---|---|---|
| WideSearch broad web research into a many-row table | 78.5% / about $2.9 | 79.8% / about $4.2 | 80.0% / about $5.9 |
| DeepWideSearch many-row collection plus multi-hop retrieval | 64.9% / about $3.4 | 65.9% / about $4.6 | 66.4% / about $6.1 |
| BrowseComp whether browsing agents find hard-to-find facts | 78.5% / about $4.2 | 81.5% / about $5.3 | 81.3% / about $6.15 |
| GDPval economically valuable knowledge-work deliverables | 83.5% / about $1.45 | 84.0% / about $2.25 | 83.1% / about $3.2 |
All four swept with Claude Fable 5. WideSearch and DeepWideSearch are 3 runs per point; BrowseComp's chart says 3 runs while reference 4 says one to three runs per setting; GDPval is 1 run per point and its cost includes grading.
All four point the same way: low gives up 1 to 3 points for a third to a half of the cost per task, medium matches the default's accuracy at 70% to 85% of its cost, and the default buys nothing measurable over medium on any of the four. On BrowseComp and GDPval the default is not more accurate than medium, and on the chart its score sits slightly lower.
Lower settings are also faster, which matters when latency is the constraint. DeepWideSearch takes 4.5 minutes per problem at low against 7.9 minutes at the default, and on the corpus benchmark an episode takes 7.9, 9.1 and 11.4 hours at low, medium and the default. Anthropic also reports that low on DeepWideSearch matched an orchestrator using a Claude Sonnet 5 worker at 20% lower cost, so lowering effort beat an architecture change.
The second shape appears on long-horizon coding. On the SWE-bench Pro 482-problem subset, Claude Opus 5 at medium gives up about 2 points for half the cost and at low about 8 points for a quarter of it. That is a real tradeoff, not a free win. One parameter behaves categorically differently across the two kinds of work.
Some workloads reach the model's ceiling, and there every step buys score.
The task description alone does not identify which curve applies, so the method is to sweep two or three settings on a sample of real traffic and read the answer off the curve. Each setting needs its own session, because changing effort mid-session invalidates the cache and distorts the comparison.
Two consequences follow in the documentation. In these internal measurements, a multi-model configuration that looked cheaper than the default single model cost more than that same model at lower effort. And this single-model curve is the baseline any multi-model strategy has to beat.
The three output-side controls
effort governs how much work goes into a task; the output side governs how far that work is allowed to continue. Re-running failures, task budgets and max_tokens look like one family, but only the first two save money, and the dividing line is whether the model can see the constraint.
When outcomes are automatically checkable, a fixed setting is itself waste
The cheapest policy on the effort curve is not a fixed setting but running everything low and re-running only the failures higher. Claude Opus 5's points on the same SWE-bench Pro tasks are below.
16% of tasks failed at low. Re-running those at the default reached the default's pass rate at about half the price per task. The documentation adds one qualification: most of the small lift comes from having a second attempt rather than from the higher setting, because re-running the default's own failures at the default also reached 94.0% but cost $1.58. Use it for the saving, not the lift.
The second condition is latency: every first-pass failure consumes two runs of wall-clock time, so the saving is paid for in latency on the failures.
A task budget saves money because the model can see it
Most agentic runs are inexpensive, while a minority spend many times the median on additional searches, repeated verification and excessive testing, and the budget targets that tail. With a live token countdown for the whole task, the model trims low-value searches, skips redundant verification, and wraps up instead of spiraling.
A generous budget gave up about 2.7 points for an 18% saving, and the tightest allowed budget 4.4 points for 47%. Budgets bought efficiency here, not accuracy.
The documentation suggests starting near the loop's 90th-percentile token usage and then tightening. Budgets below the current 20,000-token floor are rejected, and very tight budgets can produce refusal-like behaviour. The budget is set once on the first request, because a mid-task change invalidates the cache. And it is advisory, steering the model rather than stopping it, so adherence has to be verified on the actual workload.
Lowering max_tokens saves nothing, because the model cannot see it
It caps a single response invisibly to the model, so lowering it does not make the model economize. The turns that needed the room are discarded and still billed.
The 16,384 cap ended 15% of Claude Opus 5's attempts and a third of Claude Fable 5's, and none of the truncated attempts were solved. The lower cap did reduce spending per attempt, but it solved proportionally fewer tasks, so cost per solved task was the same at both caps. At 64,000 nothing was cut off and Claude Fable 5 solved 54.6% instead of 33.3%; on a separate cut of the SWE-bench Pro subset it solved 92% instead of 90%.
The turn-length distribution explains how a seemingly generous cap makes that much difference.
A very small tail of long turns decides a large share of outcomes. Retrying a capped attempt only adds cost: at the same cap those attempts never succeeded, and at a higher one the wasted attempt is still on the bill. Anthropic's recommendation is to set max_tokens to 64,000 for agentic work and 128,000 at xhigh or max effort, stream responses that large, treat stop_reason: max_tokens as a failure, and leave saving to the two controls the model can see.
| Control | Visible to the model | What it does | On hitting the limit |
|---|---|---|---|
| Task budget advisory, beta | visible | the model converges on its own, so it saves money | steers rather than stops; adherence has to be verified |
max_tokenssingle-response cap | invisible | a safety cap against an unbounded single response, and saves nothing | returns stop_reason: max_tokens, treat as a failure |
| Session budget Claude Managed Agents | platform-enforced | a hard dollar stop at list rates for tokens, searches and session time | pauses with stop_reason: budget_reached, resumes when raised |
A session budget works on any model with a list price including Claude Sonnet 5, and combines with the advisory task budget. The documentation recommends setting all three with a workspace spend limit as the final backstop. All of these controls still operate inside one model. A second model enters only when tuning them is not enough.
When a second model is worth adding
Multi-model architecture is a common answer to cost, and Anthropic's own measurements support a more conservative reading. In the documentation's account, the approach fits workloads with uneven difficulty: routine steps stay with a lower-cost model while a frontier model handles the decisions that need more capability, which keeps most tokens billing at smaller-model rates. If difficulty is uniform, or the work forms one dependent chain, a well-tuned single model is usually the stronger baseline.
Two architectures are measured, distinguished by which model holds the main loop. In the advisor strategy a lower-cost executor runs the loop, asks a higher-intelligence advisor for guidance at difficult decisions, and then continues; the advisor tool provides this at the request level, with the executor emitting a tool call, Anthropic running the advisor inference server-side, and the advice returned without any orchestration code. In the orchestrator strategy the frontier model retains the loop, divides the task, sends partitions to lower-cost workers, and merges their results.
The advisor strategy: the gain tracks the consult rate
Two variables decide how much an advisor helps. The first is the capability gap, since an advisor can supply only capability the executor lacks: on GPQA Diamond a Claude Haiku 4.5 executor gained a great deal from a Claude Opus 5 advisor, a Claude Sonnet 5 executor gained a few points, and a frontier executor almost nothing.
The second is more fragile: whether the executor actually asks. The consult rate is the share of tasks on which it calls the advisor, and across six pairings the realised gain follows it closely.
When the executor did ask, the advisor closed 60% to 90% of the gap to the stronger model while that model was billed only for the consultations, which is what makes the cost cases possible. The last row is the counter-case: the same low-effort executor asked on only 7% of tasks and the pairing scored 5.4 points below the executor alone, because an executor at low effort can stop noticing it is stuck.
Prompting moves the consult rate. With only the tool's built-in description executors under-call, particularly on coding work, and the documented system prompt asks for one call before substantive work and one before finishing, about two to three calls per task. The rate has to be prompted for, measured, and watched.
On cost, the documentation is notably restrained. A few short consultations replace running the advisor's model for the whole task only when that model is priced well above the executor, which makes a frontier advisor over a mid-tier executor the most cost-effective shape. Two measured sets follow.
| Internal coding benchmark (370 repository tasks) | Solved | Per attempt |
|---|---|---|
| Claude Opus 5 executor + Claude Fable 5 advisor | 85.7% | $8.40 |
| Claude Opus 5 alone, default | 84.4% | $8.50 |
Claude Fable 5 alone, medium | 83.4% | $8.20 |
Claude Opus 5 alone, low | 74.3% | $1.9 |
Claude Opus 5 alone, medium | 82.1% | $4.5 |
Claude Fable 5 alone, low | 78.7% | $5.4 |
| Claude Fable 5 alone, default | 85.1% | $11.9 |
A plain API agent, August 2026. Five attempts per task at the default settings and for the pairing, one at the reduced settings. The pairing averaged about two advisor consultations per attempt. Differences of a point or two are within run-to-run noise.
| Chartography (chart reading) | low | medium | default |
|---|---|---|---|
| Claude Opus 5 alone | 49 / $0.38 | 75 / $0.94 | 79 / $1.95 |
| Claude Fable 5 alone | 55 / $0.81 | 73 / $1.44 | 74 / $1.74 |
| Claude Opus 5 at low effort + Claude Fable 5 advisor | 67.5 / $0.60 (its two runs scored 65 for $0.47 and 70 for $0.73) | ||
The complete released 100-question set from Surge AI, August 2026, on Claude Managed Agents, two runs per configuration pooled, with run-to-run spreads of 4 to 10 points.
The pairing was the most accurate configuration measured, but it sits only a point or two above the best of each model's own settings, which a single run does not separate from noise. The documentation asks that the result be read as a shape to test against one's own workload rather than as a saving, and places the cost case with pairings that have a wider capability gap.
That wider gap appears on chart reading, where the advisor beat raising the executor's own effort. On Chartography, low-effort Claude Opus 5 with a Claude Fable 5 advisor scored 67.5 for $0.60 per task, above the line through either model's own effort settings, where Claude Opus 5 alone moves from 49 at $0.38 to 75 at $0.94. The executor's own medium and default settings still hold the top scores, at 1.6 and 3.3 times the pairing's price. The low-effort executor in this pairing consulted on 86% of tasks, the condition the SWE-bench Pro pairing failed to meet.
The advisor strategy suits work whose turns are mostly mechanical but whose plan matters, including coding agents, computer use, and multistep research pipelines. It fits poorly when every turn genuinely needs frontier capability, when there is nothing to plan, or when the executor already approaches the advisor's capability.
The orchestrator strategy: the saving lives in the routine tail
The orchestrator saved money in two measured situations. The first is insurance against the cost tail on routine work. A frontier model running alone occasionally spirals on a routine problem it would normally solve, and because those runs cannot be identified in advance, a few of them dominate the bill. Handing routine work to a lower-cost worker caps that tail, because any spiraling now happens at worker rates.
Anthropic describes delegation as costing a little under half of the solo model on average and about a third at the 90th percentile; by the expected values in the table, $6.45 against $11.99 is about 54% of solo, which is a little over half. The counter-intuitive part, as the documentation puts it, is that delegation paid on the routine, normally solvable share of the work, the opposite of the intuition that workers are for hard problems. The boundary belongs in the same breath: on the full, harder BrowseComp set the economics reversed.
The second is work larger than one context window, the amount a model can read in one pass. A solo model must process such material serially, paying to re-read its own state on every pass, while workers each read their own partition in parallel at worker rates. Anthropic built a benchmark for this case: a 21.6-million-token corpus drawn from 14 public Python package sources with 130 planted defects and deterministic grading.
Lowering effort cannot help here, because the bill is reading the 21.6-million-token corpus itself: Claude Fable 5 alone cost $720 to $764 per episode at every effort setting, and only its accuracy moved. The coordinator configuration cost 55% less than any of those Claude Fable 5 solo settings and scored 3 to 7 points below Claude Fable 5 at medium or the default, while beating a Claude Sonnet 5 solo baseline outright.
The token accounting shows why. The coordinator configuration read 32 million input tokens against the solo model's 14.5 million and still cost less, because partitioned reading at worker rates is cheaper than repeated re-reading at frontier rates. Claude Fable 5 at the default still holds peak accuracy, at 2.3 times the coordinator configuration's cost, so delegation here buys most of the accuracy rather than all of it.
F1 balances completeness against precision in finding the planted defects, and its absolute value is specific to this corpus build.
An orchestrator buys something only when there is genuine bulk to hand off, ideally more than one context window of it. For one dependent chain, or work that fits in a single context, it pays for a plan, a handoff and a merge that a single model gets for free. On the full, harder BrowseComp set the frontier model alone reached the coordinator configuration's accuracy at 22% to 30% lower cost. Across every case of this kind that was measured, the coordinator's model running alone at lower effort came out ahead. The documentation also references an external study on scaling agent systems, cited only for the direction of the finding and not for any figure.
The order of evaluation follows from that evidence. Sweep the current model's effort settings first, the cheapest experiment on the page, where most workloads end. If a gap remains, price the stronger model alone at low effort, since that is the number a pairing has to beat, and the pairings on this page that beat it were the ones whose executor actually consulted. On adoption cost, the documentation notes that adding an advisor is a tool definition rather than a rearchitecture.
Measuring it on real traffic
These readings come from July and August 2026 at the list prices then in effect, and they will drift as models and prices change. Escalation rates, how cleanly tasks split, and transcript length move them too. The documentation's method stays the same, in four steps.
Sample real traffic and define an outcome check
Pull tasks from production logs in proportions that reflect real traffic, write an outcome check for each (tests pass, ticket closed, row count correct), and record cost per task beside the score.
Baseline the model tiers across effort levels
Not only the default. Plot score against spend. A multi-model configuration has to beat the single model's whole curve.
Add architecture only where the curve leaves a gap
If the curve exposes a gap that effort cannot close, add the multi-model strategy that fits and re-run the suite.
Shadow the winner, then keep the suite running
Run the winner in shadow on a traffic slice before cutover, then keep the suite running.
Cost per task is the sum across the task's requests of the four token counts reported in each response's usage, each at its own rate: input at the input price, five-minute cache writes at 1.25x the input price, cache reads at 0.10x, and output at the output price. The worked example uses Claude Opus 5 list prices.
# Per-million-token prices from the pricing page;
# change these two for another model.
INPUT_PER_MTOK = 5.0 # Claude Opus 5
OUTPUT_PER_MTOK = 25.0
usage = response.usage
cost = (
usage.input_tokens * INPUT_PER_MTOK
# Cache writes bill at 1.25x the input price (5-minute cache); cache reads at 0.1x.
+ (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
+ (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
+ usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
The documentation adds one self-check: in an agent loop the cache-read term is usually the largest of the four, and if it is not, caching should be checked.
With the advisor tool or compaction enabled, some tokens are reported only in usage.iterations and not in the top-level totals, so the sum has to run over usage.iterations, with advisor_message entries priced at the advisor model's rates.
The page closes with a table of levers in the order to try them, ordered free wins first, tradeoffs next, multi-model last. The readings will drift; the method will not.
Methodology and provenance
All measured results are Anthropic-internal runs of these benchmarks, not third-party reproductions and not invoice amounts; charts labelled notional USD price each request's token counts at list rates. Unless otherwise noted, costs are at August 2026 list prices, with Claude Sonnet 5 at $2 and $10 per million input and output tokens. The page itself states the results are directional and not guarantees.
| Benchmark | Comparability limit |
|---|---|
| SWE-bench Pro | Uses a 482-problem subset selected for compatibility with Anthropic's evaluation harness, and its scores are not comparable to the public leaderboard; the max_tokens figures use a further 100-problem subset stratified from it, whose scores are not comparable to the 482-problem set either |
| Chartography | Graded by Claude Sonnet 4.6 and run with tools, so its scores compare configurations on this page but not to the published leaderboard |
| GDPval | Graded by a Claude model, so absolute scores may differ from published results |
| DeepResearch Bench II | Graded by Claude Opus 4.6 where the original benchmark uses a different judge, and an Anthropic judge may favour the house style; those runs predate Claude Opus 5, which is why the model comparison contains no Claude Opus 5 |
| The corpus benchmark | Its absolute F1 is specific to that corpus build |
Run counts. On SWE-bench Pro, Claude Opus 5 at the default effort is the mean of two runs while the reduced settings are single runs; the max_tokens 64,000 figures are single runs; the internal coding benchmark is one run per configuration; GDPval is one run per point.
Both are official text and there is no way to tell which governs, so neither is adopted as settled. Neither affects any point value.
① The task-budget chart's footnote says 35k = mean of two runs, while reference 3 says the task-budget figures are one run per budget. Reference 3 separately states that every budgeted run completed all 482 problems without harness errors.
② The advisor-mechanism chart's footnote says SWE-bench Pro and the coding tasks are one run per configuration, while reference 3 splits the two SWE-bench Pro pairings: the default-effort pairing was run twice (a run and an exact replication) and the low-effort pairing once.
Noise bands. On the support-desk evaluation, accuracy changes under about 5 points are within noise, the Claude Opus 5 accuracy gain has a 95% confidence interval of 3 to 8 points, and the Claude Sonnet accuracy differences are within noise. On the triage run, differences of about $0.10 are noise. Chartography's run-to-run spreads were 4 to 10 points. On the corpus benchmark, $720 to $764 is inside seed noise. On the internal coding benchmark, differences of a point or two are within run-to-run noise.
Two BrowseComp slices, not interchangeable. The cost-insurance figures use ten problems the solo model reliably solved, drawn from a 26-problem slice, with delegated costs carrying a measurement band of about 20%; the effort figures use a 500-problem cut.
External citation. The external study on scaling agent systems (Kim et al.) is cited for the direction of the delegation finding only, and the source explicitly does not draw any figure from it.
Implementation differences. The DeepSWE pairings used a client-side advisor loop rather than the advisor tool; the Chartography consult-rate comparison came from rerunning the same configurations on the Messages API with a container tool set.