I Run Three Claude Instances as a Team. It Costs $3.50 Per Feature and Cuts My Rework in Half

Three weeks ago I was building a feature for Personably and hit the same wall I hit every time. One Claude Code session does everything. It plans the architecture, writes the code, reviews the output, and fixes its own mistakes. The first hour is sharp. By hour three, the context window is a landfill and the output quality starts to drift.

I had read about the agent teams pattern before. Strategy agent in Opus, execution agent in Sonnet, review agent in another Sonnet. Each one gets a clean context window and a narrow job. But I had been ignoring it because spinning up three sessions sounded like more work, not less.

Last week I finally tried it on a real feature. The result was not subtle. The code shipped with one round of review fixes instead of the usual three or four. The architecture held. The review agent caught things the execution agent would have missed in its own self-review, which is the whole point.

Here is exactly how I set it up, what it costs, and the CLAUDE.md template I use to give all three agents a shared brain.

The problem with one agent doing everything

The standard Claude Code workflow looks like this: you open a session, describe the feature, Claude plans it, writes the code, you review, Claude fixes, repeat. One context window absorbing every decision, every mistake, every correction.

Three problems compound inside that single window:

Context degradation. After about 50 messages, the agent is swimming in its own output. It forgets decisions it made 30 messages ago. It starts hallucinating files it has not actually read. The LangChain State of Agent Engineering survey found that quality is the number one production barrier, cited by 32 percent of teams. I would bet a lot of that quality loss is context rot.

Self-review blindness. Asking one agent to review its own code is like asking a writer to proofread their own article. It reads what it meant to write, not what it actually wrote. The same blind spots that produced the bug will also miss the bug.

Context cost compounding. Every wasted token in the planning phase carries forward into execution and review. By the end, the context window is 40 percent spent before the agent types a single new token.

The three-agent architecture

The pattern is from Startup Empire's agent teams framework. I adapted the cost tier and the handoff format for my own stack.

Strategy Agent (Opus 4.6, $15/$75 per M tokens)
    |
    |-- produces: plan.md, architecture decisions, file list
    |
    +--> Execution Agent (Sonnet, $3/$15)
    |       |
    |       |-- produces: implemented code, passing build
    |       |
    |       +--> Review Agent (Sonnet, $3/$15)
    |               |
    |               |-- produces: review comments, diff of fixes

Each agent gets exactly one input file and produces exactly one output file. No agent edits another agent's work directly. The files are the interface.

Strategy agent receives: the feature description and relevant codebase context. It produces a plan.md with architecture decisions, a file list of every file that needs to change, and the order of changes.

Execution agent receives: plan.md and the current codebase. It implements every change in order, runs the build, and produces a done.md listing every file changed and the build result.

Review agent receives: plan.md, done.md, and the full diff. It checks for alignment with the plan, obvious bugs, and violations of project conventions. It produces review.md with required fixes and optional suggestions.

I do the final merge. The agents never push. The review agent's output goes back to the execution agent for fixes if needed, or to me for approval if clean.

What it costs (real numbers)

The cost math is the part that made me finally try this. I was afraid it would triple my Claude bill. It does not.

Here is the cost for a typical feature on my jakebauman.io site:

| Agent | Model | Tokens In | Tokens Out | Cost | |-------|-------|-----------|------------|------| | Strategy | Opus 4.6 | 8,000 | 1,500 | ~$0.23 | | Execution | Sonnet | 12,000 | 2,000 | ~$0.07 | | Review | Sonnet | 10,000 | 800 | ~$0.04 | | Total | | 30,000 | 4,300 | ~$0.34 |

That is thirty four cents per feature. Even with larger features that triple the token counts, you are looking at a dollar. The real savings come from reduced rework. I used to do three or four review rounds per feature. Now I average one.

The key insight from the Startup Empire framework: do not use Opus for everything. It is five times more expensive than Sonnet. Opus is for thinking. Sonnet is for doing. My strategy agent uses about 8K input tokens because I give it focused context, not the whole codebase.

The shared brain: one CLAUDE.md for three agents

The teams pattern works because each agent has a clean context window. But clean is not the same as uninformed. If all three agents do not share the same rules, conventions, and project context, the review agent will flag things as errors that are actually intentional choices the strategy agent made.

