Claude Code Orchestrates, Codex and OpenCode Build

I stopped paying for one big Claude plan. I now run a small Claude plan for the orchestrator and send the building to cheaper backends. The work did not get worse. The bill got smaller.

This page is my setup, written out in full. It is not a benchmark and it is not advice about your budget. It is what I run, why I run it, and the one measurement I have actually made.

Why one big plan is the wrong shape

Think about what each part of an agent session really does.

The orchestrator does judgement work. It frames the problem, decides what done looks like, splits the work, reads a diff with suspicion, and decides whether to accept or send back. That is a small number of tokens and a large amount of taste. You want your best model there, and you want it there all day.

The builders do volume work. They read a scoped file list, make a red test green, and hand back a diff. That is a large number of tokens and a narrow amount of taste. The task already carries the judgement. The tests already carry the acceptance criteria.

Paying premium rates for volume work is the mistake. So I split the two.

Tier 1: orchestrator

Frames the work, decomposes it, writes the tests first, dispatches, verifies, merges. Never builds.

Claude Code on Claude Fable 5.1

dispatches scoped units, with red tests attached

Tier 2: builders

Each one gets a worktree, a scope list, a failing test, and a test command. Nothing else.

Codex on a ChatGPT plan
OpenCode Go, flat monthly
Claude Opus 4.8 subagents
Claude Sonnet for research
Claude Haiku for mechanical work

returns a diff and verbatim test output, which is a claim, not a fact

Tier 3: verifier

Reads the diff adversarially and reports pass or fail per criterion. It never fixes anything. It runs on every unit, whatever built it.

Claude Opus 4.8 validator

My own plan mix is a smaller Claude plan for the orchestrator, a Codex plan on ChatGPT for delegated builds, and OpenCode Go at ten dollars a month for offloading. Those are my choices, not a recommendation. Plan tiers, limits, and prices change often, so check Claude pricing, ChatGPT pricing, and OpenCode pricing yourself before you copy my mix.

The setup prompt

Paste this into Claude Code in any project. It installs the orchestrate skill set, then drafts a dispatch-router skill with my routing table in it. It asks you which backends you actually have before it does anything else.

The setup prompt2,736 characters

Set up my Claude Code session as an orchestrator that delegates building to cheaper backends.

Work in this order and stop for me where I say stop.

STEP 1. Ask me, and wait for my answer, before you change anything:
a. Do I have the Codex CLI installed and signed in? Run `codex --version` to check.
b. Do I have the OpenCode CLI installed and signed in? Run `opencode --version` to check.
c. Which OpenCode model should be the cheap build lane? Default to glm-5.3.
Report what the two version commands actually printed. Do not guess. If a CLI is
missing, tell me the install command and stop.

