Choosing Model and Effort for Four Task Profiles

1. The grep-and-list subagent — Haiku, low effort. This is exactly the profile Haiku is built for: a narrowly-scoped, low-judgment, read-only task with a mechanical output format. There's no ambiguity to reason through and no architectural judgment required, so paying for a larger model's reasoning would buy nothing. low effort fits because the task is short, latency-sensitive within a larger pipeline (this subagent is likely one of several running in parallel), and not intelligence-sensitive — a wrong guess here is just a missed line, trivially caught by whatever consumes the list next.

2. Live interactive debugging — Sonnet (or Opus if the codebase is unusually gnarly), high effort, with fast mode on. This is the textbook case for fast mode: response latency is the actual bottleneck, since a human is watching the terminal and waiting between turns, and fast mode delivers up to ~2.5x faster Opus responses at the same quality for exactly this kind of rapid-iteration, someone's-watching session. Sonnet at default high effort is the right baseline model — most flaky-test debugging doesn't need Opus-level reasoning depth, and if it turns out to, switching to Opus mid-session is straightforward. Effort level and fast mode are separate levers here: fast mode buys speed without touching reasoning depth, which is what this task actually needs, since lowering effort would risk missing the actual cause of the flakiness to save tokens on a task where a human is already paying the attention cost of watching in real time.

3. The resistant root-cause investigation — Fable 5, xhigh or max effort. This is precisely the profile Fable 5 is suited to per the subject's guidance: an ambiguous, multi-step investigation that has already resisted simpler approaches, where the value is in Fable 5's tendency to investigate and verify its own work more thoroughly than the other models before committing to a conclusion. The right prompting approach is to describe the outcome — find and explain the actual root cause — rather than prescribing steps, and let it plan its own investigation path. xhigh (or max, tested first given its overthinking risk) fits because this is squarely an intelligence-sensitive, not latency-sensitive, task: three prior engineers already failed on speed-over-depth attempts, so paying for deeper reasoning is the entire point, and there's no interactive human waiting turn-by-turn the way there is in scenario 2.

4. The unattended nightly lint-and-format CI job — Haiku or Sonnet, low or medium effort, standard mode (no fast mode). Lint-and-format is mechanical, well-specified work with a deterministic correct answer (the linter/formatter's own rules), so it doesn't need deep reasoning — low or medium effort is appropriate, trading some intelligence for lower cost since this runs every single night regardless of whether anything actually needs fixing. Fast mode is explicitly the wrong fit here: nobody is watching the terminal waiting on the response, so there's no latency to buy, and its higher per-token pricing is pure waste on a batch/CI job — the subject calls this out directly as one of the cases where standard mode, not fast mode, is the right choice.