Routing Refactoring to Sonnet and Features to Opus: A

Quick answer

Route refactoring, maintenance, and well-defined tasks to Sonnet for speed and cost efficiency; reserve Opus for complex feature work, architectural decisions, and problems requiring deep reasoning. When you’re running multiple agents across different folders or worktrees, model routing becomes a practical way to balance throughput, cost, and quality—especially when you’re monitoring and approving from a phone.

Key takeaways

• Sonnet excels at refactoring, test writing, and maintenance where the problem is clear and the solution pattern is known.
• Opus handles new features, architecture, and ambiguous requirements where deeper reasoning and context synthesis matter.
• Cost and latency differ significantly: Sonnet is roughly 5× cheaper and 2-3× faster than Opus on typical coding tasks.
• Parallel lanes by model let you run Sonnet agents on stable worktrees while Opus tackles the hard feature in another folder.
• Approval gates and monitoring become critical when you’re away from your desk—knowing which agent needs input and which can safely continue.
• MobileVibe’s conversation-first design makes it practical to route, monitor, and approve multi-agent workflows from your phone.

---

Why Model Routing Matters When You’re Running Multiple Agents

When you’re directing AI coding agents from your phone, you’re not just writing code—you’re orchestrating work across multiple conversations, folders, and models. The object you care about is the conversation: one agent chat tied to a folder, an agent (Claude, Codex, or another provider), and a surface (CLI, IDE, or headless). Your dashboard becomes an inbox of what needs attention: what’s blocked, what’s working, what changed, and what you can safely resume.

Model routing is the practice of choosing which Claude model (Sonnet, Opus, or Haiku) handles which conversation based on the task’s complexity, cost tolerance, and urgency. When you’re running several agents in parallel—often across git worktrees or related clones—routing becomes a practical lever for balancing throughput, cost, and quality.

Here’s why it matters:

• Cost control: Opus costs roughly $15 per million input tokens and $75 per million output tokens; Sonnet 3.5 costs around $3 input and $15 output. Over a day of agent work, the difference compounds.
• Latency and iteration speed: Sonnet responds faster, which means quicker approval cycles and more iterations per hour when you’re checking in from a phone.
• Quality where it counts: Opus’s deeper reasoning is wasted on straightforward refactoring but essential for ambiguous feature work or architectural decisions.
• Approval and notification flow: When you’re away from your desk, knowing which agent is running which model helps you prioritize which conversations need immediate review and which can continue under auto-approve rules.

MobileVibe’s lightweight Desktop Connector pairs your machine (macOS Apple Silicon or Windows 10+) and exposes agent sessions through a private, per-desktop tunnel. The work runs on your real computer with its filesystem, terminal, and tools—not a cloud sandbox. This means you can start a Sonnet refactoring agent in one folder, an Opus feature agent in another, and monitor both from your phone while the agents keep running on your own machine.

---

Sonnet’s Speed and Cost: The Right Tool for Refactoring and Maintenance

Claude Sonnet 3.5 is the workhorse model for tasks where the problem is well-defined and the solution pattern is known. It’s fast, cost-effective, and produces high-quality code for:

• Refactoring: extracting functions, renaming variables, splitting large files, or applying consistent patterns across a codebase.
• Test writing: generating unit tests, integration tests, or snapshot tests from existing code.
• Maintenance and cleanup: fixing linter warnings, updating dependencies, or applying security patches.
• Documentation: writing docstrings, README updates, or inline comments.
• Repetitive edits: applying a change pattern across multiple files (e.g., migrating from one API to another).

Sonnet’s speed advantage is real: on typical coding tasks, it responds 2-3× faster than Opus. When you’re checking in from your phone during the day to unblock agents, faster responses mean you can approve a change, see the next iteration, and move on—all within a single notification cycle.

The cost difference is equally significant. If you’re running a Sonnet agent for an hour on a refactoring task, you might spend a few dollars; the same task on Opus could cost $10-20 depending on context size and iteration count. Over a week of multi-agent work, Sonnet’s efficiency lets you run more lanes in parallel without blowing your budget.

When Sonnet is the right choice:

• The task has a clear spec or example to follow.
• The codebase is well-structured and the change is localized.
• You’re iterating quickly and need fast feedback.
• You’re running multiple agents and want to reserve Opus for the hard problems.

When Sonnet might struggle:

