What I learned splitting Claude Code work across models, and what’s your setup?
For a while I ran everything on the strongest model: hard design work, but also quick emails, translations and “where is this function defined?” searches. It worked, but most of those tasks didn’t need it, and every side task made my main session longer and slower.
So I set up three subagents, each with its own model:
An email and Slack drafter on Haiku
A language translator on Sonnet, since translation needs more nuance
A read-only codebase explorer on Haiku that returns a short report instead of dumping files into my main session
Design, debugging and final review stay on the strongest model.
Two things surprised me. The explorer helped most, because searching the codebase in the main session fills it with files that don’t matter. And the hard part wasn’t the model choice, it was writing descriptions clear enough that the right agent gets picked.
I’m curious how others handle this:
Do you route different tasks to different models, or keep one model for everything? Why?
If you split work, where did you draw the line between “needs the strong model” and “doesn’t”?
Has anyone found a task where the cheaper model was actually worse in a way that cost more in the end?
Replies
One model wrote a fix and another wrote the test. Everything looked clean until the patch was reverted and the test still passed. The test never touched the actual bug. Break the code manually to watch it fail before trusting what the models agreed on.
@konstantin_tikhaev Did you use different models for testing and fix to prevent model bias? If so, did you use different different company (e.g. Claude vs. OpenAI) or different models within the same company (e.g. Opus vs Sonnet)
@playpakman Using Sonnet for the fix and GPT for the test to avoid shared company bias doesn't help. The test model still manages to test the wrong thing entirely.
In the coding session I kept one model for everything, translations included, and the reason is handoffs rather than quality. My app has 43 language files, and they're edited by the same agent that changed the English string, in the same step. The extra tokens are cheaper than a second agent misreading what the first one meant. Where I do split by model is inside the product, and that's where I have an answer to your third question. A song's title and the cover prompt run on a cheap model, and nobody has ever noticed. Then I tried the cheap one for the step that listens to the finished track and matches the sung words to the planned lyrics line by line, because singers drop lines and merge them. It missed a chorus where two lines were sung as one. The strong model heard it, and so did an independent transcription. So the synced lyrics were wrong on exactly the songs where someone would be reading along. Now the strong model does that step, about 24 seconds per song, and the cheap one keeps the jobs where a mistake is just a slightly worse title. My line after that: the cheap model is fine where a wrong answer looks wrong. Where a wrong answer looks right, pay for the strong one, because nobody is going to check.