Opus Plans, Sonnet Builds, a Cheap Model from Another Vendor Audits

On October 6, 2026, @Jtyles asked: "Am I supposed to use Sonnet 5.5 or Opus 5.5? And on medium or max?" The post reached 705K views, which tells you how many people are stuck on the same question.

The best reply came from @Hexakin, and it reframed the problem. You are not picking one model. You are assigning jobs.

We agree. This page is the setup we now use from Claude Code: Opus 5.5 leads, Sonnet 5.5 does the bulk work as subagents, and a cheap model from a different vendor audits read-only through the opencode CLI. It is a manual pattern, not a product.

The three roles

The lead is the main session. Everything that needs judgment stays there.

The workhorse is a subagent. Claude Code's Agent tool takes a per-subagent model (for example sonnet), so the lead can spawn Sonnet workers without leaving the session. The worker gets a brief and does the typing.

The auditor is deliberately not a Claude model. It runs through opencode and gets called from the lead's shell like any other command.

Why the checker should be a different model

The model that did the work should not be the one that checks it. A model reviewing its own output shares its own blind spots, and a re-grep by the same session that made the edit tends to confirm what the session already believes.

A second model from a different vendor was trained differently and fails differently. It will not catch everything, but it catches different things. And because an audit is a narrow, read-only question (does this string still appear anywhere, do these routes match these files), it does not need a frontier model. A cheap one is enough, which means you can run it every time.

The loop

Five steps:

1. Scope. Opus writes a brief: what changes, what must not change, what done looks like.
2. Build. A Sonnet subagent executes the brief.
3. Review. Opus reads the diff.
4. Audit. An opencode auditor checks the result, read-only.
5. Close. Opus fixes whatever the audit found and reports.

The rules that keep it honest:

• Escalate up, never down. If a worker hits something ambiguous, it goes back to the lead. A worker never makes the call itself.
• The lead never delegates decisions, outward-facing actions (deploys, commits, publishing), or destructive changes.
• Hand off through files, not chat: the brief, the diff, the audit output. Files survive; a summary of a summary does not.
• Auditors never write. More on enforcing that below.
• Skip delegation for one-line jobs. Writing a brief costs more than the edit.

Wiring opencode as an auditor

This is the practical core. The command:

opencode run -m opencode-go/deepseek-v4.1-flash --agent plan --dir /path/to/repo "Audit. ... Report each hit as file:line, or say 'none'. Be brief."

For the other auditor, swap the model:

opencode run -m opencode-go/glm-5.3-flash --agent plan --dir /path/to/repo "Audit. ... Report each hit as file:line, or say 'none'. Be brief."

Ask for file:line or none. A fixed answer shape is easy for the lead to check and hard for a model to pad.

Why --agent plan

