# 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.