• The task requires deep architectural reasoning or cross-cutting changes.
• The requirements are ambiguous and need clarification through exploration.
• The codebase is unfamiliar or poorly documented, requiring significant context synthesis.

In practice, Sonnet handles 70-80% of everyday coding tasks. The key is recognizing when a task is “Sonnet-shaped” and routing it accordingly.

---

Opus’s Reasoning Power: When New Features Demand Deeper Analysis

Claude Opus is the model you reach for when the problem is hard, the requirements are ambiguous, or the solution demands architectural thinking. It’s slower and more expensive, but its reasoning depth makes it the right tool for:

• New feature development: building a feature from a vague product requirement or user story.
• Architectural decisions: choosing between design patterns, refactoring a module’s structure, or planning a migration.
• Complex debugging: tracing a subtle bug through multiple layers of abstraction or understanding an unfamiliar codebase.
• Cross-cutting changes: refactoring that touches many files and requires understanding the system’s invariants.
• Exploratory work: prototyping a solution when you’re not sure what the right approach is.

Opus’s advantage is its ability to hold more context in working memory and reason through trade-offs. When you’re starting a new feature from a phone—typing a task description and letting the agent figure out the implementation—Opus is more likely to ask clarifying questions, propose a sensible architecture, and handle edge cases without multiple rounds of correction.

When Opus is the right choice:

• The task is genuinely hard or novel.
• The requirements are ambiguous and need exploration.
• The cost of getting it wrong (e.g., a bad architectural decision) is high.
• You’re willing to wait longer and pay more for higher-quality output.

When Opus is overkill:

• The task is straightforward and well-specified.
• You’re iterating quickly on a known pattern.
• You’re running multiple agents and Opus would bottleneck your throughput.

In a typical multi-agent workflow, you might run one Opus agent on the hard feature in your main worktree and two or three Sonnet agents on refactoring, tests, and docs in parallel worktrees. This lets you make progress on multiple fronts while reserving Opus’s reasoning power for where it matters.

---

Setting Up Conditional Routing in Your Agent Workflows

Conditional routing means choosing the model based on the task’s characteristics. In practice, this looks like:

1. Manual routing at conversation start: When you start a new conversation (via email, CLI, or the MobileVibe dashboard), you specify the model explicitly. For example: claude-sonnet-3.5 for a refactoring task or claude-opus for a new feature.

2. Folder-based routing: You might have a convention where certain folders or worktrees always use a specific model. For example, main-feature/ uses Opus, while refactor-lane/ and test-lane/ use Sonnet.

3. Task-type heuristics: Some agent CLIs or wrappers let you define routing rules based on keywords in the task description. For example, if the task mentions “refactor” or “test,” route to Sonnet; if it mentions “new feature” or “architecture,” route to Opus.

4. Escalation on failure: If a Sonnet agent gets stuck (e.g., hits a quota, produces low-quality output, or asks for help), you can escalate by starting a new conversation with Opus in the same folder. This is a manual step today, but it’s a practical pattern when you’re monitoring from a phone.

In MobileVibe, routing happens at the conversation level. When you start a new conversation (e.g., by emailing a project or starting a CLI session), you specify the agent and model. The Desktop Connector exposes that conversation through the tunnel, and you can monitor, approve, and resume it from your phone. If you need to switch models, you start a new conversation in the same folder—MobileVibe doesn’t automatically copy history between models, but you can reference the previous conversation’s output or diffs.

In Claude CLI or IDE, you typically specify the model as a flag or config option. For example:

claude --model sonnet-3.5 "Refactor the auth module to use the new token format"
claude --model opus "Design a caching layer for the API and implement the core logic"

The key is making the routing decision explicit and documented so you (and your future self on a phone) know which agent is running which model and why.

---

Real Workflows: Parallel Lanes and Approval Gates by Model

Here’s a concrete example of when to use Sonnet vs Opus in a multi-agent workflow:

Scenario: You’re building a new API endpoint (hard feature work) while also refactoring the existing auth module and writing tests for the data layer.

Setup:

• Main worktree (main-feature/): Opus agent building the new endpoint. This is the hard problem—ambiguous requirements, architectural decisions, and cross-cutting changes. You’re willing to wait longer and pay more for quality.
• Refactor worktree (refactor-auth/): Sonnet agent refactoring the auth module. The task is clear: extract shared logic, rename variables for consistency, and add docstrings. Sonnet is fast and cheap, and the task is well-defined.
• Test worktree (test-data-layer/): Sonnet agent writing unit tests for the data layer. Again, the task is straightforward—Sonnet can follow the existing test patterns and generate coverage quickly.

