Opus Shouldn't Do Grunt Work: Claude Code's Three-Layer Division of Labor, and One Wrong Constant That Fooled Every Test

Anthropic's documentation has an experimental switch that lets Claude Code run the main session with Sonnet and use Opus as an on-call advisor. The startup command is one line:

claude --model sonnet --advisor opus

The documentation is restrained: advisor is a server tool, requires the Anthropic API, and Claude decides when to consult. When consulting, Opus receives the full conversation, including tool calls and results, and then gives advice. It does not participate in every turn.

The main post breaks the division of labor down further:

Sonnet 5.5 runs the main session and writes code.
Haiku 5.5 does read-only exploration: search the repo, find call sites, pull docs.
Opus 5.5 stays nearby and intervenes only at three moments: before a plan is locked, after the same error appears twice, and before declaring the task complete.

In one sentence: Sonnet does the work, Haiku runs errands, Opus watches the key intersections.

The appeal of this setup is the bill. If Opus accompanies the whole run, the bill accompanies the whole run too. The documentation says the advisor is called only at decision points and is usually cheaper than running the strongest model throughout; the cost is that each consultation is billed at the advisor model rate, and the advisor reads the full transcript, which is not cached. It suits long tasks, repeated debugging, and work that needs an independent check before completion; it does not suit short jobs that need the strongest model every turn.

You can paste the following into Claude Code and have it rebuild your setup according to the tree:

Rebuild my Claude Code setup around this tree:
1. Main session on Sonnet 5.5, Opus 5.5 as advisor.
2. Three read-only Haiku 5.5 subagents: search, grep, docs.
3. Add one rule to CLAUDE.md: consult the advisor before locking a plan, after the same error twice, and before calling a task done.
4. Route fast deterministic forks through JEV.
Show every change as a diff first. No edits until I say go.

JEV is the fast fork layer in the original post, handling decisions that do not need 'thinking,' such as choosing files, choosing tools, retrying, or stopping. You can use the advisor without this layer; just do not treat it as mandatory.

The documentation says the model decides when to consult, and there is no switch to force a number of consultations. The main post condenses this into three moments; that is an operating rule, not hard coding.

There is an easy point of confusion here. The advisor is not responsible for spawning multiple subagents to work in parallel. It is more like the main model pressing an upgrade key at key nodes. AGTP's summary of Anthropic's new guidance warns in the opposite direction: reduce unnecessary subagents; a single agent plus skills is often more stable than a complex multi-agent system. The poster lists several numbers: about 2x execution speed, 15 agents merged into 1, agent team costs 1.8 to 5.1 times higher. Multi-agent is not useless either: in the same test, multi-agent found 66/70 planted bugs, while a single agent found at most 27. The difference lies in task shape, not agent count.

Someone in the replies put it directly: five agents each do one thing, and all the bugs live in the handoffs. Another said you should compare cost by each verified result, not by each run. That judgment is more reliable than 'multi-model is advanced.' If the division is accurate, the advisor is the brake and the steering wheel; if it is not, it is just another scheduling layer.

The truly chilling story is on the reverse-engineering side. NO1ennn wrote the full usage of REA, where REA lets a coding agent read binaries, inspect functionality, and reconstruct its own version of an MCP service and CLI. Opus 5.5 reads assembly, pseudocode, and call graphs, writes explanations and specs, and then lets an agent in another room rebuild from the spec. The process sounds like an assembly line—until a constant appears.

N0zoM1z0 encountered a function in the TH08 reconstruction record. It had already passed byte-by-byte comparison. Later, a downstream console port reported a bug with automatic item collection. The reconstructed code compared player power with 0.0; the original used 128.0, the full-power threshold. One constant, and the game behavior changed.

How did it fool the check? Before comparing instructions, the comparison tool adjusts addresses, because the reconstructed version may place the constant elsewhere. But the tool did not check the floating-point value stored at that address. The instruction bytes matched; the meaning did not.

The fix has two halves: change the source code so the comparison tool checks the actual bytes of the constants; audit all code that passed weak checks—1,548 floating-point literal references—and find 12 more errors, spread across 5 functions that had already been 'accepted.' N0zoM1z0's exact words were: Test the oracle too.

An oracle is any trusted reference used to judge whether a reconstruction is correct. A byte oracle compares machine code, a behavior oracle compares outputs for the same input, and a runtime oracle runs the program and observes it. The model proposes explanations; the oracle decides truth. The oracle is also software and also has bugs. A blind spot will not let just one function through; it will quietly approve hundreds.

This is two sides of the same thing as Claude Code's three-layer division of labor. The advisor puts the strong model at key forks and does not let it drown in routine work. The oracle puts judgment on verifiable checks and does not let the model's confidence replace facts. Both ask the same question: which step is worth spending the strongest judgment on?

The difference is that the advisor saves tokens, while the oracle saves rework. A setup that saves tokens can be copied directly; one command gets it running. A check that saves rework cannot be copied; you have to know what the goal actually cares about. FilmCraft's reconstruction team hard-coded a rule in AGENTS.md: do not read code from Adobe application packages; look only at behavior. They used behavior as the oracle and a clean room to separate reading from writing. That is how twelve applications came about.

REA's disclaimer also draws a line: security research, malware analysis, vulnerability research, CTF, interoperability, and auditing software you own are allowed. Bypassing DRM, license checks, anti-cheat, authentication, or copying proprietary code and assets is not. The output grants no rights to the original program, data, or generated artifacts. There is a line between reading and taking; the tool will not cross it for you.

So this Claude Code advisor setup is worth saving. It pulls Opus out of every turn and inserts it only at three points: planning, repeated errors, and completion judgment. But do not treat 'model division of labor' as quality assurance. First build an oracle that can fail for the task, then let it read anything. Opus speaking less can save money; Opus being wrong when it should speak costs another order of magnitude.