Routing Database Migrations to Opus and UI Polish to Haiku
By MobileVibe Team · August 28, 2026 · 13 min read
Routing Database Migrations to Opus and UI Polish to Haiku
Quick answer
Route heavy, schema-critical work—migrations, refactors, complex SQL—to Opus in one conversation, and lighter UI polish—button spacing, color tweaks, copy changes—to Haiku in another. Each conversation ties to a folder, an agent, and a model; you can’t swap models mid-thread without forking context. Running them in parallel on your real machine lets you approve Opus migrations carefully while letting Haiku iterate fast, all controllable from your phone.
Key takeaways
- One conversation = one model: Claude conversations lock to a model at creation; switching requires a new conversation or forking.
- Opus for migrations: schema changes, foreign keys, backfills, and complex refactors benefit from Opus’s reasoning depth.
- Haiku for UI polish: button alignment, color adjustments, copy tweaks, and simple CSS changes run faster and cheaper on Haiku.
- Separate folders or worktrees: keep migration work in one folder/branch and UI polish in another to avoid merge conflicts and context bleed.
- Approval gates: set Opus migrations to require approval before applying schema changes; let Haiku auto-approve low-risk UI tweaks where supported.
- Parallel monitoring: MobileVibe’s dashboard shows both conversations; pause, approve, or resume either from your phone.
Why Task Routing Matters When Running Multiple Claude Models
When you’re directing AI coding agents from your phone, not every task deserves the same model. A database migration that adds a foreign key, backfills a column, and updates three services needs Opus’s reasoning depth. A UI polish pass that adjusts button padding and swaps a color hex needs Haiku’s speed and cost efficiency. Routing migrations to Opus and UI polish to Haiku isn’t about being clever—it’s about matching the model to the risk and complexity of the work.
Claude conversations lock to a model at creation. You can’t start a thread on Haiku, decide halfway through that you need Opus, and seamlessly upgrade. The conversation’s context—its history, its folder, its agent surface—stays tied to the model you picked. If you want Opus for migrations and Haiku for UI tasks, you need two separate conversations, each in its own folder or worktree, each with its own approval rules and monitoring cadence.
This matters when you’re away from your desk. Your phone becomes the control surface for two agents running in parallel on your real machine. One conversation is deep in a migration, waiting for your approval to apply a schema change. The other is iterating on button spacing, auto-approving low-risk tweaks. MobileVibe’s dashboard shows both: what’s blocked, what’s working, what changed. You approve the migration, let the UI polish continue, and ship both when you’re back at your desktop.
The alternative—running everything on one model—wastes money or time. Opus on UI polish burns tokens on reasoning you don’t need. Haiku on migrations risks shallow solutions: it might generate a migration that works in the happy path but misses edge cases, foreign key constraints, or backfill logic. Task-based model selection is a real workflow optimization, not a theoretical exercise.
Setting Up Separate Conversations for Migration Work vs. UI Tasks
Start by deciding where each conversation lives. If you’re using git worktrees, create one for the migration branch and one for the UI polish branch. If you’re working in a monorepo with separate services, point each conversation to a different service folder. The goal is isolation: migration work shouldn’t touch UI files, and UI polish shouldn’t touch schema files.
In MobileVibe, each conversation ties to a folder, an agent (Claude CLI or IDE), and a model. Create the migration conversation first: open your migration folder, start a Claude session with Opus, and give it a clear initial prompt: “Add a user_id foreign key to the orders table, backfill existing rows with the default user, and update the order service to validate the constraint.” That conversation is now locked to Opus and that folder.
Next, create the UI polish conversation: open your UI folder or worktree, start a Claude session with Haiku, and prompt it: “Adjust the button padding on the checkout form to match the design system, swap the primary color to #3B82F6, and fix the mobile layout for screens under 375px.” That conversation is now locked to Haiku and that folder.
Both conversations appear in your MobileVibe dashboard. You can open either from your phone, see what each agent is doing, and approve or pause as needed. The conversations don’t share context—Opus doesn’t know about the button padding, Haiku doesn’t know about the foreign key—but that’s the point. You’ve routed the work to the right model and kept the concerns separate.
If you’re not using worktrees, you can still separate by folder: put migration scripts in db/migrations/ and UI work in src/components/. Point each conversation to the relevant subtree. The key is that each conversation has a clear scope and the right model for that scope.
Structuring Prompts So Opus Handles Schema Changes and Haiku Handles Polish
Prompts for Opus migrations should emphasize correctness, edge cases, and rollback safety. Example: “Add a created_at timestamp column to the users table. Write a migration that defaults to the current timestamp for new rows, backfills existing rows with their earliest login_at value, and includes a rollback script. Test the migration on a local copy of production data.” Opus will reason through the backfill logic, consider null handling, and generate a migration you can review before applying.
Prompts for Haiku UI polish should be specific and low-risk. Example: “Change the submit button color from #10B981 to #3B82F6, increase padding from 8px to 12px, and add a hover state with opacity: 0.9. Apply the changes to CheckoutButton.tsx and verify the mobile layout doesn’t break.” Haiku will make the changes quickly, and you can auto-approve them if you trust the scope.
The difference is in the stakes. Opus migrations touch the database schema, affect multiple services, and require careful review. Haiku UI polish touches presentation code, affects one component, and can be rolled back with a git revert. Structure your prompts to match: give Opus the context it needs to reason deeply, and give Haiku the constraints it needs to iterate fast.
Avoid mixing concerns in one prompt. Don’t ask Opus to “add a foreign key and also fix the button padding.” Don’t ask Haiku to “adjust the color and also backfill a column.” Keep each conversation focused on its model’s strengths.
Approval Gates: Letting Opus Migrations Run Unattended, Catching Haiku Regressions
Opus migrations should require approval before applying schema changes. In MobileVibe, you can set approval gates per conversation: Opus waits for your explicit approval before running a migration script, applying a schema change, or deploying a backfill. You see the proposed migration in the conversation, review it from your phone, and approve or reject. If you’re away, the agent stays paused until you’re back.
Haiku UI polish can often run with auto-approve enabled, depending on your risk tolerance. If the task is “adjust button padding and swap a color,” and you trust the scope, let Haiku iterate without blocking. If the task is “refactor the entire checkout form,” you probably want approval gates even on Haiku. MobileVibe’s approval controls let you tune this per conversation.
The trade-off is speed vs. safety. Opus migrations are high-risk, so you gate them. Haiku UI polish is low-risk, so you let it run. But if a Haiku task introduces a regression—say, it breaks the mobile layout—you catch it in the conversation history, pause the agent, and fix it. MobileVibe’s dashboard shows what changed, so you can spot regressions without opening your IDE.
In practice, you might approve an Opus migration from your phone during lunch, let it run while you’re in a meeting, and check the result when you’re back at your desk. Meanwhile, Haiku finishes three UI polish tasks, auto-approved, and you review the diffs in one batch. This is the workflow that makes routing migrations to Opus and UI polish to Haiku worth the setup cost.
Monitoring Two Agents in Parallel—and When to Pause One
Your MobileVibe dashboard is an inbox of what needs attention. Two conversations running in parallel means two entries: one for the Opus migration, one for the Haiku UI polish. Each shows its status—working, waiting for approval, blocked, or done—and its recent changes. You can open either conversation from your phone, see the agent’s latest output, and decide whether to approve, pause, or let it continue.
When to pause: if the Opus migration hits an error—say, the backfill script fails on a null value—pause it, review the error, and adjust the prompt or the migration script. If the Haiku UI polish introduces a regression—say, the button color change breaks contrast accessibility—pause it, revert the change, and refine the prompt. Pausing is cheap; letting a broken agent run wastes tokens and creates more cleanup work.
When to let both run: if the Opus migration is applying a schema change you’ve already approved, and the Haiku UI polish is iterating on safe tweaks, let both run. Check the dashboard periodically to make sure neither is blocked. If one finishes first, you can focus on the other.
The key insight is that parallel agents don’t compete—they work in separate folders, on separate concerns, with separate approval rules. You’re not context-switching between tasks; you’re monitoring two independent workstreams from one control surface. This is the “multi-agent operator” workflow: several lanes running at once, each with the right model and the right level of oversight.
Resuming a Stalled Migration from Your Phone
Migrations stall for predictable reasons: the agent hit a quota, needs re-auth, or is waiting for approval. MobileVibe’s dashboard shows which conversations are stalled and why. If your Opus migration is paused because it needs approval, you open the conversation from your phone, review the proposed schema change, and approve. The agent resumes on your real machine, applies the migration, and continues.
If the migration stalled because Opus hit a rate limit, you see that in the conversation. You can wait for the quota to reset, or you can adjust the prompt to break the work into smaller steps. If the migration stalled because it needs a manual step—say, you need to run a SQL script on production before the agent can continue—you handle that step, then resume the conversation with a follow-up prompt: “I’ve applied the SQL script. Continue with the service updates.”
Resuming from your phone is the core MobileVibe workflow. The agent session keeps running on your desktop; your phone is the remote control. You don’t need to SSH into your machine, open your IDE, or copy-paste context. You open the conversation, see where it stalled, and take the next action. For migrations, this often means approving a schema change, verifying a backfill, or confirming that a rollback script is safe.
The alternative—letting the migration sit paused until you’re back at your desk—wastes hours. With MobileVibe, you unblock the agent during a coffee break, let it finish while you’re in another meeting, and review the result when you’re back. This is why routing migrations to Opus matters: the model is expensive, but the workflow is efficient.
Common Pitfalls: Mixing Models, Losing Context, and Token Waste
Mixing models in one conversation: You can’t start a conversation on Haiku, decide halfway through that you need Opus, and seamlessly upgrade. If you realize mid-task that Haiku isn’t handling a migration well, you need to fork the conversation or start a new one with Opus. The context doesn’t transfer automatically; you’ll need to summarize the work so far in the new prompt.
Losing context across conversations: Opus doesn’t know what Haiku is doing, and vice versa. If the migration depends on a UI change, or the UI change depends on a schema update, you need to coordinate manually. This usually means finishing one conversation, verifying the result, and starting the next with a prompt that references the completed work: “The user_id foreign key is now in place. Update the checkout form to validate it.”
Token waste on the wrong model: Running Opus on button padding burns tokens on reasoning you don’t need. Running Haiku on a complex migration risks shallow solutions that you’ll need to fix later. Match the model to the task. If you’re unsure, start with Opus and downgrade to Haiku for follow-up polish.
Approval fatigue: If you set approval gates on every Haiku task, you’ll spend more time approving than the agent spends working. Tune your approval rules: gate Opus migrations, auto-approve Haiku polish where safe, and adjust based on what actually goes wrong.
Folder conflicts: If both conversations touch the same files, you’ll hit merge conflicts. Use separate worktrees, separate folders, or separate branches. Keep migration work in db/migrations/ and UI work in src/components/. If you need to merge both, do it manually after both conversations finish.
FAQ
Can I route the same conversation to different Claude models, or do I need separate conversations?
You need separate conversations. A Claude conversation locks to a model at creation; you can’t swap models mid-thread without forking or starting fresh. If you want Opus for migrations and Haiku for UI polish, create two conversations—one in your migration folder with Opus, one in your UI folder with Haiku. Each conversation maintains its own context and history.
How do I set up approval gates so Opus migrations don’t apply schema changes without my review?
In MobileVibe, you can configure approval gates per conversation. Set the Opus migration conversation to require approval before running migration scripts, applying schema changes, or executing SQL. When the agent proposes a migration, it pauses and waits for your approval. You review the proposed change from your phone, approve or reject, and the agent resumes. This prevents unreviewed schema changes from hitting your database.
What happens if a Haiku UI polish task introduces a regression while Opus is running migrations?
Both conversations run independently. If Haiku introduces a regression—say, it breaks the mobile layout—you see the change in that conversation’s history. Pause the Haiku conversation, revert the change, and refine the prompt. The Opus migration continues unaffected in its own folder. After you fix the Haiku regression, you can resume that conversation or start a new one. The key is that the conversations don’t interfere; they work in separate folders with separate concerns.
Can I pause a migration mid-task and resume it from my phone?
Yes. If the migration stalls—because it needs approval, hit a quota, or requires a manual step—MobileVibe’s dashboard shows the stalled conversation. Open it from your phone, see where it paused, and take the next action: approve the schema change, wait for the quota to reset, or confirm you’ve completed the manual step. The agent resumes on your real machine and continues the migration. This is the core MobileVibe workflow: unblock agents from anywhere, without SSH or desktop access.
How much does routing to Opus vs. Haiku cost, and when is it worth the trade-off?
Opus costs significantly more per token than Haiku—check Anthropic’s current pricing for exact rates. For a complex migration with deep reasoning, Opus might cost a few dollars but save hours of debugging. For UI polish, Haiku might cost cents and finish in minutes. The trade-off is worth it when the task matches the model: use Opus for high-stakes, complex work where reasoning depth matters, and Haiku for low-risk, repetitive work where speed and cost matter. Avoid running Opus on tasks Haiku can handle, and avoid running Haiku on tasks that need Opus’s depth.
Should I use the same folder for both migrations and UI tasks, or separate worktrees?
Separate worktrees or folders. If both conversations touch the same files, you’ll hit merge conflicts and context bleed. Use one worktree or branch for migration work (feature/add-user-id-fk) and another for UI polish (feature/button-polish). Point each conversation to its own folder. After both finish, merge them manually. This keeps the concerns isolated, the conversations focused, and the merge conflicts manageable.
Running Opus migrations and Haiku UI polish in parallel—each in its own conversation, each with the right approval rules—is a real workflow optimization when you’re directing agents from your phone. You route the heavy, schema-critical work to the model that can reason through edge cases, and the light, low-risk polish to the model that iterates fast. MobileVibe makes both conversations reachable from anywhere, so you can approve a migration during lunch and let UI polish finish while you’re in a meeting. Try MobileVibe free and see how task-based model routing changes the way you ship work from your phone.
