9. Model Selection Strategy (Fast vs Smart vs Cheap)

What this section is for

Model selection is not about picking “the best model.” It’s about picking the right model for the job you’re doing right now—and switching deliberately when the job changes.

This section gives you practical decision rules for:

• prototyping fast,
• handling complex refactors safely,
• switching models mid-project without chaos,
• controlling determinism for repeatable builds,
• building cost intuition so you don’t get surprised.

The three dimensions: fast vs smart vs cheap

Think in dimensions instead of brands:

• Fast: low latency, cheap enough for many iterations, good for scaffolding and routine coding.
• Smart: stronger reasoning, better at multi-step planning and complex tradeoffs, often slower and more expensive.
• Cheap: cost-efficient for high-volume or batch tasks, may require tighter constraints or more verification.

In practice, you rarely get all three at once. Your workflow should assume you’ll switch between “lanes.”

Model routing: the practical strategy

A pragmatic strategy that works in real teams:

• Default lane (fast): most iterations, small features, routine refactors, generating boilerplate.
• Design lane (smart): architecture choices, tricky refactors, debugging ambiguous failures, writing a plan you’ll actually trust.
• Scale lane (cheap): batch processing, large document sets, repeated tasks where you can constrain outputs heavily.

You don’t “choose once.” You route tasks.

Common failure modes (and what to change)

Failure: output is plausible but messy

• Often means: constraints and acceptance criteria are weak.
• Try first: tighten prompt structure (Section 10) and add tests (Section 7.3).
• Then: switch to a smarter model if you need deeper reasoning/refactoring.

Failure: you’re stuck in a loop (multiple failed attempts)

• Often means: the model can’t reason through the failure with current context.
• Try: provide better evidence (Section 8.1) and ask for hypotheses/tests (Section 8.2).
• Then: escalate to a smarter model for diagnosis only, not a full rewrite.

Failure: cost or latency is exploding

• Often means: prompts are too large, you’re repeating context, or retries are out of control.
• Try: context trimming (Section 11) and caching/dedup (see Part V+).
• Then: route high-volume tasks to a cheaper model with tighter schemas.

Section 9 map (9.1–9.5)

• 9.1 Choosing a model for prototypes
• 9.2 Choosing a model for complex refactors
• 9.3 When to switch models mid-project
• 9.4 Controlling determinism for repeatable builds
• 9.5 Cost intuition: tokens, context size, and repeated calls

Where to go next

• Start with 9.1 (prototypes)
• Then go to Section 10 (prompt structure)