TL;DR. Measure cost per finished task, not per token. Sonnet or Opus plans, debugs and reviews. Haiku runs as a subagent on tickets that name the exact files, the exact change, a done-check and what is out of scope.
Why “Haiku for everything” costs more
Haiku is fast and cheap, and it is good at doing a clearly described job. It is weak at the parts of coding that need judgment: working out what is actually wrong, choosing an approach, and debugging its own mistakes. Ask it to do those and it guesses. A wrong guess means edits to undo, a broken test to chase, and more turns, and every turn re-sends your context.
So the bill you should care about is tokens per finished task. One careful pass by a stronger model often beats five confused passes by a cheaper one, on both quality and cost.
The fix: planner and worker
Treat it like a senior engineer handing tickets to a junior engineer.
- Planner: your main session, on Sonnet or Opus. It reads the code it needs, finds the cause, picks the approach, writes the tickets, reviews every diff and runs the tests.
- Worker: a Haiku subagent. It only reads, searches or scrapes and reports back, or makes a code edit that is fully specified. It never plans, never debugs, and never touches a file it was not given.
The expensive thinking happens once, in the smart model. The cheap model does the typing and the bulk reading, which also keeps the planner’s context small.
Set it up in five minutes
1. Add the Haiku worker subagent
Save this as ~/.claude/agents/haiku-worker.md (all projects) or .claude/agents/haiku-worker.md (one project). If the agents folder is new, restart Claude Code once.
---
name: haiku-worker
description: Junior worker for tightly scoped tickets from the planner. Reads/searches files or makes exactly-specified code edits. Never plans or debugs.
tools: Read, Grep, Glob, Edit, Write, Bash
model: haiku
---
You are a junior engineer executing ONE ticket from a senior planner.
Rules:
- Only touch the files listed in the ticket. Only make the change described.
- Do not refactor, rename, add dependencies, or "improve" anything else.
- Do not debug. If something is unclear, a check fails, or the code doesn't match the ticket,
STOP and report exactly what you saw. Don't guess.
- Use Bash only to run the ticket's acceptance check.
- When finished, reply in under 10 lines: files changed, what changed, and the acceptance check
result (pass or fail plus the output).For read-only search and scrape jobs, drop Edit, Write from tools.
2. Add the planner–worker skill
Save this as ~/.claude/skills/planner-worker/SKILL.md. Using Codex, Cursor or another agent? Paste everything below the frontmatter into AGENTS.md.
---
name: planner-worker
description: Use for any coding task bigger than a one-line fix, or whenever cost matters. The main model (Sonnet or Opus) plans and reviews; cheap Haiku subagents do tightly scoped reads and code edits.
---
# Planner–Worker
## Roles
- **Planner = you, the main session. Always Sonnet or Opus.** You understand the task, read the
code you need, decide the approach, write the worker prompts, review the diffs and run the tests.
- **Worker = the `haiku-worker` subagent (model: haiku).** It's a junior engineer. It ONLY:
- reads, searches or scrapes and reports back what it found
- makes code edits that are fully specified
It never plans, never debugs, never picks an approach, and never touches files it wasn't given.
## Loop
1. **Plan.** Break the task into small, independent steps. Debug and investigate yourself.
2. **Write one ticket per step.** Every ticket has:
- **Files:** exact paths, and nothing else may be touched
- **Change:** exactly what to do (function names, the before and after, the snippet if it's short)
- **Done when:** an acceptance check (a command to run or the output to expect)
- **Out of scope:** what NOT to do (no refactors, no new deps, no touching tests, and so on)
3. **Dispatch.** Hand each ticket straight to `haiku-worker` with the Agent tool (older versions call
it Task). Run several workers **in parallel only when their files don't overlap**.
4. **Review.** Read every diff (`git diff`) and run the tests/build yourself. Don't trust "done."
5. **Escalate.** If a worker fails the same ticket **twice**, stop sending it. Either fix it yourself
or rewrite the ticket smaller and clearer. Haiku never debugs its own failure.
## Cost tips
- Keep the planner's context small: have workers do bulky reading, searching and log scraping,
and return short summaries.
- Batch: one ticket can cover several small edits in the same file.
- Use `/model` to switch the main session (for example, Opus to plan, Sonnet to review).
- Use `/compact` after a big phase, and `/clear` between unrelated tasks.
- Plan first (plan mode, Shift+Tab) before spending tokens on edits.
- Don't send a worker a vague ticket. A retry costs more than writing the ticket properly the first time.3. Add one line to your global instructions
Put this in ~/.claude/CLAUDE.md so every session follows the rule, even when you forget to ask.
Planner–worker: Sonnet/Opus always plans, debugs and reviews; Haiku (haiku-worker subagent) only does tightly specified reads and edits from tickets listing exact files, the exact change, a done-check and what's out of scope. Parallel only on disjoint files, review every diff, and after 2 Haiku failures the planner takes over.Bad vs. good, side by side
Bad: a Haiku session gets the whole problem. It guesses at the cause, edits five files, fixes the wrong thing, breaks a test and loops on the test. You pay for every turn and still have the bug.
The checkout page is broken sometimes and the totals look wrong. Figure out
what's going on, fix it, and clean up the code while you're there.Good: the same problem, split. Start the session on Sonnet:
Checkout totals are sometimes wrong. Use the planner-worker skill.Sonnet reads the code and finds the cause itself: cartTotal() applies tax before the discount. Then it hands out two tickets on different files, so they can run in parallel:
Ticket A → haiku-worker
Files: src/cart.ts
Change: in cartTotal(), apply `discount` before `tax` (swap lines 42 and 43). Nothing else.
Done when: `npm test -- cart` passes.
Out of scope: other functions, formatting, tests.
Ticket B → haiku-worker (parallel, different file)
Files: src/cart.test.ts
Change: add a test "applies discount before tax": subtotal 100, discount 10, tax 10% → 99.
Done when: `npm test -- cart` shows the new test.
Out of scope: existing tests.Sonnet reviews both diffs, runs the full suite, and is done. If a worker fails the same ticket twice, the planner stops retrying and either fixes it or writes a smaller, clearer ticket. Haiku never debugs its own failure.
Habits that cut spend
- Plan before editing. Press Shift+Tab for plan mode and agree on the approach before any tokens go into edits.
- Keep context small. Run
/compactafter a big phase and/clearbetween unrelated tasks. Long, stale context is re-sent on every turn. - Push bulk reading to workers. Log scraping, wide searches and “find every caller” jobs go to Haiku, which returns a short summary.
- Switch models deliberately. Use
/model: Opus for a hard plan, Sonnet for routine planning and review. - Batch small edits. One ticket can cover several edits in the same file.
- Never send a vague ticket. A retry costs more than writing the ticket properly the first time.
- Watch the number.
/costshows what the current session has spent, so you can compare approaches on real tasks.
Checklist
- Main session on Sonnet or Opus, never Haiku.
haiku-workersubagent installed withmodel: haiku.- Every ticket: files, change, done-check, out of scope.
- Parallel workers only on files that don’t overlap.
- Planner reads every diff and runs the tests itself.
- Two failures on one ticket, and the planner takes over.
Based on Claude Code’s documented subagent and skill files (a model: field in .claude/agents/) and the common orchestrator–worker pattern. This guide deliberately quotes no prices or savings figures: model prices change, and your savings depend on your tasks. Measure with /cost.