Say your Claude Code bill hits $312 in one week. Restructure how you use subagents and the next week can come in around $124 for more work — same project, roughly 60% less spend. Those numbers are an illustration of the mechanics, not a measured run, but the fix they point at is real, and it is not "use a cheaper model."
The phrase to search is Claude Code subagents, and almost everything written about them treats them as a parallelism toy. They're actually a cost lever. That's the part nobody told me.
Why a single long thread bleeds money
Here's the thing that finally clicked. When you work in one giant Claude Code session, every message drags the entire conversation history with it. By hour three your context window is stuffed with old file dumps, dead-end attempts, and a log of you saying "no, the other file." You pay for all of it, every single turn.
A subagent gets a fresh, narrow context. It does one job, returns a tight summary, and its bloated working context evaporates. The main thread never sees the 8,000 tokens of file contents the subagent waded through — it sees the three-line answer.
That's the whole trick. Subagents are context isolation. Context isolation is cost control.
How I actually split the work
I build a feature in roughly four moves now, and I match each to who should do it.
The main agent stays the orchestrator. It holds the plan and almost nothing else. Then I delegate:
- A research subagent reads the codebase and reports back "here are the 4 files that touch auth and what they do." It chews through 20 files. I get a paragraph.
- A builder subagent writes the actual change against that paragraph.
- A reviewer subagent reads the diff cold, with no memory of how we got there, which makes it weirdly good at catching dumb stuff.
The reviewer being amnesiac is a feature. A fresh agent doesn't rationalize the code it just wrote.
You define these in .claude/agents/ as markdown files. A minimal one:
---
name: codebase-researcher
description: Finds and summarizes relevant files. Use before any change.
tools: Read, Grep, Glob
---
You locate the files relevant to the task and return a tight summary:
paths, what each does, and the 1-2 functions that matter. No code dumps.
Notice the tools line. I gave the researcher read-only tools. It physically cannot edit a file or run a command. That stops a whole class of expensive flailing where an agent "investigates" by running your test suite eleven times.
The mistake that cost me the most
Vague delegation. Early on I'd spawn a subagent with "fix the login bug." It would re-read the entire codebase from scratch because it had no idea where to look, burning the exact tokens I was trying to save. The subagent started from zero.
Now the orchestrator does cheap reconnaissance first, then hands the subagent a specific target: "In auth/session.ts, the refresh token isn't rotating. Fix only that function." Narrow input, narrow context, small bill.
If your subagent prompt doesn't name files, you're paying it to get lost.
When NOT to use a subagent
This surprised me. Subagents aren't free. There's overhead in the handoff, and if the task is tiny, spawning one costs more than just doing it inline. Renaming a variable? Do it in the main thread. A two-line change doesn't need a committee.
I use the smell test: if the task requires reading more than a few files to do well, isolate it in a subagent. If it doesn't, don't. Parallelism for its own sake is just a more expensive way to be slow.
The numbers, concretely
Where does a $312 week like that go? A huge chunk is the model re-reading the same four large files on basically every turn because they're pinned in the session context. Death by a thousand re-reads.
In the restructured week, the research subagent reads those files once, summarizes them, and the main thread coasts on the summary. The files enter context exactly one time instead of thirty. That single behavior change is most of the savings.
A few smaller wins stacked on top. I started clearing context between unrelated tasks instead of letting one session run all day. I stopped pasting giant logs into the main thread and let a subagent triage them. And I set cheaper models for the grunt research while keeping the strongest model for the actual building and reviewing — let the smart one think, let the fast one fetch.
My actual setup right now
Three agent files: researcher, builder, reviewer. The researcher and a log-triage agent run on a cheaper, faster model. Builder and reviewer run on the strongest model I've got, because that's where mistakes get expensive in a different way — bad code costs more than tokens.
The orchestrator's job is to stay light. The second the main thread starts holding file contents, I know I've messed up and I push that work into a subagent.
Shipping solo means your compute bill is your salary's roommate. Every token you don't waste is margin. Subagents aren't about going faster, though you do. They're about not paying to re-read the same file thirty times like I did.
Check your usage breakdown this week. I bet it's re-reads.