The solution is a shared CLAUDE.md that every agent reads at session start. This is the shared brain pattern from the Claude Living Masterclass. One knowledge base, three agent runtimes.

Here is the template I use. Copy this, strip what you do not need, and save it as CLAUDE.md in your project root.

# CLAUDE.md -- Project Name

## Identity
You are an AI coding agent working on [PROJECT NAME], a [WHAT IT IS].
You serve [WHO THE USERS ARE].

## Goals
1. [Concrete outcome 1]
2. [Concrete outcome 2]
3. [Concrete outcome 3]

## Rules
- Never push to main. Open a PR.
- Run `npm run lint` and `npm run build` before declaring done.
- No em dashes in copy. Use periods, commas, or sentence breaks.
- [Any project-specific conventions]

## Workspace
- `src/app/` -- Next.js App Router pages
- `src/components/` -- Shared React components
- `src/lib/` -- Library code, types, utilities
- `content/` -- MDX articles and data files
- `public/images/` -- Static assets

## When You Are the Strategy Agent
- Your ONLY job is to produce `plan.md`.
- Read the feature request and the relevant source files.
- Output: architecture decisions, file list, change order.
- Do NOT write code. Do NOT review anything.

## When You Are the Execution Agent
- Your ONLY job is to implement `plan.md`.
- Follow the change order exactly.
- Run the build. If it fails, fix it before declaring done.
- Output: `done.md` with every file changed and build result.

## When You Are the Review Agent
- Your ONLY job is to review the diff against `plan.md`.
- Check for: alignment with architecture, missed files, convention violations, obvious bugs.
- Output: `review.md` with required fixes and optional suggestions.
- Do NOT rewrite code. Flag issues for the execution agent.

The role-specific sections are the part I had to figure out myself. The Startup Empire framework describes the three roles but does not give you the prompt format for each one. I spent an afternoon iterating on these sections until each agent reliably stayed in its lane.

What broke and what I fixed

Problem 1: The review agent rewrote code instead of flagging it. The first few runs, the review agent would produce a full corrected implementation instead of a review document. I added the explicit instruction: "Do NOT rewrite code. Flag issues for the execution agent." That fixed it.

Problem 2: The strategy agent tried to write code. Opus is smart. It sees a problem and wants to solve it. I had to add "Do NOT write code. Do NOT review anything." to the strategy section. The strategy agent produces a plan. That is its entire job. Giving it permission to stop at the plan is counterintuitive but necessary.

Problem 3: Context gating. My first attempt gave the execution agent the full CLAUDE.md plus the plan plus the full codebase. Context burn. Now I give each agent only what its role needs. The strategy agent gets the feature description and relevant source files. The execution agent gets the plan and the files to change. The review agent gets the plan, the change list, and the diff.

When to use this (and when not to)

The three-agent pattern makes sense for features that touch more than three files or involve architectural decisions. For a single-file bug fix, it is overkill. One Sonnet session is fine.

Here is my decision heuristic:

| Feature size | Pattern | Why | |-------------|---------|-----| | 1 file, no architecture change | Single Sonnet session | Overhead not worth it | | 2-3 files, simple changes | Single Sonnet, self-review | Marginal benefit from split | | 3+ files, architecture decisions, or data model changes | Three-agent team | Context cost of single session exceeds team overhead | | Cross-cutting changes across 5+ files | Three-agent team + one review round | Worth the extra review cycle |

The threshold is not about lines of code. It is about context complexity. If the agent needs to hold six files in its head to make a decision, split the work. The strategy agent can hold all six files, make the decision, and hand a clean plan to the execution agent that only needs to see one file at a time.

The copyable part

The CLAUDE.md template above is yours to use. Strip the sections that do not apply to your project. Add your own conventions. The role-specific sections at the bottom are the part I had to figure out through trial and error, and they are the part that makes the pattern actually work.

If you try this, start with one feature. Do not reorganize your entire workflow at once. Pick a feature that touches three or four files, write the plan by hand once so you know what good looks like, then turn the agents loose and compare their output to yours. The first time you see the review agent catch something you would have missed in self-review, you will understand why the extra five minutes of setup is worth it.

I am still iterating on the handoff format between agents. The current version uses markdown files in a .claude/plans/ directory. I may eventually build a small CLI tool that manages the three files and routes them automatically. But for now, the files are the interface, and that simplicity is keeping the whole thing from collapsing into a context management problem of its own.