Route Database Migrations to Opus, Everything Else to Sonnet
By MobileVibe Team · August 30, 2026 · 14 min read
Route Database Migrations to Opus, Everything Else to Sonnet
Quick answer
Route database migrations—schema changes, rollbacks, data backfills—to Claude Opus for its stronger reasoning and consistency guarantees, while keeping feature work, bug fixes, and iterative coding on Sonnet for speed and cost efficiency. Model routing by task type lets you optimize both quality and budget across your agent workload.
Key takeaways
- Opus for migrations, Sonnet for features is a practical routing strategy that balances quality, speed, and cost across your agent workload.
- Migrations demand stronger reasoning: schema changes, rollbacks, and data consistency checks benefit from Opus’s deeper analysis and fewer hallucinations.
- Sonnet excels at iteration: feature development, refactoring, and bug fixes run faster and cheaper on Sonnet without sacrificing quality.
- Model routing can be configured per conversation, per folder, or by task description in Claude Desktop, Claude CLI, or MobileVibe.
- Multi-agent lanes let you run migrations on Opus and features on Sonnet in parallel, each in its own folder or worktree.
- Monitor which model handled which task by checking conversation metadata, agent logs, or MobileVibe’s conversation history.
Why Split Your Agent Workload Between Opus and Sonnet
When you direct AI coding agents to build software, not every task demands the same level of reasoning. A database migration that touches production schema, foreign keys, and rollback logic requires deep consistency checks and careful planning. A feature branch that adds a new API endpoint or refactors a component benefits from fast iteration and multiple attempts. Routing opus for migrations sonnet for features lets you match the model’s strengths to the task’s risk and complexity.
Claude Opus offers stronger reasoning, fewer hallucinations, and better handling of multi-step logic—critical when a migration error could corrupt data or break production. Claude Sonnet is faster, cheaper, and still highly capable for the majority of coding tasks: writing tests, implementing features, fixing bugs, and iterating on feedback. By splitting your agent workload, you optimize for both quality and cost without manually switching models mid-conversation.
This strategy works best when you can describe the task type clearly—either in the conversation prompt, the folder name, or a routing rule. MobileVibe makes this practical by letting you start conversations tied to specific folders and agents, then monitor and approve them from your phone. You can run a migration lane on Opus in one folder and a feature lane on Sonnet in another, both reachable from the same mobile inbox.
When Migrations Demand Opus: Schema Changes, Rollbacks, and Consistency
Database migrations are high-stakes, low-iteration tasks. A migration that adds a column, renames a table, or backfills data must be correct the first time—rollback scripts must undo exactly what the forward migration did, foreign key constraints must be preserved, and data integrity must be maintained. Opus’s deeper reasoning and stronger consistency make it the right choice for these scenarios.
Schema changes often involve multiple interdependent steps: creating indexes, altering constraints, updating application code to match the new schema. Opus is better at reasoning through the full dependency graph and catching edge cases—like a nullable column that should have been non-nullable, or a missing index that will slow down production queries. Sonnet can handle straightforward migrations, but when the schema change touches multiple tables or requires careful ordering, Opus reduces the risk of subtle errors.
Rollback scripts are where Opus shines. A rollback must undo the forward migration exactly, without leaving orphaned data or broken constraints. Opus is more likely to generate a correct down migration that mirrors the up migration, handles edge cases like partial failures, and preserves data integrity. Sonnet may skip steps or assume rollback is trivial when it’s not.
Data consistency checks and backfills benefit from Opus’s ability to reason about data invariants. If you’re migrating user records from one table to another, Opus is better at ensuring no records are lost, duplicates are handled, and foreign keys remain valid. Sonnet may produce a working backfill script but miss edge cases that only appear in production.
When to use Opus for migrations: any schema change that touches production, any migration with a non-trivial rollback, any data backfill that must preserve consistency, and any migration that interacts with foreign keys, indexes, or constraints. If the migration is straightforward—adding a single nullable column with no dependencies—Sonnet is fine. If it’s complex or risky, route it to Opus.
Keeping Feature Work on Sonnet: Speed, Cost, and Iteration
Most coding tasks are iterative: write a feature, get feedback, refactor, add tests, fix bugs, repeat. Sonnet is optimized for this workflow—it’s fast, cost-effective, and capable of handling the majority of feature development without needing Opus’s deeper reasoning. Routing feature work to Sonnet keeps your agent workload efficient and your budget predictable.
Feature development typically involves writing new code, integrating APIs, building UI components, and adding tests. Sonnet handles these tasks well—it writes clean, idiomatic code, follows project conventions, and iterates quickly on feedback. If the agent makes a mistake, you catch it in review, provide feedback, and it corrects course. The cost of iteration on Sonnet is low enough that you can afford multiple rounds without worrying about budget.
Bug fixes and refactoring are natural fits for Sonnet. These tasks require understanding existing code, making targeted changes, and verifying the fix with tests. Sonnet’s speed means you can fix a bug, run tests, and ship the change in minutes—often from your phone if the agent needs approval or hits a quota. Opus would be overkill for most bug fixes unless the bug involves complex logic or data integrity.
Iterative feedback loops are where Sonnet’s speed pays off. You start a conversation, the agent proposes a solution, you review the diff, provide feedback, and the agent adjusts. On Sonnet, this loop is fast and cheap. On Opus, the same loop would be slower and more expensive, with diminishing returns—Opus’s deeper reasoning doesn’t help much when the task is “change this button color” or “add a new API parameter.”
Cost efficiency matters when you’re running multiple agents in parallel or working on a large codebase. Sonnet’s lower per-token cost means you can afford to let agents run longer, handle more conversations, and iterate more freely. Opus should be reserved for tasks where its reasoning justifies the higher cost—migrations, complex refactors, or high-risk changes.
When to use Sonnet: feature development, bug fixes, test writing, refactoring, documentation, and any task where iteration is expected and the cost of a mistake is low. If the task is straightforward and the agent can recover from errors quickly, Sonnet is the right choice.
Setting Up Model Routing in Your Agent Conversations
Model routing by task type can be configured at the conversation level, the folder level, or by task description. The goal is to make it easy to start a migration conversation on Opus and a feature conversation on Sonnet without manually switching models every time.
Conversation-level routing is the simplest approach: when you start a new conversation, specify the model in the prompt or the agent configuration. In Claude Desktop or Claude CLI, you can set the model explicitly when starting a conversation. In MobileVibe, you can start a conversation tied to a specific folder and agent, then specify Opus or Sonnet in the initial prompt. For example, “Run this migration on Opus” or “Build this feature on Sonnet.”
Folder-level routing is more scalable: dedicate one folder (or git worktree) to migrations and configure it to always use Opus, and another folder to features configured for Sonnet. This works well with MobileVibe’s multi-agent lanes—you can run a migration lane in migrations/ on Opus and a feature lane in feature-branch/ on Sonnet, both visible in your mobile inbox. Each conversation is tied to its folder, so the model choice persists across sessions.
Task description routing relies on the agent understanding the task type from the prompt. If you start a conversation with “Add a migration to rename the users table,” a well-configured agent can infer that Opus is appropriate. If you start with “Add a new API endpoint for user profiles,” the agent defaults to Sonnet. This requires clear prompts and may need manual override if the agent guesses wrong.
Claude Desktop and CLI support model selection per conversation. In Claude Desktop, you can specify the model when starting a new chat. In Claude CLI, you can set the model with a flag or environment variable. MobileVibe respects these settings—if you start a conversation on Opus in Claude Desktop, MobileVibe will continue that conversation on Opus when you open it from your phone.
Auto-approve and notification settings should reflect the model choice. Migrations on Opus may need stricter approval rules—you want to review the migration and rollback scripts before they run. Features on Sonnet can use more permissive auto-approve settings, since the cost of a mistake is lower and iteration is expected. MobileVibe lets you configure approval rules per conversation or per folder, so you can set tighter controls for migration lanes and looser controls for feature lanes.
Switching models mid-conversation is possible but not always ideal. If a migration conversation starts on Sonnet and you realize it needs Opus, you can manually switch models or start a new conversation on Opus and copy the context. MobileVibe makes this easier by letting you open the conversation in Claude Desktop or CLI, switch models, and continue from your phone.
Monitoring Which Agent Took Which Path
When you route tasks to different models, you need visibility into which agent handled which task and which model it used. This is critical for debugging, cost tracking, and understanding whether your routing strategy is working.
Conversation metadata in Claude Desktop, Claude CLI, and MobileVibe includes the model used for each message. In MobileVibe’s conversation history, you can see which model handled each turn—Opus or Sonnet—and filter conversations by model. This helps you verify that migrations ran on Opus and features ran on Sonnet as expected.
Agent logs provide more detail: which files were changed, which commands were run, and which model generated each response. If a migration fails, you can check the logs to see whether Opus or Sonnet was used and whether the failure was due to the model or the task itself. MobileVibe surfaces these logs in the conversation view, so you can review them from your phone.
Cost tracking is easier when you know which model handled which task. If your migration lane on Opus is consuming more budget than expected, you can review the conversation history to see whether the agent is iterating too much or whether the task genuinely required Opus’s deeper reasoning. If your feature lane on Sonnet is hitting quota limits, you can adjust auto-approve settings or split the work across multiple conversations.
Notification and approval flows should indicate the model. When MobileVibe sends a push notification that “Claude needs approval,” the notification should include the model and the task type—“Opus migration needs approval” or “Sonnet feature needs input.” This helps you prioritize which conversations to review first and which can wait.
Dashboard filtering in MobileVibe lets you view conversations by model, folder, or status. You can filter for “Opus conversations” to see all migration lanes, or “Sonnet conversations” to see all feature lanes. This makes it easy to triage which agents need attention and which are safe to let run.
Common Routing Mistakes and How to Avoid Them
Routing everything to Opus is wasteful. Opus is more expensive and slower than Sonnet, and most coding tasks don’t need its deeper reasoning. If you route feature work, bug fixes, and refactoring to Opus, you’ll burn through your budget and slow down iteration. Reserve Opus for high-stakes tasks—migrations, complex refactors, and anything where a mistake is costly.
Routing migrations to Sonnet by default is risky. Sonnet can handle straightforward migrations, but it’s more likely to miss edge cases, skip rollback steps, or produce inconsistent schema changes. If a migration touches production data or involves multiple tables, route it to Opus. The cost of a migration error is much higher than the cost of using Opus.
Not monitoring which model handled which task makes it hard to debug failures or optimize your routing strategy. If a migration fails and you don’t know whether it ran on Opus or Sonnet, you can’t tell whether the failure was due to the model or the task. Always check conversation metadata and agent logs to verify the model used.
Switching models mid-conversation without context can confuse the agent. If you start a migration on Sonnet, realize it needs Opus, and switch models without copying the context, the agent may lose track of what it was doing. Instead, start a new conversation on Opus and provide a clear summary of the task and any prior work.
Over-relying on task description routing without verification can lead to the wrong model being used. If you assume the agent will always infer the right model from the prompt, you may end up with migrations on Sonnet or features on Opus. Always verify the model in the conversation metadata and adjust if needed.
Not configuring approval rules per model means you may auto-approve a migration on Sonnet that should have been reviewed on Opus. Set stricter approval rules for Opus conversations—especially migrations—and more permissive rules for Sonnet conversations where iteration is expected.
Multi-Agent Lanes: Running Migrations and Features in Parallel
One of the most powerful patterns for opus for migrations sonnet for features is running multiple agent lanes in parallel, each in its own folder or git worktree, each tied to a different model. This lets you work on migrations and features simultaneously without context-switching or waiting for one agent to finish before starting another.
Separate folders or worktrees are the foundation of multi-agent lanes. Create a migrations/ folder for migration work and a feature-branch/ folder for feature work. Each folder gets its own conversation, its own agent, and its own model—Opus for migrations, Sonnet for features. MobileVibe treats each folder as a separate lane, so you can monitor both from your mobile inbox and approve or review them independently.
Parallel execution means you can let the migration agent run on Opus while the feature agent runs on Sonnet. If the migration needs approval, you review it from your phone and let it continue. If the feature agent hits a quota or needs input, you handle that separately. Both agents keep running on your own computer, and MobileVibe makes them reachable from anywhere.
Independent approval and notification is critical for multi-agent lanes. You don’t want a migration approval to block a feature approval, or vice versa. MobileVibe’s conversation-based inbox lets you triage each lane independently—approve the migration, let the feature run, or pause one while the other continues.
Folder-level model configuration makes it easy to enforce routing rules. If migrations/ is always configured for Opus and feature-branch/ is always configured for Sonnet, you don’t have to remember to specify the model every time you start a conversation. The folder determines the model, and the agent respects that choice.
Cross-lane coordination is possible but requires manual intervention. If the feature depends on the migration—for example, the feature uses a new column that the migration adds—you need to coordinate the order. MobileVibe doesn’t automatically sequence lanes, so you’ll need to monitor both and ensure the migration completes before the feature starts using the new schema.
Cost and quota management across multiple lanes is easier when you know which model each lane is using. If your Opus migration lane is consuming more budget than expected, you can pause it or adjust the task scope. If your Sonnet feature lane is hitting quota limits, you can split the work across multiple conversations or adjust auto-approve settings.
FAQ
When should I use Opus instead of Sonnet?
Use Opus for high-stakes, low-iteration tasks where deeper reasoning and consistency are critical: database migrations, schema changes, rollbacks, data backfills, and complex refactors that touch multiple files or systems. Use Sonnet for iterative, lower-risk tasks: feature development, bug fixes, test writing, and refactoring. If a mistake is costly or hard to undo, route it to Opus. If iteration is expected and the cost of a mistake is low, route it to Sonnet.
What are the key differences between Claude Opus and Sonnet for database work?
Opus offers stronger reasoning, fewer hallucinations, and better handling of multi-step logic—critical for migrations that involve schema changes, foreign keys, and rollback scripts. Sonnet is faster, cheaper, and capable of handling straightforward migrations and feature work. Opus is better at catching edge cases and ensuring consistency; Sonnet is better at iterating quickly and keeping costs low. For database migrations, Opus is the safer choice unless the migration is trivial.
How do I configure my agent to automatically route migrations to Opus?
Configure model routing at the folder level or by task description. Create a dedicated folder for migrations (e.g., migrations/) and configure it to always use Opus. In Claude Desktop or CLI, specify the model when starting a conversation. In MobileVibe, start a conversation tied to the migrations folder and specify Opus in the initial prompt. You can also rely on task description routing—if the prompt includes “migration” or “schema change,” the agent can infer that Opus is appropriate.
Can I run migrations and feature development in parallel with different models?
Yes. Use separate folders or git worktrees for migrations and features, each tied to a different model—Opus for migrations, Sonnet for features. MobileVibe treats each folder as a separate conversation, so you can run both agents in parallel and monitor them from your mobile inbox. Approve the migration independently of the feature, and let both agents keep running on your own computer.
What happens if Sonnet makes a mistake on a migration—should I always use Opus?
If Sonnet makes a mistake on a migration, review the error and decide whether to retry on Sonnet or switch to Opus. For straightforward migrations—adding a nullable column, creating a simple index—Sonnet can usually recover from feedback. For complex migrations—schema changes with foreign keys, rollbacks, or data backfills—switch to Opus to reduce the risk of repeated errors. Always review migration diffs before running them in production, regardless of the model.
How do I monitor which model my agent used for a specific task?
Check conversation metadata in Claude Desktop, Claude CLI, or MobileVibe. Each conversation includes the model used for each message—Opus or Sonnet. In MobileVibe, you can filter conversations by model and view the full conversation history, including which model handled each turn. Agent logs also show the model used, along with files changed and commands run. Use this metadata to verify your routing strategy and debug failures.
Routing opus for migrations sonnet for features is a practical way to balance quality, speed, and cost across your agent workload. Migrations demand Opus’s deeper reasoning and consistency; features thrive on Sonnet’s speed and iteration. With MobileVibe, you can run both in parallel, monitor them from your phone, and approve or review them independently—all while keeping your agents running on your own computer. Try MobileVibe free and start routing your agent workload by task type today.