Approval gates:

• The Opus agent in main-feature/ needs approval before making architectural changes (e.g., adding a new database table or changing the API contract). You get a push notification on your phone, review the proposal, and approve or ask for revisions.
• The Sonnet agents in refactor-auth/ and test-data-layer/ can run under auto-approve rules for low-risk changes (e.g., renaming variables, adding tests). You check in periodically to see what changed, but you don’t need to approve every step.

Monitoring from your phone:

• Your MobileVibe dashboard shows three conversations: one Opus (needs approval), two Sonnet (working or done).
• You open the Opus conversation, review the diff, and approve. The agent continues.
• You skim the Sonnet conversations to see what changed. One is done; the other is still working but doesn’t need input.
• You get an email notification when the test-lane Sonnet finishes. You review the test coverage and merge the worktree.

This workflow balances throughput, cost, and quality. Opus handles the hard problem; Sonnet handles the volume work. You monitor and approve from your phone, and the agents keep running on your own machine.

---

Cost and Latency Trade-offs Across Your Workstreams

Let’s make the cost and latency trade-offs concrete with a realistic example.

Assumptions:

• You’re running three agents in parallel for 2 hours.
• Each agent processes roughly 50,000 input tokens and generates 10,000 output tokens per hour (typical for a coding task with moderate context).

Sonnet (2 agents):

• Input cost: 2 agents × 2 hours × 50k tokens × $3/1M = $0.60
• Output cost: 2 agents × 2 hours × 10k tokens × $15/1M = $0.60
• Total: ~$1.20 for both Sonnet agents over 2 hours.
• Latency: Fast responses (typically 5-15 seconds per turn).

Opus (1 agent):

• Input cost: 1 agent × 2 hours × 50k tokens × $15/1M = $1.50
• Output cost: 1 agent × 2 hours × 10k tokens × $75/1M = $1.50
• Total: ~$3.00 for the Opus agent over 2 hours.
• Latency: Slower responses (typically 15-45 seconds per turn).

Combined: You spend ~$4.20 over 2 hours for three agents. If you ran all three on Opus, you’d spend ~$9.00—more than double. If you ran all three on Sonnet, you’d save money but risk lower quality on the hard feature work.

The latency difference matters when you’re approving from a phone. Sonnet’s faster responses mean you can iterate more quickly during a notification cycle. Opus’s slower responses mean you might approve a change, put your phone away, and check back later—which is fine for deep feature work but frustrating for quick refactoring tasks.

The trade-off: Sonnet lets you run more agents in parallel and iterate faster; Opus gives you higher quality on hard problems. The right balance depends on your budget, timeline, and task mix.

---

Monitoring Agent Performance by Model and Task Type

When you’re running multiple agents across different models, monitoring becomes critical. You need to know:

• Which agent is working, which is blocked, and which is done.
• Which agent needs approval or input.
• Which agent is producing high-quality output and which is struggling.

In MobileVibe, your dashboard is an inbox of conversations. Each conversation shows:

• The folder/project it’s tied to.
• The agent and model (e.g., Claude Sonnet 3.5, Claude Opus).
• The current state (working, needs approval, blocked, done).
• Recent changes (diffs, file edits, terminal output).

You can filter by state, model, or folder to see what needs attention. For example:

• “Show me all Opus conversations that need approval.”
• “Show me all Sonnet conversations that are still working.”
• “Show me all conversations in the main-feature/ folder.”

Performance patterns to watch:

• Sonnet getting stuck on hard problems: If a Sonnet agent repeatedly asks for clarification or produces low-quality output on a task you thought was straightforward, it might be a sign the task is harder than expected. Escalate to Opus.
• Opus being underutilized: If an Opus agent finishes quickly or produces output that could have come from Sonnet, you might be overpaying. Consider routing similar tasks to Sonnet next time.
• Approval bottlenecks: If you’re approving every Sonnet change manually, you’re not taking advantage of Sonnet’s speed. Set up auto-approve rules for low-risk changes (e.g., test additions, docstring updates).

Metrics to track (manually or with a simple log):

• Cost per conversation by model.
• Iterations per conversation (how many approval cycles before done).
• Time to completion by model and task type.
• Quality of output (subjective, but you’ll notice patterns over time).

