Analyzing Opus vs Sonnet for Subagents · Entire

Does it make sense to also use opus for subagents?

I notice that subagents often use sonnet which doesn't make too much sense to me. What are the trade-offs?

Why Sonnet is the sensible default for subagents:

• ~5x cheaper than Opus, and subagent costs compound fast when you spawn several in parallel
• Most subagent work is bounded: grep/search, file reads, focused research, narrow implementation — Sonnet 4.6 handles these fine
• Faster turnaround, which matters because the parent is blocked waiting on foreground agents
• The subagent's job is often to filter raw output into a summary; the parent (Opus) does the synthesis

When Opus subagents earn their cost:

• Open-ended investigation where the subagent has to make judgment calls (e.g. "is this migration safe?")
• Code review / security review on non-trivial diffs
• Debugging that requires hypothesis generation across many files
• Anything where a wrong summary back to the parent silently corrupts your decision — Sonnet hallucinating a "looks fine" defeats the point

The asymmetry that makes the default reasonable:

If Sonnet gets a search task wrong, you notice quickly and re-run. If Opus gets a search task right, you paid 5x for the same answer. Reserve Opus for tasks where you can't easily verify the output.

Practical heuristic:

• lookup/search/mechanical → Sonnet (or even Haiku).
• Judgment/synthesis/review → Opus, especially when the parent will act on the result without re-reading source.

[f4711f2remove unused session-listing chain

Delete strategy.ListSessions, GetSession, and three private helpers along with their tests. The chain had no non-test callers in the repo.

Keeps Session/Checkpoint structs (still referenced by explain.go) and NoDescription/ErrNoSession (used elsewhere in the package).

Entire-Checkpoint: d6f9bf29997f-672]