Routing Claude Models by Task: When Haiku, Sonnet, and Opus Make
By MobileVibe Team · August 4, 2026 · 12 min read
Routing Claude Models by Task: When Haiku, Sonnet, and Opus Make Sense
Quick answer
Haiku is fast and cheap for simple refactors, test generation, and docs; Sonnet is the balanced default for most coding workflows; Opus handles complex architecture, large codebases, and long-context reasoning. Choose based on task complexity, iteration speed, and whether the agent runs unattended—then switch models mid-conversation when the work changes.
Key takeaways
- Haiku excels at narrow, well-defined tasks: formatting, simple tests, small edits, and quick iteration loops where speed and cost matter more than deep reasoning.
- Sonnet is the workhorse for everyday coding: feature implementation, debugging, moderate refactors, and most agent-driven workflows where you need reliability without Opus pricing.
- Opus justifies its cost when you face architectural decisions, large file counts, cross-module reasoning, or tasks that demand the longest context window and strongest reasoning.
- Model switching mid-conversation is practical: start with Haiku for scaffolding, escalate to Sonnet when logic gets complex, or drop back to Haiku for cleanup—MobileVibe’s approval gates let you change models when the agent asks for input.
- Multi-agent workstreams benefit from routing: run Haiku in a test-generation lane, Sonnet in a feature lane, and Opus in an architecture lane, each in its own folder or worktree.
Why Model Choice Matters When Agents Run Unattended
When you direct an AI coding agent from your phone and let it work while you’re away, the model you choose determines how far the agent gets before it needs you. A Haiku agent might breeze through ten small edits in the time Sonnet completes three—but Sonnet might solve a tricky bug Haiku would miss. Opus might architect a clean solution on the first try, but cost five times as much and take longer to respond.
The stakes are higher when the agent runs unattended. If Haiku hits a reasoning limit and produces broken code, you won’t know until you check back. If you route a simple task to Opus, you burn budget and wait longer for a response you could have gotten from Haiku. The right model keeps the agent productive, unblocked, and cost-effective while you’re doing something else.
haiku vs sonnet coding comes down to task complexity and iteration speed. Haiku is faster and cheaper; Sonnet is smarter and more reliable. Opus is the heavy lifter for when neither is enough. The best workflows route tasks to the right model and switch models when the work changes.
Haiku for Fast Iteration and Cost-Conscious Agents
When to use Haiku coding: formatting, linting, test generation from existing code, small refactors, documentation updates, and any task where the agent has a clear template or narrow scope. Haiku’s speed and low cost make it ideal for high-volume, low-complexity work—especially when you’re running multiple agents in parallel or iterating quickly.
Haiku shines in these moments:
- Generating unit tests from a function signature and a few examples. The logic is straightforward; Haiku can produce dozens of test cases faster than Sonnet.
- Formatting or linting a batch of files. Haiku applies rules mechanically and finishes in seconds.
- Simple refactors like renaming variables, extracting constants, or splitting a long function into smaller ones—tasks where the structure is obvious and the agent doesn’t need deep reasoning.
- Documentation updates where the code already exists and the agent just needs to describe it clearly.
Haiku’s context window is smaller than Sonnet’s, so it struggles with tasks that require reading many files or holding a large codebase in memory. Its reasoning is weaker, so it may miss edge cases, produce brittle solutions, or fail to connect the dots across modules. If you notice the agent repeatedly asking for clarification, producing code that doesn’t compile, or missing obvious bugs, Haiku has hit its limit.
Cost and speed trade-off: Haiku is roughly 5-10x cheaper per token than Sonnet and responds faster. For a task that takes Haiku 30 seconds and Sonnet 90 seconds, the speed difference compounds when you’re running ten agents or iterating on a tight loop. But if Haiku produces code you have to fix manually, the time savings evaporate.
Practical routing: use Haiku for the first pass on scaffolding, tests, or docs, then escalate to Sonnet if the agent gets stuck or the task grows more complex. MobileVibe’s approval gates let you switch models when the agent asks for input—start with Haiku, and if the next step needs deeper reasoning, approve with Sonnet instead.
Sonnet as the Balanced Default for Most Coding Workflows
Sonnet vs Haiku performance in real coding tasks: Sonnet handles moderate complexity, multi-file changes, debugging, and feature implementation without the cost or latency of Opus. It’s the model most developers default to for everyday agent-driven work.
Sonnet is the right choice when:
- Implementing a feature that touches multiple files, requires some design thinking, and needs to integrate cleanly with existing code.
- Debugging a tricky issue where the agent has to read stack traces, understand control flow, and propose a fix that doesn’t break other parts of the system.
- Refactoring a module where the logic is non-trivial and the agent needs to preserve behavior while improving structure.
- Reviewing diffs and suggesting improvements—Sonnet can reason about trade-offs and catch subtle bugs Haiku would miss.
Sonnet’s context window is larger than Haiku’s, so it can hold more files in memory and reason across a broader scope. Its reasoning is strong enough to handle most coding tasks without escalating to Opus. It’s slower and more expensive than Haiku, but the quality difference is noticeable: fewer broken solutions, fewer approval loops, and less manual cleanup.
When Sonnet isn’t enough: if the agent repeatedly asks for clarification, produces solutions that feel incomplete, or struggles with architectural decisions, the task may be too complex for Sonnet. That’s when you escalate to Opus.
Practical routing: make Sonnet your default for any task that isn’t obviously simple (Haiku) or obviously complex (Opus). Start conversations with Sonnet unless you have a specific reason to use a different model. If the agent finishes the hard part and just needs cleanup, you can drop back to Haiku for the final pass.
Opus When Complexity or Long Context Demands It
Opus is the most capable Claude model: the longest context window, the strongest reasoning, and the highest cost. Use it when the task demands architectural thinking, cross-module reasoning, or reading a large codebase—and when the cost is justified by the quality of the solution.
Opus makes sense for:
- Architectural decisions: designing a new module, choosing between patterns, or refactoring a system where the agent needs to understand the big picture and propose a coherent plan.
- Large codebases: tasks that require reading dozens of files, understanding dependencies, and making changes that ripple across the project.
- Complex debugging: issues where the root cause is buried in interactions between components, and the agent needs to trace execution across multiple layers.
- Long-context reasoning: tasks where the agent has to hold a lot of information in memory—long API docs, large config files, or a conversation history that spans many turns.
Opus’s cost is roughly 5x Sonnet’s per token, and its latency is higher. For a task that takes Sonnet two minutes, Opus might take five—and cost significantly more. But if Opus solves the problem on the first try and Sonnet would have taken three attempts, Opus is cheaper in total.
When Opus isn’t worth it: routine feature work, simple refactors, test generation, or any task where Sonnet would produce a good-enough solution. Opus’s extra reasoning power doesn’t help if the task is straightforward. Save Opus for the moments when you genuinely need it.
Practical routing: start with Sonnet for most tasks. If the agent gets stuck, produces incomplete solutions, or asks for more context than Sonnet can hold, escalate to Opus. If Opus finishes the hard part and the remaining work is simple, drop back to Sonnet or Haiku for cleanup.
Mixing Models Across a Multi-Agent Workstream
Multi-agent workflows benefit from routing different models to different lanes. If you’re running agents in parallel—one generating tests, one implementing a feature, one refactoring a module—each lane can use the model that fits its task.
Example setup:
- Haiku in a test-generation lane: a folder or worktree where the agent generates unit tests from existing code. Haiku’s speed and cost make it ideal for high-volume, low-complexity work.
- Sonnet in a feature lane: a folder where the agent implements a new feature, touching multiple files and requiring moderate reasoning.
- Opus in an architecture lane: a folder where the agent designs a new module, reads a large codebase, and proposes a coherent plan.
Each conversation is tied to a folder, an agent, and a surface (CLI or IDE). MobileVibe’s dashboard shows what’s blocked, what’s waiting for approval, and what’s still working. You can check each lane from your phone, approve the next step, and let the agents keep running.
Practical routing: use git worktrees or separate clones to isolate lanes. Start each conversation with the model that fits the task. If a lane’s work changes—Haiku finishes scaffolding and the next step needs deeper reasoning—switch models when the agent asks for input.
Approval Gates and Model Switching Mid-Conversation
Model switching mid-conversation is practical and common. Start a conversation with Haiku for scaffolding, escalate to Sonnet when the logic gets complex, or drop back to Haiku for cleanup. MobileVibe’s approval gates let you change models when the agent asks for input—no need to start a new conversation or lose context.
How it works:
- Agent asks for approval or input: the conversation pauses and waits for you to respond.
- You review the request from your phone: check the diff, read the agent’s message, and decide whether to approve, reject, or change direction.
- Change the model if needed: if the next step is simpler or more complex than the current model can handle, switch models before approving.
- Agent continues with the new model: the conversation history carries forward, and the new model picks up where the old one left off.
When to switch models:
- Escalate from Haiku to Sonnet if the agent gets stuck, produces broken code, or asks for clarification repeatedly.
- Escalate from Sonnet to Opus if the task grows more complex than expected—architectural decisions, large file counts, or long-context reasoning.
- Drop back from Opus to Sonnet or Haiku if the hard part is done and the remaining work is straightforward—cleanup, formatting, or simple edits.
Practical tip: if you’re unsure which model to use, start with Sonnet. If the agent breezes through the task, you could have used Haiku. If the agent struggles, escalate to Opus. Over time, you’ll develop intuition for which tasks need which model.
Testing Model Performance Before Committing to Production Agents
Testing model performance before committing to a long-running agent: run a small version of the task with each model, compare the results, and choose the model that balances quality, speed, and cost for your workflow.
Steps:
- Pick a representative task: a feature, refactor, or bug fix that’s typical of the work you want the agent to do.
- Run the task with Haiku, Sonnet, and Opus: start three conversations in the same folder (or copies of it), each with a different model.
- Compare the results: check the code quality, the number of approval loops, the time to completion, and the cost.
- Choose the model that fits: if Haiku produces good-enough code and finishes faster, use Haiku. If Sonnet’s quality is noticeably better and the cost is acceptable, use Sonnet. If Opus solves the problem on the first try and the cost is justified, use Opus.
Practical tip: test with tasks that are slightly harder than your average work. If Haiku handles the hard cases, it’ll breeze through the easy ones. If Sonnet struggles with the hard cases, you’ll know when to escalate to Opus.
FAQ
Should I use Haiku or Sonnet for writing code?
Sonnet for most coding tasks—feature implementation, debugging, moderate refactors. Haiku for simple, well-defined tasks like test generation, formatting, or small edits where speed and cost matter more than deep reasoning. Start with Sonnet unless you have a specific reason to use Haiku.
What’s the practical speed difference between Haiku and Sonnet for coding tasks?
Haiku responds roughly 2-3x faster than Sonnet and costs 5-10x less per token. For a task that takes Haiku 30 seconds, Sonnet might take 60-90 seconds. The speed difference compounds when you’re running multiple agents or iterating quickly, but Sonnet’s higher quality often saves time by reducing approval loops and manual fixes.
When should I upgrade from Haiku to Sonnet or Opus?
Upgrade to Sonnet if Haiku repeatedly asks for clarification, produces broken code, or misses obvious bugs. Upgrade to Opus if Sonnet struggles with architectural decisions, large file counts, or long-context reasoning. If the agent gets stuck or the task grows more complex than expected, escalate to the next model.
Can I start a conversation with Haiku and switch to Sonnet mid-task?
Yes. MobileVibe’s approval gates let you change models when the agent asks for input. Start with Haiku for scaffolding, escalate to Sonnet when the logic gets complex, or drop back to Haiku for cleanup. The conversation history carries forward, and the new model picks up where the old one left off.
How do I know if my agent is hitting Haiku’s context or reasoning limits?
Signs: the agent repeatedly asks for clarification, produces code that doesn’t compile, misses edge cases, or fails to connect the dots across modules. If you notice these patterns, the task is too complex for Haiku—escalate to Sonnet.
Is Opus worth the cost for routine coding tasks?
No. Opus is roughly 5x more expensive than Sonnet and slower. Use it for architectural decisions, large codebases, complex debugging, or long-context reasoning—tasks where Sonnet would struggle. For routine feature work, refactors, or test generation, Sonnet or Haiku is more cost-effective.
How do I set up different models for different folders or workstreams in MobileVibe?
Each conversation is tied to a folder, an agent, and a surface. Start a conversation in a folder with the model that fits the task—Haiku for test generation, Sonnet for feature work, Opus for architecture. Use git worktrees or separate clones to isolate lanes. MobileVibe’s dashboard shows all active conversations; you can check each lane from your phone and approve the next step.
What happens to a conversation if I change models while an agent is running?
The conversation pauses when the agent asks for approval or input. You can change the model before approving the next step. The conversation history carries forward, and the new model picks up where the old one left off. If you change models mid-task without an approval gate, the agent continues with the original model until the next pause.
Routing haiku vs sonnet coding tasks by complexity, cost, and iteration speed keeps your agents productive and unblocked while you’re away. Start with Sonnet as your default, drop to Haiku for simple work, escalate to Opus when the task demands it, and switch models mid-conversation when the work changes. If you’re running agents on your own machine and checking progress from your phone, try MobileVibe free—control Claude, Codex, Cursor, or Windsurf agents from anywhere, approve the next step, and let the right model finish the work while you’re doing something else.
