claude_settings/plans/zany-growing-penguin.md

Document Model Selection Strategy in CLAUDE.md

Goal

Create a clear, non-ambiguous rule for model selection (Haiku vs Sonnet vs Opus) that balances token costs with quality, avoiding false economies where cheaper models lead to more expensive debugging cycles.

Key Insight from Discussion

Using Haiku for execution with Opus for error recovery is likely more expensive in practice because:

• Context loss between models
• Opus must do blind forensics on Haiku's errors
• Error recovery costs more tokens than doing it right the first time

Model Characteristics

Haiku (claude-haiku-4-5)

• Speed: Fastest
• Cost: Cheapest per token
• Best for: Truly trivial, zero-risk tasks
• Risk: Higher error rate, weaker context understanding

Sonnet (claude-sonnet-4-5)

• Speed: Medium
• Cost: Medium (~3x Haiku)
• Best for: Most standard tasks, the "default choice"
• Risk: Good balance of speed/quality

Opus (claude-opus-4-5)

• Speed: Slower
• Cost: Highest (~5x Haiku)
• Best for: Complex tasks, deep debugging, critical systems
• Risk: Lowest error rate, best context understanding

Proposed Decision Tree

TASK COMPLEXITY:

1. Is this trivial? (git status, typo fix, read a single file)
   → HAIKU

2. Is this a standard task with a plan?
   Default: OPUS plans AND executes (one shot, no context loss)

   Exception: SONNET executes if BOTH:
   - Plan is super-straightforward (mechanical steps, no decisions)
   - AND error probability is very low (documented, tested system)

3. Complex/risky tasks?
   → OPUS (always)

Core Principle: Avoid model switches mid-task. Context loss costs more than using Opus from start.

Why Opus for execution too?

• Real-world execution rarely matches the plan exactly
• Opus can adapt on-the-fly without re-planning overhead
• Token-efficient when you factor in error recovery costs

Critical Files

• ~/.claude/CLAUDE.md - Global instructions to update

Implementation Plan

1. Add new section to CLAUDE.md after "Mandatory Workflow"

   • Title: "Model Selection Strategy"
   • Decision tree with concrete examples
   • Anti-patterns (what NOT to do)

2. Document these rules:

   • Default: Opus plans AND executes (one shot, no context loss)
   • Sonnet: Only for execution when plan is super-straightforward AND low error risk
   • Haiku: Only for truly trivial read-only tasks
   • Never mix models mid-task - context loss costs more than using Opus from start

3. Include real examples:

   • Haiku: git status, reading a single file, checking if a file exists
   • Sonnet (rare exception): Executing a well-tested deployment script when plan is 100% mechanical
   • Opus (default): Host scans, documentation, SSH operations, service restarts, debugging, anything with potential for surprises

4. Add anti-pattern:

   • ❌ "Opus plans, Sonnet/Haiku executes, Opus fixes errors" → Context loss costs more tokens
   • ❌ "Save tokens by using cheaper models" → False economy, error recovery is expensive
   • ✅ "Opus plans AND executes in one shot" → No context loss, adapts on-the-fly
   • ✅ "Only use Haiku for truly trivial read-only tasks"

Verification

• Read the updated CLAUDE.md section
• Verify the decision tree is unambiguous
• Check that examples are concrete, not vague
• User confirms it's no longer "schwammig"

Decision Made

After discussion, the strategy is:

• Opus as default for planning AND execution (one shot, no context loss)
• Sonnet only as rare exception when plan is 100% mechanical AND low error risk
• Haiku only for trivial read-only operations

Rationale: Context loss between models costs more tokens than using Opus from start. Real-world execution rarely matches plans exactly.