Source: raw/anthropic-watch-anthropic-cookbook-commit-a485090d4c3af1a59f6071aa13d388d48e0c9bf3.md, raw/anthropic-watch-anthropic-cookbook-commit-7aaa17fa217f27ff4b7d97fcfaba1ba75f328523.md, raw/anthropic-watch-anthropic-cookbook-commit-5d6d633b6a746e9302946d3ef5b82b99e99a1966.md

A first-party Anthropic cookbook notebook (added to anthropics/claude-cookbooks, merged to main via PR #754 on 2026-07-06) that puts a hard number on the managed_agents coordinator configuration: a frontier coordinator (Fable 5) plans and synthesizes while cheap workers (Sonnet 5) do the token-hungry reading in parallel threads. Its distinguishing feature is a rigor-matched comparison — the control isn’t a weaker product, it’s one frontier agent held to the exact same standard — so the reported “2.5x cheaper, 3x faster” is an apples-to-apples result rather than a favorable framing. The notebook is unusually candid about the ways this measurement can be faked, which is the reason to read it.

Key Takeaways

  • The pattern. A tool-less frontier coordinator (Fable 5) plans the work and synthesizes the answer; cheap workers (Sonnet 5), scoped to web_search + web_fetch only, do the expensive reading in parallel threads.
  • Rigor-matched control. The comparison baseline is one frontier agent with the same tools, held to the same two-source verification standard, answering the same 20-fact coverage question. Both arms read a similar volume — so the delta is attributable to the architecture, not to one arm doing less work.
  • Headline result. On the committed run, the team came out 2.5x cheaper and 3x faster than the rigor-matched solo frontier agent at similar read volume.
  • Trap (a) — the fake win. An unconstrained solo agent reads less and therefore only looks cheaper. That is a different product (less coverage), not a fair comparison. The whole point of the rigor match is to refuse this comparison.
  • Trap (b) — the per-thread floor. Over-narrow briefs spin up many tiny worker threads, and each thread pays a fixed floor cost. Slicing the work too finely pays that floor repeatedly and erodes the savings.
  • Trap (c) — the invisible team contract. The coordinator cannot see its roster agents’ prompts or descriptions. The team contract — what each worker is for, how to brief it — must live in the coordinator’s own prompt, not in the worker definitions.
  • Cost attribution is typed, not estimated. Use the per-thread usage rollups: sessions.threads.listthread.usage for each worker; session.usage is the team total. The notebook also points to where per-request span detail lives.
  • Model IDs. validate_notebook.py’s model allowlist was extended with the current IDs (fable-5, sonnet-5, opus-4-8) so the notebook passes the repo’s audit check.

How the Coordinator Config Works

The architecture diagram (added in the internal-review-fixes commit) sits right after the intro and reads left to right: the recorded 20-fact question feeds a tool-less frontier coordinator, which fans out to ten scoped web-reading workers. Every arrow is two-way — workers return findings to the coordinator, which synthesizes and can re-dispatch.

  • Coordinator = brain. Fable 5. Plans the decomposition, holds the team contract, synthesizes the final answer. Has no reading tools of its own.
  • Workers = hands. Sonnet 5, each scoped to only web_search + web_fetch. They absorb the token-hungry reading that would otherwise be billed at the frontier rate.
  • Why it’s cheaper. The bulk of the tokens (reading source pages) are consumed by the cheap model in parallel; the expensive model is reserved for planning and synthesis. This is the same “big models plan, small models execute” lever documented for the advisor and orchestrator strategies, applied to managed_agents with measured cost attribution.

The Rigor-Matched Comparison

The notebook’s core methodological contribution is refusing the easy win. Both arms must:

  • Answer the same 20-fact coverage question.
  • Use the same tools (web_search + web_fetch).
  • Meet the same two-source verification standard (each fact confirmed against two sources).

Only then is cost compared. Because both arms read a similar volume of source material, the 2.5x / 3x deltas reflect the division of labor, not a coverage shortcut. This is the guard against Trap (a).

Honest Caveats (from the internal-review commit)

The polish commit added review fixes to comments and prose only — the recorded outputs were left untouched — including a fourth honest caveat:

  • The committed run’s own “park list” is wrong at #10. The facts were verified, but the question decomposition was not — which the notebook calls its sharpest lesson. (The term “park list” is the source’s own wording.^[ambiguous])
  • Sonnet 5 introductory pricing. The PRICES comment now names the fact that Sonnet 5’s figures reflect an introductory pricing window — so the absolute cost ratio may shift once that window closes.
  • Tool scoping is a security boundary. Restricting workers to web_search + web_fetch isn’t only about cost — the comment now names the prompt-injection boundary that narrow tool scoping provides. A worker that can only search and fetch can’t be talked into doing anything more dangerous.

Open Questions

  • The 2.5x / 3x figures are for the single committed 20-fact research question; the notebook does not claim they generalize to other task shapes. How the ratio moves for longer-horizon or non-research tasks is untested here.
  • The absolute cost advantage depends on the Sonnet 5 introductory pricing window remaining open.

Try It

  • Open the notebook in anthropics/claude-cookbooks under the managed_agents directory and run it against your own coverage question.
  • Copy the rigor match, not just the pattern. Before trusting any “multi-agent is cheaper” claim (your own included), pin the solo baseline to the same tools, the same verification standard, and the same question. If the solo agent is allowed to read less, you’re measuring the wrong thing.
  • Put the team contract in the coordinator’s prompt, never only in the worker definitions — the coordinator can’t see them.
  • Attribute cost with typed rollups: iterate sessions.threads.listthread.usage per worker and reconcile against session.usage (the team total) rather than eyeballing spend.
  • Right-size the briefs. Watch for the per-thread floor cost — if you’re spawning many tiny workers, consolidate until the reading-per-thread justifies the thread.