Workflow

Model Selection

Choose the right model for planning versus execution.

Overview

Different Claude models have different strengths. Opus excels at complex reasoning and planning, while Sonnet provides fast, high-quality execution. By strategically choosing which model to use for each phase of work, you optimize for both quality and speed. Use the strongest model when decisions matter most, then switch to faster models for execution once the approach is clear.

When to use

Use this workflow for multi-phase projects, architectural decisions, complex refactoring, or anytime you need to balance deep thinking with rapid iteration.

Step-by-step process

Use the strongest model for planning

Start with Opus for tasks requiring deep analysis, architectural decisions, or complex tradeoff evaluation. Let it do the hard thinking upfront.

"Using Opus 4: Design our microservices architecture. Consider: service boundaries, data ownership, communication patterns, failure modes, scalability requirements. Propose 2-3 approaches with detailed tradeoff analysis."

Switch to a faster model for execution

Once the plan is approved, switch to Sonnet for implementation. It executes well-defined tasks quickly while maintaining quality.

"Switching to Sonnet 3.5: Implement phase 1 of the approved architecture plan—the user service with the patterns we discussed. Focus on execution, not re-evaluating the approach."

Confirm the plan before implementing

Before switching models, explicitly approve the plan. This prevents the execution model from second-guessing decisions made by the planning model.

"The Opus plan looks good. I approve: PostgreSQL for user data, Redis for sessions, REST for client communication, gRPC for inter-service. Now switch to Sonnet and implement without reconsidering these choices."

Return to stronger model for course correction

If implementation reveals issues with the plan, switch back to a stronger model to reconsider the approach rather than having the execution model make ad-hoc decisions.

"Implementation revealed a problem: gRPC doesn't work well with our deployment setup. Switching back to Opus: Propose alternatives for inter-service communication that work with standard HTTP load balancers."

Example prompts

Complex architectural decision

"Use Opus 4: We're hitting database performance limits. Analyze our schema and query patterns (attached). Should we: 1) Add read replicas, 2) Implement caching, 3) Denormalize tables, or 4) Move to a different database? Consider cost, complexity, and long-term maintainability."

Fast iteration on defined task

"Use Sonnet 3.5: We've decided to implement Redis caching (plan attached). Build the cache layer with: cache keys based on user ID and request path, 5-minute TTL, invalidation on user updates. Follow the implementation plan exactly."

Strategic planning then execution

"Phase 1 (Opus): Plan a migration from REST to GraphQL. Phase 2 (Sonnet): Once approved, implement the GraphQL schema and resolvers following the plan. I'll explicitly tell you when to switch models."

Debugging complex issues

"Use Opus 4: Users report intermittent auth failures. I've attached logs from 3 failures. The pattern is unclear. Analyze the logs, our auth flow, and propose a debugging strategy to isolate the root cause."

Expected outputs

Better planning

Stronger models provide more thorough analysis, identify more edge cases, and propose better-considered solutions

Faster execution

Faster models implement approved plans quickly without the overhead of reanalyzing decisions

Cleaner handoff

Explicit model transitions with approved plans prevent confusion and misaligned expectations

Cost optimization

Using expensive models only when necessary and cheaper models for execution balances quality with efficiency

Best practices

Use Opus for decisions that are expensive to change later—architecture, database schema, API contracts

Use Sonnet for well-defined implementation tasks where the approach is clear

Explicitly approve plans before switching models—don't assume the execution model should second-guess

Document which model made which decisions so you know when to revisit with a stronger model

Use Haiku for simple, repetitive tasks like formatting, basic refactoring, or test data generation

Common pitfalls

Using fast models for complex decisions

Solution: If a task requires weighing tradeoffs or making architectural choices, use Opus. Don't sacrifice decision quality for speed.

Not explicitly approving plans

Solution: Before switching to execution mode, clearly state: 'Plan approved. Now implement this exactly as designed.' This prevents re-planning during execution.

Staying on Opus for simple implementation

Solution: Once the approach is clear and approved, switch to Sonnet. Opus is overkill for straightforward execution tasks.

Pro tips

Mark the handoff point explicitly

""Planning phase complete (Opus). HANDOFF: Switching to Sonnet 3.5 for implementation. Approved plan attached. Execute phases 1-3 following this plan exactly.""

Use planning-execution-review cycle

""Opus plans → Sonnet implements → Opus reviews. This catches issues early while keeping implementation fast.""

Document model choices in commits

""In commit messages, note: 'Architecture designed by Opus' or 'Implementation by Sonnet 3.5'. This helps understand quality expectations when reviewing history.""

Related workflows

Think First Context Management Get Unstuck