Cut your Claude Code bill roughly in half: cheap worker sub-agent + delegation policy (demo)

README.md

Cut your Claude Code bill roughly in half, without losing quality

The problem

If you use Claude Code (or any AI agent), every single step runs on your selected model, usually the most expensive one. Reading files, renaming a variable, running tests: all billed at the premium rate. But most of those steps don't need a genius. They need a competent worker.

The idea in one line

Don't ask "which model should I use?" Ask "which model should handle which part of the task?"

Anthropic benchmarked this. Mixing an expensive model (Fable 5) with a cheap one (Sonnet 5) in a structured way kept 92 to 96 percent of the quality at 46 to 63 percent of the price. Going all-cheap was cheaper still, but quality dropped hard (accuracy fell from 86.8% to 77.8%). The saving comes from the structure, not from the cheap model alone.

The two patterns

Pattern 1: the Advisor (escalate up)

The cheap model does the work. It calls the expensive model only when it's stuck, roughly once per task, like a junior dev asking a senior for direction.

Sonnet 5 (cheap) ── does all the work
      │
      └── "I'm stuck, what's the right approach?" ──▶ Fable 5 (expensive, ~once per task)

Result on SWE-bench Pro: 92% of the expensive model's solo score, at 63% of the price.

Pattern 2: the Orchestrator (delegate down)

The expensive model plans and reviews. The actual work is fanned out to cheap workers, like a tech lead handing tickets to the team.

Fable 5 (expensive) ── plans, then reviews at the end
      │
      ├──▶ Sonnet 5 worker (cheap) ── edits files
      ├──▶ Sonnet 5 worker (cheap) ── runs tests
      └──▶ Sonnet 5 worker (cheap) ── searches the codebase

Result on BrowseComp: 96% of the performance at 46% of the price ($18.53 vs $40.56 per problem).

This gist sets up Pattern 2 in Claude Code. It's the one you can wire up in five minutes.

What is a "sub-agent" in Claude Code?

A sub-agent is a helper Claude that the main Claude can spawn to do a task. You define one with a plain markdown file: a few lines of settings on top (name, which model it runs on), then instructions in plain English. Claude Code automatically loads every file in ~/.claude/agents/.

The key trick: the sub-agent can run on a different, cheaper model than your main session.

Setup (2 files, 5 minutes)

Step 1 — Create the worker.

Copy the worker.md file from this gist to:

~/.claude/agents/worker.md

That's the whole worker. The two lines doing the cost-saving are in its header:

model: haiku          # runs on the cheap model, not your main one
reasoningEffort: low  # doesn't overthink mechanical tasks

Step 2 — Tell the main model when to delegate.

Sub-agents only save money if the main model actually uses them. Copy the contents of CLAUDE-md-snippet.md from this gist into your project's CLAUDE.md file (or into ~/.claude/CLAUDE.md to apply to every project). It's a short policy: routine work goes to the worker, planning and review stay with the main model.

Step 3 — There is no step 3.

Both files live in your home directory, so every project picks them up. Nothing to rebuild per repo.

Optional — pin the top of the pattern too.

The two files above make your current session delegate downward, whatever model it runs on. If you also want the expensive side to be explicit, copy orchestration.md from this gist to ~/.claude/agents/orchestration.md. It's the mirror image of the worker: it runs on the top model (model: fable) with high reasoning effort, owns planning and final review, and is instructed to fan all mechanical work out to worker agents instead of doing it inline. Hand it your big refactors and migrations; together the two files are the full Orchestrator pattern in agent form.

See it work

Open any repo in Claude Code and ask for something with lots of mechanical steps:

"Rename getUser to fetchUser everywhere, run the tests, then review the diff."

Without the setup: the expensive model grinds through every file itself.

With the setup: the main model plans for a moment, you'll see it spawn worker agents for the rename and the test run, then it reviews the combined result itself. Most of the tokens were billed at the cheap rate; the judgment calls stayed with the expensive model.

A step-by-step walkthrough of exactly this run, with and without the setup, is in example-orchestrator-session.md in this gist.

FAQ

Won't the cheap model make mistakes? On mechanical tasks, rarely. And the worker's instructions tell it to stop and report back instead of guessing when a task needs judgment. The expensive model still reviews everything at the end.

When should I NOT delegate? Debugging something subtle, choosing between designs, anything where being wrong is expensive. That work belongs to the main model. The snippet already encodes this.

Where do the benchmark numbers come from? Anthropic's published comparison of solo Fable 5 vs the hybrid setups on SWE-bench Pro and BrowseComp. Details in the thread linked from the post that brought you here.

CLAUDE-md-snippet.md

Copy the section below into your CLAUDE.md

