Skip to main content

Command Palette

Search for a command to run...

Orchestrating Sub-Agents for Cost-Efficient Engineering

Updated
5 min readView as Markdown
Orchestrating Sub-Agents for Cost-Efficient Engineering

How I route Claude Code work to the cheapest model that can do it well, and the exact rules I use.

Kasun de Silva · September 2026


In Claude Code, every subagent you spawn inherits the parent's model unless you say otherwise. If your main session runs on the most capable model, so does the agent you sent to grep sixty repos for a variable name. That is a cron job running on your biggest instance type because it was the one already booted.

I fixed this with one section in my global CLAUDE.md. The idea: one expensive brain, many cheap hands.

The brain is the main session model, Fable 5.1 at the time of writing. It plans, briefs, reviews and commits. It does not grep. The hands are subagents on cheaper models. Each gets one bounded job and one precise brief, does it, reports back, and never touches git. Control plane and data plane, if you like.

The rules

Copy this into ~/.claude/CLAUDE.md and replace "Fable" with whatever your main model is.

# Global rules

## Orchestration and model routing

Fable is the planner, sole decision maker, orchestrator, reviewer and committer. Cheaper models do the bulk of the work under Fable's direction. The quality bar is the highest in every case; delegation never lowers it.

### Always set the model explicitly
Subagents inherit the parent model unless `model` is passed. A delegated task without `model:` runs on Fable and saves nothing. Every `Agent` call must name a model.

| Model | Use for |
|---|---|
| `haiku` | Read-only sweeps: grep/find across repos, locating files or symbols, scanning logs, summarising large tool output. Use `Explore` type. |
| `sonnet` | Implementation from a precise spec: code and Terraform/HCL edits, tests, boilerplate, doc and PR-body drafting, applying review fixes. |
| `opus` | Implementation where the path is unclear: multi-file refactors, debugging with unknown cause, work needing judgement mid-task. |
| Fable (self) | Planning, architecture and design decisions, requirement clarification, code review, anything security- or prod-impacting, final approval and commit. |

Never use `subagent_type: "fork"` for grunt work. A fork inherits the full Fable context and always runs on Fable.

### Do it yourself when delegation costs more
Delegation has fixed overhead: writing the brief, reading the report, reviewing the diff. Do the work directly when:
- the change is small (roughly under 20 lines or a single file edit),
- it is a single-fact lookup and the file is already known,
- the brief would be longer than the work itself,
- the task is conversation, advice or a decision rather than production of code.

### Briefing standard
A subagent gets one precise brief, not a conversation. Every brief includes: exact files and scope, the required approach and conventions, what "done" looks like, what to leave untouched, and the report format (summary of changes plus anything uncertain). A vague brief produces a round-trip, and every round-trip re-bills the brief.

### Review and correction
- Fable reviews every diff a subagent produces before anything is committed. Read the actual diff, not just the agent's summary.
- Deviation from the spec is corrected, always. If the fix is a few lines, Fable applies it directly. If the fix is substantial, send it back to the same agent via `SendMessage` (keeps its context) with the exact change required. Do not start a fresh agent to fix a running agent's work.
- Fable commits, opens PRs and posts review requests. Subagents never commit or push.

### Parallelism
Independent tasks go to separate agents in one message so they run concurrently. Dependent tasks run sequentially through Fable, never chained agent to agent.

### Skills that dispatch agents
Superpowers (subagent-driven-development, dispatching-parallel-agents, requesting-code-review) and any other skill that spawns agents does so without a model. When following such a skill, add `model:` to every Agent call it prescribes: `sonnet` for implementers and spec-compliance reviewers, `haiku` for search. Mechanical review (does the output match the written spec) goes to a Sonnet agent; the judgement layer (is the design right, do the findings matter) stays with Fable in the main context so the same files are not read twice at Fable rates.

The three that matter most

If you only take three things from that block:

  1. Name a model on every agent call. Without it, delegation saves nothing. I also set CLAUDE_CODE_SUBAGENT_MODEL to sonnet in ~/.claude/settings.json as a safety net for the calls I forget.

  2. Do it yourself when delegation costs more. A brief, a report and a review are fixed overhead. Under about twenty lines, the brain does the work directly. Without this rule a multi-agent setup pays twice for one-line changes.

  3. Review the diff, not the summary. Summaries are where "bumped the module version" hides "and reformatted 400 lines". Fixes go back to the same agent so its context is not paid for twice.

What changed

The expensive model now touches a task a few times, for a few minutes of judgement each. Search and edits run on models that cost a fraction of it, often in parallel, so tasks finish sooner as well as cheaper.