STEP 2. Install the orchestrate skill set.
1. Clone https://github.com/cgraves09/claude-orchestrate-skill.git into a temporary
directory.
2. Run its ./install.sh. It copies skills/*/SKILL.md into ~/.claude/skills/<name>/ and
agents/*.md into ~/.claude/agents/. It skips any file that already exists there. Do
not pass --force unless I say so.
3. Show me the script's output and list which files were installed and which were skipped.
4. Delete the temporary clone.

STEP 3. Write a new skill at ~/.claude/skills/dispatch-router/SKILL.md. Do not overwrite
an existing file there: if it exists, show me a diff and ask. The skill body must contain
this routing table verbatim, as a markdown table, plus a one-paragraph description of when
to load it.

The skill must also state these rules:
- The orchestrator never builds. It frames, decomposes, writes tests first, dispatches,
verifies, and merges.
- Every dispatch names its model explicitly. An omitted model is a bug.
- A returned report is a claim. The orchestrator runs the tests itself before it counts.
- A unit that fails twice gets re-decomposed into smaller units. It never gets escalated
to a bigger model.
- External lanes run in their own git worktree, never on a main-line branch.

STEP 4. Show me the finished SKILL.md and tell me to start a new Claude Code session so
the skills load.

Do not change anything else in ~/.claude. Do not install anything I did not confirm in
STEP 1. If git or the network is unavailable, stop and tell me instead of working around it.

Free, ungated, no email required. Copy it as many times as you like.

Set it up

Install the Codex CLI. Run npm i -g @openai/codex, then codex and sign in with your ChatGPT account. Check the vendor docs for the current command before you run it.
Install the OpenCode CLI. Run npm i -g opencode-ai, then opencode auth login and pick your plan. Check the vendor docs for the current command before you run it.
Pick the cheap build model. In OpenCode, set the default model for your build lane. I use glm-5.3 for scoped builds and glm-5.3-flash for mechanical work.
Run the setup prompt above in Claude Code. It installs the orchestrate skill set and drafts the dispatch-router skill.
Add the lane pack template. Every external lane gets the same five sections. Copy the block below into your repo so the orchestrator fills it in rather than inventing a new brief each time.
Run the daily loop. Start a session, read NEXT.md, run /orchestrate <task>, let lanes run in worktrees, verify each result yourself, merge it yourself, run /compact, and repeat.

npm i -g @openai/codex
npm i -g opencode-ai
codex --version
opencode --version

The lane pack

An external model is not in your session. It has none of your context and none of your habits. So the brief has to carry everything, and the rules have to be explicit. This is the template I hand every external lane.

# Lane: <ticket id> <one-line title>

## Context
<what this repo is, what this file does, which convention to follow>

## Acceptance criteria
- <criterion 1, observable>
- <criterion 2, observable>

## Failing tests and the exact test command
Tests already written and currently red: <paths>
Run exactly this, nothing else: <command>

## Output contract
End your reply with `git diff --stat` and the verbatim test output.

## Self-check
Re-read your full diff. Remove any hunk that does not serve this task.
Walk each acceptance criterion and state met or not met with evidence.
Run the test command one final time after your last edit.

## Rules for this repo
- Work only in this worktree.
- Never switch, create, or delete a branch. Never push. Never open a PR.
- Never edit a file outside the scope list above.
- End with `git diff --stat` and verbatim test output.
- STOP and ask if anything is ambiguous. A wrong guess costs more than a question.

My dispatch.sh wrapper enforces the parts a prompt cannot. It refuses to run on a main-line branch, it runs the tests itself after the backend returns, and it writes a result.json with status (ok, backend_failed, timeout, tests_failed), diff_stat, files_changed, and test_exit. The orchestrator reads the file, not the model's summary of it.

The routing table

This is routing table v0. It is a starting point, not a law. Move a row when your own runs tell you to.

Kind of work	Where it goes	Why
Mechanical: renames, index regeneration, formatting	OpenCode glm-5.3-flash	No judgement needed. Speed and price win.
Research and code reading	Claude Sonnet subagent	Reads a lot, writes nothing. Cheap per token, good at search.
Scoped build with a red test and a small blast radius	OpenCode glm-5.3, or Codex gpt-5.6-terra when quota allows	The test carries the spec. The scope list carries the limits.
Hard build: editors, concurrency, crypto, shared contracts, unclear scope	Claude Opus 4.8 subagent	Domain judgement is the failure mode of a cheap lane.
Validation of every unit, whatever built it	Claude Opus 4.8 validator	The verifier is the only thing standing between a claim and a merge.
Prod-touching: migrations, secrets, deploys, payments	Never dispatched	It gates on a human. No model, no plan, no exception.

Why I compact so often

A small Claude plan lasts a full day only if the orchestrator context stays small. So I run /compact after every merged wave and every time a lane returns.

That works because the orchestrator does not need the history. It needs the current state, and the current state lives in two places that survive compaction:

Git. Branches, worktrees, and diffs are the record of what actually changed.
NEXT.md. A ledger file in the repo, capped at 150 lines. Older entries roll into an archive folder.

If a fact only exists in the chat scrollback, it is one /compact away from gone. So it goes in the ledger. Here is the skeleton I use.

# NEXT.md

## Now
- <the one thing in flight, with its branch name>

## Next
1. <next unit, with its acceptance criteria in one line>
2. <the one after that>

## Blocked
- <thing> waiting on <person or decision>

## Done this wave
- <ticket>: <what shipped> on <commit sha>

## Landmines
- <the thing that will bite the next session>

Calibration: what I actually measured

I did not want to trust a vibe about cheap models, so I ran a small protocol on 2026-09-08.

I took three tickets I had already closed. For each one I checked out the commit just before the fix, applied the red test from the real fix, and gave the lane the same lane pack a live ticket would get. Then I scored the returned diff with an Opus 4.8 validator.

Here is everything I found. It is a small sample and I am not going to dress it up.

OpenCode glm-5.3: promoted. Three of three green, zero P1 findings. This is now my default scoped-build lane.
kimi-k2.7-code: on hold. One P1. It hardcoded an English string instead of calling the repo's localization helper. The code worked. The judgement was wrong.
gpt-5.6-luna: on hold. Zero P1 findings, two P2 findings, and it was the fastest lane in the set.
Codex gpt-5.6-terra: not scored. The ChatGPT account hit its usage limit before the run finished. Codex is not calibrated in my runs. I keep it in the routing table because I use it, not because I measured it.

The lesson that surprised me: scope discipline was not the problem. Across nine lane runs, the cheap models stayed inside the scope list nine times out of nine. Every failure was domain judgement, not mechanics. That is exactly what the Opus validator is for, and it is why the validator does not get cheaper no matter what built the code.

You can run the same protocol in an afternoon. Pick three closed tickets. Check out the parent commit of each fix. Apply the red test. Hand the lane pack to the candidate model. Score the diff with a strong validator. Three tickets is not science, but it is far more than a guess.

Where the files live

The orchestrate skill set is public: github.com/cgraves09/claude-orchestrate-skill. It ships orchestrate, context-and-state, delegate-prompts, familiarize, orchestrator-delegation, tdd-protocol, validation-and-evidence, and workflow-patterns, plus the implementer, researcher, and validator agents. Clone it and run ./install.sh, or use the ready-made install prompt on the orchestrate skill page.

The dispatch-router skill and dispatch.sh are not in that repo yet. They are coming to the repo. Until then, the setup prompt above writes the skill for you from the routing table on this page.

FAQ

Do I need three paid plans to do this?

No. The split works with one Claude plan and nothing else, because Claude subagents can be the builders. The point is that the orchestrator and the builders are different jobs with different models. Adding Codex or OpenCode moves volume work off your Claude plan, which is a cost choice, not a requirement.

Why not just use a bigger model for everything?

Because a bigger model does not fix the failure mode. In my calibration the cheap lanes never broke scope. They lost on domain judgement, and the fix for that is a strong validator on every unit plus better lane packs, not a bigger builder.

Is Codex faster or better than OpenCode here?

I do not know. Codex hit a usage limit during my calibration run and was never scored. I use it, and it sits in my routing table, but calling it calibrated would be a lie. Only OpenCode glm-5.3 is calibrated in my runs.

What happens when a lane fails twice?

The unit gets re-decomposed into smaller units. It never gets escalated to a bigger model. Two failures on the same brief usually mean the brief was wrong, not that the builder was too small.

Does the orchestrator ever write code?

It writes the failing tests and it does trivial edits. It does not build features. It runs the tests itself, reads every diff, and does the merge itself. That is the whole point of keeping the best model in that seat.

How does the small plan survive a full day?

By compacting after every merged wave and after every lane returns, and by keeping the state in git and in a 150-line NEXT.md instead of in the chat. The orchestrator context stays small because it never needs to remember what the ledger already records.

Can I run this on a Windows or Linux machine?

Yes. Claude Code, the Codex CLI, and the OpenCode CLI all run outside macOS. Only the Ducktate part below is Mac only.

Is any of this safe to point at production?

Not the dispatch part. Migrations, secrets, deploys, and payments are never dispatched to any lane in my setup. They stop and wait for a person. Keep that row in the table exactly as it is.

If this saved you money, send it to someone still paying for one big plan. The link is ducktate.com/prompts/orchestrator-stack/.

One more thing

I dictate almost all of these prompts. A lane pack is long, and typing it out kills the habit. Ducktate is my Mac dictation app: hold a key, say the brief out loud, and it lands as clean text in whatever window you are in. That is the only reason my briefs are this detailed.

Talk to Claude instead of typing to it.

Ducktate turns what you say into clean text, on your Mac, and pastes it anywhere.

Get early access