The orchestrator's context window is the scarcest resource in a session. Every file dump,\nlog tail, and grep result read directly is context that can no longer hold the plan, the\nspec, or the diff under review. Delegation exists to keep that window for judgment.
\nOpus 5.5 is the daily driver: it is the orchestrator, and it makes the code edits. Reading\nwork goes to cheaper models.
\n| Work | \nWho does it | \nModel | \nEffort | \n
|---|---|---|---|
| Search, recon, mapping call sites, \"where does X live\" | \nsubagent (Explore) | \nhaiku; sonnet when interpreting what it finds takes judgment | \nnone on Haiku | \n
| Reading CI or gate logs, running the gate suite | \nsubagent | \nhaiku or sonnet | \nnone on Haiku | \n
| Bulk prose: docs pages, guides, templates, against an exact spec | \nsubagent | \nsonnet | \nsession level | \n
| Code edits: scripts, tests, generators, gates, workflow code, Rust | \norchestrator, or opus subagents for independent parallel edits | \nOpus 5.5 | \nsession level | \n
| Architecture, schema shapes, security-sensitive and load-bearing edits | \norchestrator only | \nOpus 5.5 | \nsession level | \n
| Verification of delegate output, and the commit | \norchestrator only | \nOpus 5.5 | \nsession level | \n
One task that high has failed twice in the same way | \norchestrator, after switching model | \nFable 5.1 | \nthen switch back | \n
Search and log-reading are summarization jobs: a cheaper model reads a lot and returns a\nlittle, and that is exactly the trade you want. Code edits are the opposite. They are where a\nsubtle mistake costs a CI cycle and a reviewer's trust, and a spec rarely captures every\ninvariant the surrounding code depends on. Keep them on the model that holds the whole plan.
\nDocs prose is the judgment call in this table. It is not code, so a Sonnet writer with an\nexact file-scoped spec is still the default. Anything that encodes facts (model names,\ncommand flags, API shapes) gets verified by the orchestrator before acceptance, whoever wrote it.
\nPass model explicitly each time you spawn a subagent. Since Claude Code v2.1.198 the\nbuilt-in Explore agent inherits the main conversation's model instead of always running on\nHaiku, so an Explore call without model: \"haiku\" runs the reconnaissance on Opus 5.5. That\ndefeats the point of delegating it. The per-invocation model parameter wins over the\nsubagent's frontmatter, over CLAUDE_CODE_SUBAGENT_MODEL, and over the session model. An\nopus alias from an Opus 5.5 session resolves to Opus 5.5 itself, which is what you want for\nparallel code-edit delegates.
Opus 5.5 defaults to medium, and well-scoped daily work belongs there. Raise effort only\nwhen the work shows it needs more, and in this order:
npm run validate, cargo test, a one-line negative probe) often catches at\nmedium what you would otherwise need high to find. Add the check before touching the\neffort dial.medium stalls → high. More thinking per turn catches what medium misses.high still cannot get there → xhigh. Use this when each attempt makes progress but\nfalls short.high hits the same problem twice → Fable 5.1 for that task. An identical repeated\nfailure means more thinking on the same model is not the fix. Switch that specific task to\nFable 5.1, solve it, then switch back to Opus 5.5 at medium. Do not leave the session\nrunning on the escalated setting.max is for one hard task, never a standing default. Claude Code applies max to the\ncurrent session only unless it is forced through CLAUDE_CODE_EFFORT_LEVEL. The docs\nwarn it can show diminishing returns and is prone to overthinking. Turn it on for the task,\nthen lower it again.Change effort or model at a break, such as after a commit or between tasks. Changing effort\ninvalidates the messages cache, and caches are model-scoped, so the next turn after a switch\npays full price for the whole conversation. Switching in the middle of a debugging loop pays\nthat cost at the worst time.
\nEffort for delegates:
\nhigh on Sonnet is not high on Opus. Choose the\ndelegate's model first, then its effort.effort:\nor the Workflow agent() call passes one. A recon or gate-run delegate rarely needs more\nthan the session level./plan, or Shift+Tab) for changes that span multiple files. The plan is\nreviewed before any edit touches disk, which is cheaper than unwinding a wrong edit./clear between unrelated tasks, so the old task's context does not ride along./compact at a natural break, with a note on what to keep, for example\n/compact keep the spec, the failing test names, and the open review threads./usage reports. Your own numbers beat anyone's benchmark, including this skill's\ntable.These stay with the orchestrator because each needs the whole picture, and a delegate sees\nonly its slice:
\nHaiku never orchestrates; it explores and runs gates. If Sonnet orchestrates instead of Opus\n5.5, run it at high effort at minimum. Planning quality degrades below that, and a weak\nplan wastes every delegate downstream.
A delegate knows only what its prompt says. Hand over:
\nfile:line or a URL for every claim. A report without them is not actionable; re-run it\nwith a tighter prompt rather than accepting it.npm run validate, no cargo test, and never git commit. Delegates write files; only\nthe orchestrator commits.A delegate's self-report is a lead, not evidence. Read the diff in full, then run the gates\nrelevant to the touched files (npm run validate, cargo test for tools/vfa-tui,\nnpx markdownlint-cli2, npm run lint:spell). Treat a green gate as necessary, not sufficient. Also\nrun one positive probe (the thing now works) and one negative probe (bad input now fails with\nthe right message).
Three shapes cover most multi-step tasks here. Reach for one before inventing a bespoke plan.\nFor large work, .claude/workflows/agentic-delegation.js runs the same doctrine as an\nexecutable Workflow (see .claude/workflows/README.md).
Parallel Explore agents on model: \"haiku\", one narrow question each, one area of the tree\neach, all launched in the same message so they run concurrently. Every finding carries a\nfile:line citation. Use this when you do not yet know where something lives. It is\nread-only: no edits, no commits. If a sweep comes back thin or off-target, tighten the prompt\nand re-run it.
The orchestrator writes the spec first: exact paths, the shape of the change, the conventions\nto mirror, and checkable acceptance criteria.
\nopus subagents, one spec each, with disjoint file lists.sonnet subagent. A one-line summary of a spec\nproduces a one-line-quality result.Either way, the orchestrator reads the whole diff before running any gate, then verifies as\nabove. Delegates touch exactly the files their spec lists and never commit.
\nA haiku subagent, with no effort level, runs the suite and reports pass or fail with raw\nfailure output verbatim, not a paraphrase like \"some tests failed\". The orchestrator needs the\nactual error to decide the next move.
Order matters because npm run validate includes the asset-integrity check. The orchestrator\nruns the generators its change needs first. The gate run then refreshes the manifest with\nnpm run asset-integrity:write, on its own, as the last write. Only then does it run the\nchecks: npm run validate, npm run lint:spell, and npx markdownlint-cli2, plus\ncargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test when\ntools/vfa-tui changed. Run it the other way round and validate fails on the stale\nmanifest before the refresh ever happens. The only file a gate run may write is\ncatalog/asset-integrity.json, and it never commits.