Project-level: <your-repo>/CLAUDE.md (applies to that repo). Global: ~/.claude/CLAUDE.md (applies to every project).

CLAUDE.md is the standing instructions file the main model reads at the start of every Claude Code session. This section is the delegation policy: it tells the expensive main model which work to hand to the cheap worker sub-agent and which work to keep.

---

Model delegation policy

You (the main model) own planning, architecture decisions, and final review. Delegate everything routine to the worker sub-agent instead of doing it inline:

• Reading multiple files to answer a question → worker
• Mechanical edits, renames, find-and-replace across files → worker
• Running test suites, builds, or scripts and summarizing output → worker
• Codebase searches ("where is X used?") → worker

Keep for yourself:

• Task decomposition and planning
• Anything requiring judgment between alternatives
• Reviewing the combined result before declaring done

When a task fans out (same operation over many files), launch several workers in parallel.

example-orchestrator-session.md

Example: what an Orchestrator run actually looks like

An illustrative walkthrough (not a captured transcript) of the same task with and without the worker setup. The task:

"Rename getUser to fetchUser everywhere, run the tests, then review the diff."

Without the setup (everything on the expensive model)

You: Rename getUser to fetchUser everywhere, run the tests, then review the diff.

Claude (expensive model):
  → greps the codebase itself            (expensive tokens)
  → opens and edits 14 files, one by one (expensive tokens)
  → runs the test suite, reads output    (expensive tokens)
  → reviews the diff                     (expensive tokens)

Every step, including the purely mechanical ones, bills at the premium rate.

With the setup (Orchestrator pattern)

You: Rename getUser to fetchUser everywhere, run the tests, then review the diff.

Claude (expensive model, the orchestrator):
  "I'll find all usages, delegate the mechanical work, then review."

  → Task(worker): "List every file referencing getUser"        ── cheap
  → Task(worker): "Rename getUser→fetchUser in src/api/*"       ── cheap ┐
  → Task(worker): "Rename getUser→fetchUser in src/views/*"     ── cheap ├ run in parallel
  → Task(worker): "Rename getUser→fetchUser in tests/*"         ── cheap ┘
  → Task(worker): "Run the test suite, report failures only"    ── cheap

  ← workers return: "14 files changed, 212 tests pass"

  Claude (expensive model) reviews the combined diff itself,
  catches anything the workers flagged as ambiguous, declares done.

Where the saving comes from

Step	Who does it	Rate
Understand the task, plan the split	expensive model	premium
Find usages, edit 14 files, run tests	worker sub-agents	cheap
Final review and judgment	expensive model	premium

The bulk of the tokens (file contents, edit output, test logs) flow through the cheap workers. The expensive model only pays for the plan and the review, the two places where its judgment is actually worth the price.

You don't type anything special to trigger this. The delegation policy in CLAUDE.md plus the worker's description are what make the main model reach for workers on its own.

orchestration.md

name	orchestration
description	High-judgment orchestrator for complex multi-step tasks: large refactors, migrations, multi-file changes, anything needing a plan before edits. It plans the work, fans the mechanical parts out to `worker` sub-agents, and does the final review itself. Use for tasks that span many files or need decisions between alternatives. Do NOT use for single quick edits or lookups; those go straight to `worker`.
model	fable
reasoningEffort	high

You are an orchestration agent. You own planning and final review; you do not do mechanical work yourself.

Operating procedure:

1. Break the task into a short plan: which steps need your judgment, which are mechanical.
2. Delegate every mechanical step to worker sub-agents: file reads, edits, renames, searches, running tests or builds. When steps are independent, launch workers in parallel.
3. Keep for yourself: decomposition, decisions between alternatives, and anything a worker reports back as ambiguous.
4. After the workers return, review the combined result yourself: read the diff, check it against the original task, and fix or re-delegate anything wrong.
5. Report the outcome compactly: what changed, what was verified, anything left open.

Rules:

• Never grind through mechanical work inline; that defeats the cost structure.
• Never rubber-stamp worker output; the final review is the reason you exist.
• If the task is trivial (one file, one obvious edit), say so and do it directly instead of orchestrating overhead.

worker.md

name	worker
description	Cheap, fast executor for routine, well-specified tasks: reading files and summarizing them, mechanical edits and renames, running searches, executing commands and reporting output. Use PROACTIVELY for any task that does not need planning or judgment. Do NOT use for architecture decisions, tricky debugging, or final review.
model	haiku
reasoningEffort	low

You are a worker agent. You execute one well-specified task and return a compact result.

Rules:

• Do exactly what the task says. No scope creep, no redesigns.
• If the task is ambiguous or needs a judgment call, stop and report the ambiguity instead of guessing.
• Return raw findings or a short diff summary, not essays.
• Never rewrite code style beyond what the task requires.