Model choice¶
Relative cost per token on the API, which is roughly how fast each burns Claude Code quota:
| Model | Input $/M | Output $/M | Relative |
|---|---|---|---|
| Haiku 4.5 | 1 | 5 | 1x |
| Sonnet 5 | 2 | 10 | 2x |
| Opus 5 | 5 | 25 | 5x |
| Fable 5.1 | 10 | 50 | 10x |
Pick by task, not by mood¶
- Haiku: running things and reading things. Build/test loops, log and DRC triage, web research, datasheet skimming. Anything where the answer is a pass/fail or a short list.
- Sonnet: writing code to a spec someone else wrote. Modules, tests, scripts, bulk edits. Good enough for most implementation when the interface is already decided.
- Opus: judgment calls. Architecture and API design, debugging when the cause is unclear, reviewing safety-critical hardware or security code, refactors that touch many files.
- Fable: the same class of work as Opus, but when the task is long-horizon and one session has to hold the whole picture: a multi-day board bring-up, a large migration, a problem that resisted Opus.
Signals that a problem is hard enough for Opus or Fable¶
- The worker has failed twice on the same task.
- There is no spec yet; the job is to decide what the spec should be.
- A mistake is expensive: fabrication, safety isolation, money, security.
- The fix requires understanding more than a few files at once.
- You are about to argue with the model about an approach.
If none apply, stay on Sonnet or Haiku.
Practical default for the orchestrator¶
Set the app's model picker to Opus for day-to-day sessions. Move it to Fable only for the long, hard sessions above. The delegation rule already keeps workers on Sonnet and Haiku regardless of what the orchestrator runs on, so the picker choice only affects the expensive seat.
Cheaper trick before upgrading models: on the same model, ask for more effort first. Newer models at low effort often beat older models at high effort, and effort is free to change.