Over time, you’ll develop intuition for when to use Sonnet vs Opus based on your own codebase and task mix.

---

When to Override: Exceptions and Edge Cases

Even with good routing rules, there are times when you’ll override the default choice:

Use Opus even for “simple” tasks when:

• The task is in an unfamiliar codebase or language where Sonnet might miss context.
• The task is low-risk but high-visibility (e.g., a public API change or a security fix).
• You’ve already tried Sonnet and it produced low-quality output.

Use Sonnet even for “hard” tasks when:

• You have a clear spec or example to follow, and the task is more about execution than reasoning.
• You’re prototyping quickly and plan to refine later.
• You’re running multiple agents and can’t afford to bottleneck on Opus.

Switch models mid-workflow when:

• A Sonnet agent gets stuck and you need Opus’s reasoning to unblock it. Start a new Opus conversation in the same folder and reference the Sonnet conversation’s output.
• An Opus agent finishes the hard part (e.g., architectural design) and you want to hand off the implementation to Sonnet. Start a new Sonnet conversation with the Opus output as context.

Edge cases:

• Haiku for trivial tasks: If you have very simple, low-stakes tasks (e.g., formatting code, generating boilerplate), Haiku is even cheaper and faster than Sonnet. But for most coding work, Sonnet is the better default.
• Opus for learning: If you’re exploring a new library or framework, Opus’s deeper reasoning can help you understand the concepts faster, even if the task itself is simple.

The key is staying flexible. Routing rules are guidelines, not laws. When you’re monitoring from your phone, you’ll develop a feel for when to override based on what you see in the conversation history and diffs.

---

FAQ

When should I route a task to Opus instead of Sonnet?

Route to Opus when the task requires deep reasoning, architectural decisions, or handling ambiguous requirements—such as building a new feature from a vague spec, debugging a subtle cross-cutting issue, or making a design choice with long-term consequences. Use Sonnet for well-defined tasks like refactoring, test writing, or maintenance where the solution pattern is known.

Does Sonnet cost significantly less than Opus, and is the speed worth the trade-off?

Yes. Sonnet costs roughly $3 per million input tokens and $15 per million output tokens, compared to Opus’s $15 input and $75 output. Sonnet is also 2-3× faster on typical coding tasks. For straightforward work, the speed and cost savings are substantial; for hard problems, Opus’s quality justifies the premium.

Can I switch models mid-conversation or do I need to start a new agent session?

You typically need to start a new conversation to switch models. In MobileVibe, each conversation is tied to a specific agent and model. If a Sonnet agent gets stuck, you can start a new Opus conversation in the same folder and reference the Sonnet conversation’s output or diffs. Claude CLI and IDE work similarly—you specify the model at session start.

How do I set up automatic routing rules in MobileVibe or my agent CLI?

MobileVibe doesn’t currently offer built-in automatic routing rules; you choose the model when starting a conversation (via email, CLI, or dashboard). In agent CLIs like Claude CLI, you can specify the model as a flag (e.g., --model sonnet-3.5 or --model opus). Some teams build simple wrappers or scripts that route based on task keywords or folder conventions.

What happens if Sonnet gets stuck on a refactoring task—can I escalate to Opus?

Yes. If Sonnet produces low-quality output or repeatedly asks for clarification, start a new Opus conversation in the same folder. You can reference the Sonnet conversation’s history, diffs, or terminal output to give Opus context. This is a manual escalation step, but it’s a practical pattern when monitoring from your phone.

Is it better to run one powerful agent (Opus) or multiple faster agents (Sonnet) in parallel?

It depends on your task mix and budget. If you have one hard problem and several straightforward tasks, run one Opus agent on the hard problem and multiple Sonnet agents on the volume work. This balances throughput, cost, and quality. If all your tasks are hard, you might run multiple Opus agents—but expect higher costs and slower iteration. For most developers, a mix of Sonnet and Opus across parallel worktrees is the sweet spot.

---

When you’re running multiple agents across different folders, models, and surfaces, routing becomes a practical tool for balancing cost, speed, and quality. Sonnet handles the volume work; Opus tackles the hard problems. MobileVibe makes it practical to monitor, approve, and resume those conversations from your phone—so you can keep agents running on your own machine and unblock them wherever you are. Try MobileVibe free and see how conversation-first multi-agent workflows change the way you build.