Use Opus for large implementations in the CLAUDE.md model split (#857)

* Use Opus for large implementations in the CLAUDE.md model split

Sonnet remains the default implementer for routine, well-scoped
changes; large multi-file features or refactors now use Opus, decided
at planning time.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Define the "complex" Opus trigger with concrete criteria

Addresses Copilot review feedback on #857: the heading promised Opus
for "large or complex work" but the body only defined the large
multi-file case. Add concrete examples of contained-but-complex
changes (subtle parsing/encoding logic, concurrency, paired
protocols).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Sean Whalen
2026-07-26 11:42:47 -04:00
committed by GitHub
co-authored by Claude Fable 5
parent a421747a79
commit f3689c3125
+1 -1
View File
@@ -7,7 +7,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
Any new feature or modification to an existing feature must follow this model split:
1. **Plan with Fable** (fall back to Opus only if Fable is unavailable). Enter plan mode, design the implementation, and present the plan to the user for approval or modification. Do not start implementing until the user approves the plan. Once the plan is approved, enter auto mode for the implementation and review.
2. **Implement with Sonnet.** Once the plan is approved, carry out the implementation using Sonnet (e.g. by delegating the implementation steps to Sonnet subagents via the Agent tool with `model: "sonnet"`).
2. **Implement with Sonnet by default; use Opus for large or complex work.** Once the plan is approved, carry out the implementation by delegating the implementation steps to subagents via the Agent tool. Use `model: "sonnet"` for routine, well-scoped changes (single-module edits, bug fixes, small features). Use `model: "opus"` when the approved plan is a large multi-file feature or refactor (e.g. a new output integration, or an RFC-level parser change touching `parsedmarc/__init__.py` plus types, tests, and docs), or when the change is complex even if contained — subtle parsing or encoding logic, concurrency, or a paired protocol (`__getstate__`/`__setstate__`, save/load, encode/decode) where one side is easy to get silently wrong. When in doubt, decide at planning time and note the choice in the plan.
3. **Review with Fable** (fall back to Opus only if Fable is unavailable). After implementation, all work must be reviewed by Fable before it is considered done.
**PR reviews** must also use Fable, with Opus as the fallback if Fable is unavailable.