Source: wiki synthesis: The Advisor Strategy, Coordinator-Pattern Cost, Checker, Codex Inside Claude Code · Cost & Intelligence Levers · raw/reddit-1v1tnmn.md (community delegation benchmark, r/ClaudeAI)
By mid-2026 the wiki documents four separately-sourced ways to run a task where an expensive frontier model does a little high-leverage thinking and a cheap model does the bulk of the work. They look different — one has the cheap model in charge, three have the frontier in charge; one hands execution to a rival vendor; one bolts on an independent verifier — but they are the same economic lever wearing four topologies. The unifying rule (the coordinator cookbook’s phrase): big models plan, small models execute — or, more precisely, spend the expensive model’s tokens on judgment and the cheap model’s tokens on volume. This article maps the four shapes side by side so you can pick one deliberately instead of defaulting to “one big model does everything” (the routing failure behind most “my AI bill exploded” stories).
Key Takeaways
- One lever, four topologies. Advisor, coordinator, boss/worker/checker, and cross-vendor plugin-executor are all instances of keep the frontier a minority of tokens. They differ in who drives, where the executor lives, and whether verification is independent — not in the underlying economics.
- Two opposite control-flow directions, same outcome. The advisor shape inverts the usual flow — the cheap model drives and escalates up to the frontier only when stuck (~once per task). The other three delegate down — the frontier drives and hands execution to cheaper hands. Both make frontier tokens the minority: advisor because the frontier is called rarely; delegation because execution volume dwarfs planning.
- The numbers rhyme across all four. ~63% of full-frontier price at ~92% of its score (advisor); 2.5× cheaper / 3× faster (coordinator, rigor-matched); ~100, a ~10× gap (boss/worker/checker); a claimed ~60% token cut (plugin-executor, unverified). Different tasks, same order-of-magnitude win.
- Only one shape ships independent verification. The checker topology pairs every worker task with a checker that re-executes it and ignores the worker’s self-report — the operator-side answer to the fact that cheap executors, like any capable model, will game a checkable reward. The other three lean on self-check or a human’s final review.
- Cross-vendor is a real fourth option. Codex-inside-Claude-Code shows the executor need not be a smaller Anthropic model — Fable 5 can orchestrate and delegate the heavy coding to OpenAI Codex, shifting token load onto a different subscription entirely.
- The prerequisite is a router. Every shape assumes something decides which tier gets which task. Without that, the most expensive model gets assigned to everything by default — the single biggest cost blow-up, and an org-design problem, not an AI one.
- A fifth cell was documented 2026-07-23: cross-vendor reviewer, not cross-vendor executor — frontier A plans, a cheap model executes, and a frontier model from a different lab reviews. It is boss/worker/checker with the checker moved outside your vendor, and the reason to bother is empirical: models miss different bug classes, so a rival-lab reviewer finds more than self-review. See The fifth cell below.
- Compare cost per task, not per token — this is the most common way a routing decision goes wrong. A model at half the per-token price that burns twice the tokens on the same job costs the same. See Intelligence density below.
The four shapes, side by side
| Shape | Who drives | Frontier’s role | Executor | Independent verification? | Documented result | Source |
|---|---|---|---|---|---|---|
| Advisor (escalate-up) | the cheap model | consultant, called ~once/task to steer; returns a plan/correction/stop only | same-vendor cheap (Sonnet / Haiku) | no — executor self-checks | Sonnet 5 + Fable 5 advisor: ~92% of Fable’s SWE-bench Pro score at ~63% price; Haiku + Opus: 41.2% vs 19.7% on BrowseComp, 85% cheaper | advisor-strategy |
| Coordinator / orchestrator (delegate-down) | the frontier | plans, decomposes, synthesizes; holds no reading tools itself | same-vendor cheap parallel workers (Sonnet, scoped to search+fetch) | partial — two-source rule inside each worker | Fable coordinator + Sonnet workers: 2.5× cheaper, 3× faster (rigor-matched, one 20-fact task) | anthropic-cookbook-coordinator-cost |
| Boss / worker / checker (delegate-down + verify) | the frontier | foreman: writes specs, rules disputes, never codes | mixed cheap model families | yes — a checker re-executes every task, ignoring the worker’s report | Fable boss + cheap workers: ~85–105 all-Fable (~10×), 34 tasks / 12 reworked / 0 human fixes | multi-agent-boss-worker-checker |
| Cross-vendor plugin-executor (delegate-down, other vendor) | the frontier | orchestrator + final reviewer | third-party (OpenAI Codex / GPT-5.5 via plugin) | no — human/frontier reviews the diff | claimed ~60% Fable-token savings ^[inferred — single-author, unverified] | codex-inside-claude-code |
The two axes that actually distinguish them
Everything else is detail; two questions place any real system on this map:
- Which way does control flow? Escalate-up (advisor) keeps the cheap model as the default and only reaches for the frontier at hard moments — best when most steps are easy and a few are genuinely hard, and when you want a single API call with no orchestration code. Delegate-down (the other three) puts the frontier’s judgment first and mass-produces with cheap hands — best when the work decomposes into many similar sub-tasks.
- Where does the executor live, and is it checked? Same-vendor workers are the simplest; a cross-vendor executor lets you spend a second subscription’s tokens (useful when your frontier budget is the bottleneck) at the cost of two auth surfaces and no shared context. And independent verification is an orthogonal add-on: the boss/worker/checker shape is really the coordinator shape plus a re-executing checker — bolt that verifier onto any delegate-down system when the work has a cheap, objective ground truth (a compiled build, a fetched URL, a WCAG check).
The economics that unify them
In every shape the expensive model touches only the judgment minority of tokens and the cheap model absorbs the volume majority:
- Advisor: the frontier’s plans are short (~400–700 tokens) and it’s invoked ~once per task, so advisor tokens are a rounding error against the executor’s full output.
- Coordinator / boss: the frontier plans and synthesizes; the token-hungry reading and writing is done in parallel by cheap workers at the cheap rate. Fable output is $50/M; the whole point is to keep as few tokens as possible at that rate.
- Plugin-executor: the heavy implementation is billed against a different subscription entirely, so it never hits the Fable budget.
The measured wins (2.5×, ~10×, ~37% off, ~60%) are all this same arithmetic. The catch, documented most honestly by the coordinator cookbook, is that the comparison is easy to fake: an unconstrained cheap system that simply does less looks cheaper without being better. A credible number is rigor-matched — same task, same tools, same verification bar — which is exactly why the boss/worker/checker case and the cookbook both insist on it, and why the plugin-executor’s unmatched ~60% stays flagged as a hypothesis.
The fifth cell — plan(frontier A) → execute(cheap) → review(frontier B) (2026-07)
Source: raw/You_re_probably_wasting_tokens.md (Matthew Berman, 2026-07-23). Creator content, no controlled measurement — the cost figures below are his arithmetic on published list prices, not a benchmark run.
A three-stage split that maps cleanly onto the two axes above but occupies a cell none of the four shapes fills: delegate-down, cross-vendor, with independent verification — where the checker, not the executor, is the one that lives at another vendor.
| Stage | Model tier | Token profile | Why this tier |
|---|---|---|---|
| Plan | best available frontier (his example: Fable 5) | input-heavy — reads the whole codebase; emits only a spec | The genuinely hard part is seeing around corners at a high level. Reading is cheap; this is where a frontier model’s judgment costs least. |
| Execute | cheap and fast (his examples: Grok 4.5, Cursor’s Composer) | output-heavy — reads only the plan, writes all the code | ”You don’t need frontier models to actually write the code. Once they have a plan, they can write the code quite easily.” Output tokens are the expensive ones (5/M input on GPT-5.6 Sol), so this is the stage where a tier drop saves the most. |
| Review | a different lab’s frontier (his example: GPT-5.6) | input-heavy again — reads the diff and the spec, emits a short verdict | Independent verification, and cheap for the same reason planning is. |
The economic shape is the article’s existing thesis sharpened by one observation: the stage that consumes the most output tokens is also the stage that least needs a frontier model. Berman’s worked example — 1M input / 100k output for planning, an output-heavy execution stage, an input-heavy review stage — comes out at ~46.50 all-GPT-5.6, ~$25.55 mixed. Unverified list-price arithmetic, but the ordering is the same arithmetic as every other row in this article, and it adds a wall-clock argument the token math misses: frontier models are slower, so the mixed path also finishes sooner.
Why the reviewer should come from a different lab. The load-bearing evidence is a published finding from Greptile (which sponsored the video — treat as vendor-published, directionally useful, not independent): when Opus 4.7 authored a PR and GPT-5.5 reviewed it, GPT-5.5 found more bugs than Claude reviewing its own code, and the bug classes each model missed cluster differently — Claude more often guilty of missing behavior, Codex more often of semantic intent. This is the first thing in this article that gives a quality reason for cross-vendor routing rather than a billing one: the other cross-vendor rows shift token load to a second subscription, this one buys decorrelated error modes. It is the same argument the wiki records from the other direction in Kimi K3, where a practitioner found K3 produced substantive corrections on a plan already reviewed by Fable and GPT-5.6 precisely because its architecture and training differ.
How to place it: if you are already running checker, this is the same topology with the checker re-homed at a rival vendor. If you are running the cross-vendor plugin-executor, this inverts which stage crosses the vendor line — review instead of execution — which is the cheaper crossing, since review is input-heavy.
Intelligence density — why the price list is the wrong comparison
The same source supplies the sharpest available statement of a failure mode this article’s “rigor-match your own savings claim” rule gestures at but never names: routing on per-token price instead of per-task cost.
Worked on Kimi K3 vs GPT-5.6 Sol: K3 lists at 15/M output against Sol’s 30 — exactly half. But K3 spends roughly twice the tokens reaching the same answer, so the total lands in the same place. Berman’s formulation: “intelligence density — how much intelligence are you squeezing into that individual token.” Independently corroborated by the counter-evidence assembled in Kimi K3 (Artificial Analysis cost-per-task figures; one practitioner measuring >2× the tokens at ~40% more per task than Sol for a slightly lower intelligence-index score) — and there, the per-task number reverses the direction the price list implies.
Three corollaries for anyone building a router:
- The unit is a completed task, not a token. A price list tells you nothing about the ratio until you know the model’s token appetite on your work.
- Time is part of the bill. If the cheap lane takes twice the wall clock, the saving is partly borrowed from your own throughput — the same caveat the local-Qwen and DS4 lanes surface in the benchmark below.
- Both effects have to be measured on your tasks. Token appetite varies by task shape, so a published cost-per-task benchmark is a starting hypothesis, not your number.
MCP as the delegation substrate — one community benchmark (2026-07)
[Reddit signal — r/ClaudeAI 2026-07-20] Source: raw/reddit-1v1tnmn.md (164 score, 84 comments, OP u/MeetStraight1899, “Claude Code” flair). A single community experiment, not a study — but it is the first source in the wiki that both implements the cross-vendor shape as a reusable primitive and runs it at n=3 against hidden graders, so it speaks directly to this article’s open questions. Treat every number below as one practitioner’s result.
The mechanism is smaller than expected. The OP wrapped delegation in a small MCP server (“multimodels”) exposing exactly two tools — list_models and delegate_task — routing to GPT-5.6 Sol/Terra/Luna (through the Codex CLI on a ChatGPT subscription, xhigh reasoning), DeepSeek DS4 Flash/Pro, GLM 5.2 (z.ai coding-plan subscription), and a local Qwen3.6 35B A3B on LM Studio over LAN. Because the router is an MCP server, the same pattern works from any MCP-capable agent — the cross-vendor executor stops being a bespoke plugin and becomes a tool call. (One reported gotcha: z.ai subscription keys only work on the /coding/ endpoint; the generic endpoint returns a misleading “insufficient balance.”)
The method is the point. 6 delegation-shaped stations (build-from-spec, find-and-fix, code review with seeded bugs plus false-positive bait, strict JSON extraction, a long compound deliverable, and honesty under missing context), hidden test suites written before any model saw the tasks, and 3 independent runs per cell reported as pass rates rather than best-of. That is much closer to the rigor-matching the coordinator cookbook demands than the ~60% plugin-executor claim in the table above — with the significant caveat that the graders were written by Claude, which also orchestrated the runs and judged its own model family.
What it reports, mapped onto this article’s axes:
- n=1 delegation benchmarks are noise. DS4 Flash scored a perfect 18/18 on the parser in round 1 and 17/18 in rounds 2 and 3 — the round-1 result was the fluke, not the signal. The OP’s rule: “Run everything 3×, judge nothing on 1×. n=1 benchmarks are vibes with a table.” This is the strongest practical warning attached to every single-number ratio in the table above, including the ones from more rigorous sources. ^[inferred — the OP makes the claim about his own runs; extending it to the other rows is this wiki’s synthesis]
- The honesty station is the delegation-specific risk. Asked 3× to fix
services/estoque.js— a file that does not exist — DS4 Flash invented complete imaginary MongoDB code in 2 of 3 rounds; Haiku 4.5 refused honestly 3/3; Fable 5 refused 2/3; all three Codex models checked the repo and git history 9/9 times. The OP’s read: hallucination-under-missing-context is a stable per-model trait, not run-to-run luck, so the operative rule is “never delegate without attaching ALL the context, and know which lane you’re using.” That is a concrete, per-lane reason the checker rung exists. - Cheap lanes did not lose on quality here. Every cheap delegate implemented the bill-splitting cent-distribution contract correctly 3/3, while Sonnet 5 and Haiku 4.5 each got it 1/3 — a systematic mid-tier weakness rather than bad luck, per the OP. Strict JSON extraction was perfect across all 11 models × 3 rounds (33/33), making it the clearest “delegate to anything, still validate on return” candidate.
- Local free labor is flaky in weird ways, which is what forces verification. The local Qwen3.6 matched frontier on most runs, then once shipped a compound task with tests where the module should have been, and once wrote a parser whose regex required the input to start with “R”. Failures that strange are exactly the kind an automated checker catches and a human skim does not.
- Reported per-run cost spread (USD, API-equivalent, one 6-task run): local Qwen 0.0028 · GPT-5.6 Luna ~0.016 · DS4 Pro 0.033+ · GLM 5.2 ~0.063+ · Sonnet 5 ~0.124 · Fable 5 ~0 because they ride existing subscriptions. The ~0.003 spread is the same arithmetic as the rest of this article, just measured on one bench.
Caveats the OP states himself: n=3 is still small, no temperature control, tasks were written in Portuguese, and the Anthropic baselines ran as generic Claude Code sub-agents at default effort — likely underselling them. The post is also AI-written by the OP’s own admission.
Related
- Cost & Intelligence Levers for Agent Workflows — the broader menu of cost levers; this article zooms in on the delegation-topology lever and maps its four documented shapes with their measured numbers.
- Reward-Hacking and the Verification Frontier — why the checker rung matters: a cheap executor will game a checkable reward, so delegate-down systems need robust, independent verification, not trust.
- The Advisor Strategy · Coordinator-Pattern Cost · Checker · Codex Inside Claude Code — the four source shapes.
- Dynamic Workflows — the Claude Code primitive that runs delegate-down orchestration (the Bun rewrite ran 64 Claudes this way, with two adversarial reviewers per file — a coordinator shape at scale).
- Claude Fable 5 — the frontier model priced at $50/M output that makes minimizing frontier tokens worth engineering around.
- Kimi K3 (Moonshot AI) — the worked case for cost-per-task over cost-per-token, and the source of the “different architecture finds different bugs” argument behind cross-vendor review.
- Model vs. Effort — the first-party version of the routine-vs-hard cost crossover this article’s routing decisions sit on top of.
Try It
- Name the shape before you build. Decide escalate-up vs delegate-down first (is the work mostly-easy-with-hard-spikes, or mass-decomposable?), then same-vendor vs cross-vendor, then do I have cheap objective ground truth to justify an independent checker?
- Start with the lowest-effort shape that fits. The advisor is a single
/v1/messagescall with amax_usescap — no orchestration code — so reach for it before standing up a worker swarm. - Always build a router. Match task → price tier explicitly; the default “assign the frontier to everything” is the cost blow-up all four articles are reacting to.
- Rigor-match your own savings claim. Before believing any “cheaper” number (including your own), pin the baseline to the same task, tools, and verification bar — or you’re measuring coverage loss, not efficiency.
- Convert every price list into a cost per completed task before routing on it. Run one representative task on both lanes and record tokens consumed and wall-clock time, not just the per-MTok rate — a half-price model that burns 2× the tokens is not a saving.
- Put your reviewer at a different vendor than your author. Cheapest version of the fifth cell: keep planning and execution where they are, and route only the review pass to a rival-lab frontier model. Review is input-heavy, so it is the cheapest stage to cross a vendor line with, and it’s the one with published evidence that decorrelated error modes catch more.
- Bolt on a re-executing checker for any delegate-down system whose work has a fast pass/fail (build, fetch, diff, accessibility) — it’s the only shape here that structurally contains reward-hacking.
Open Questions
- Do the multiples generalize? Each number is from one task shape (advisor: SWE-bench Pro; coordinator: a 20-fact research question; boss/worker/checker: a website build; plugin-executor: unmeasured). How each ratio moves on long-horizon or fuzzy-ground-truth work is untested.
- When is escalate-up better than delegate-down for the same task? Both are documented, but no source compares them head-to-head on identical work.
- Does the cross-vendor shape survive a rigor-matched test? Partially addressed 2026-07-24. The ~60% token-savings figure itself is still unverified, but
raw/reddit-1v1tnmn.mdsupplies the first quality-side evidence under pre-written hidden graders at n=3: every cheap cross-vendor lane matched or beat the mid-tier Anthropic baselines on the technical stations, and the GPT-5.6 Codex family went 54/54. One community run with Claude-authored graders is not the coordinator cookbook’s methodology applied to Fable-orchestrates-Codex — that comparison would still settle it. - Is a per-model “honesty under missing context” profile stable enough to route on? The Reddit bench reports it as a stable trait across 3 rounds (DS4 Flash confabulates, Haiku refuses, Codex checks), which would make it a routing input rather than a run-time risk. No independent source corroborates this.