opencode ships a build agent whose permission rules start with "permission": "*", "action": "allow", which means allow everything. It also ships a plan agent that denies edit on every path except plan files (.opencode/plans/*.md in the project, plus opencode's global plans folder). You can inspect the rules yourself with opencode agent list.

Our first audit ran on build and behaved, but only because the prompt said "read-only". That is a request, not a control. The plan agent enforces it instead of the prompt. If an auditor misreads your instructions or wanders, it still cannot edit your tree.

Prove it

Do not take the permission model on faith. Checksum the working tree state before and after the run:

git status --short | md5
# run the audit
git status --short | md5

md5 is the macOS command. Identical output means nothing in the tree changed.

Other flags worth knowing

From opencode run --help:

• --format json emits raw JSON events, useful in scripts.
• -f attaches files.
• --variant sets provider-specific reasoning effort.
• --attach http://localhost:4096 reuses a running opencode server and skips the cold start.

The help also lists --auto, which auto-approves any permission that isn't explicitly denied and is flagged "dangerous!". Never use it for audits. It defeats the point of a read-only check.

One macOS note: there is no timeout command, so don't wrap the call in it.

A real run: removing 52 pages

On 2026-10-09 we removed 52 thin Midjourney SREF pages from this site. The change touched:

• the content folder and its images
• a route block in lib/routes-config.ts
• one _redirects line
• the sitemap and llms.txt entries
• inbound links on 8 pages

Opus did the scoping and the edits directly. The job was small enough that writing a brief for a subagent would have cost more than the work, so we followed our own rule and skipped delegation.

Then we audited. The prompt asked both auditors to search contents/, app/, components/, lib/, public/_redirects, public/llms.txt, and public/sitemap-0.xml for midjourney/sref.

GLM 5.3 Flash (plan agent) finished in 18 seconds. It searched the repo, then each folder, and answered: none in scope. Unprompted, it also flagged 9 hits in a drafts file outside the scope (wip/twitter/posts-v2.md) and correctly said they were out of scope.

DeepSeek V4.1 Flash (plan agent) gave the same answer and the same out-of-scope flag, at a similar speed. We did not time it precisely, so we won't put a number on it.

The git status checksum was identical before and after both runs.

The takeaway: two independent cheap models agreeing, one of them in 18 seconds, is a stronger after-check than the lead re-grepping its own work. It also surfaced something the lead had not asked about, which is the kind of thing a self-check rarely does.

A sidebar: why not the Antigravity CLI

We also tried Google's Antigravity CLI (agy) with Gemini 3.8 Flash High in plan mode. Headless with default permissions, it re-read whole files (a 163KB file four times), handed the search to a background subagent, reported success with no answer, and sat until the 180-second print timeout. With --dangerously-skip-permissions it answered correctly in 36 seconds, but at that point only plan mode and the prompt kept it from writing. That is why opencode's plan agent is our auditor.

Why not automatic routing?

The obvious objection is that a router could do this for you. @dani_avila7's Jev Model Router for Claude Code (September 18, 2026, 208K views) is the best-known attempt. It installs with npx claude-code-templates@latest --mod productivity/jev-model-router and uses TypeSafe's Jev decision model to choose a model tier (haiku, sonnet, or opus) and an effort level on every prompt and subagent spawn. For background on Jev itself, see our Jev guide and the model routing pattern.

We read the source. A lot of it is well judged:

• It fails open. An 800ms timeout or any error leaves the request alone.
• Upgrading needs only 0.3 confidence, while downgrading needs 0.6. It is biased toward spending more rather than silently under-powering a task.
• A "risky" score above 0.7 forces the deep tier.
• Main-model switching is off by default, because changing models mid-session breaks the prompt cache.

The limits, for our purposes:

• It classifies only the prompt text. Terse prompts like "do it" or "try again" carry almost no signal.
• Its alias-to-ID table maps opus to claude-opus-5 and haiku to claude-haiku-4-5-20251001. That looks stale if you turn main-model routing on.
• It only routes between Claude tiers. It cannot send an audit to another vendor, and cross-vendor checking is the whole point of the audit role.

None of this makes the router bad. It solves a different problem: guessing the right tier per prompt. Routing by role, decided once, beats guessing per prompt, because the role is already known before the prompt is written. The builder builds, the lead decides, the auditor reads.

Adding Hexakin's escalation loop

@Hexakin's reply (October 6, 2026, 94.7K views) described a setup close to ours: "Opus 5.5 on High as the orchestrator" and "Sonnet 5.5 Medium as the default for sub-agents", with Claude acting as judge of whether a sub-agent job needs the default or a stronger configuration.

His escalation idea is the part worth adding on top of the role split. Run a job on the lowest model and lowest thinking setting and record the output. If it falls short, re-run one step higher and record that too. Then write the best speed, cost, and quality compromise into the relevant skills, so the next run starts from what you learned instead of guessing again.

That turns "which model and which effort level" into something you measure once per kind of job and then stop debating. It sits comfortably inside the loop above: the brief the lead writes in the Scope step is where that recorded configuration gets used.

Limits and caveats

• Auditors add false positives. A model from another vendor catches different mistakes, but it also invents its own. The lead verifies a finding before acting on it.
• Your data leaves the machine. Prompt text and file contents go to the opencode provider, OpenCode Go in our case. Decide what you are willing to send.
• plan blocks edits, not everything. Check what else your opencode config allows, bash for example, before trusting it near secrets.
• It is manual. You write the briefs, run the commands, and read the output. Nothing here is automated, and we have not benchmarked it against other setups.

Start with one audit

You do not need to adopt the whole loop. After your next multi-file change, run one opencode plan audit before you commit. Checksum git status --short around it, read what comes back, and see whether a cheap second opinion from another vendor finds anything your own session missed.

Related Integrations

• Hooks + DeepSeek API: offload bulk generation to DeepSeek instead of auditing with it
• Driving Gemini with Ralph Loops: Claude designs, Gemini CLI executes with self-verification
• Claude Code Cost Optimization: task routing, session discipline, model selection
• OpenCode: setup, providers, and configuration for the auditor side