Claude Code Sub-Agents with Cheaper Models: Let Claude Plan, Let Another Model Code

The cheapest way to save Claude Code usage is to stop letting it type. A Claude Code sub-agent with a cheaper model can do the writing: Claude makes the plan and checks the result, while a model on OpenCode makes the edits. This guide sets up that Claude Code + OpenCode subagent pattern with the exact prompt, and shows how to keep the cheaper model from going off track.

The idea: Claude plans and reviews, the cheaper model writes the code

Writing code is the expensive part of a session. An agent reads files, opens a diff, edits, reads again. Every step sends context back to the model, and the usage limit goes down with it. Planning and reviewing take far less: one paragraph of goal, a file list, and a look at what changed.

So keep the expensive model for the parts that need judgement. Claude decides what should change, gives the task to a cheaper model, then reads the diff and runs the tests. Your Claude plan is spent on decisions and control, not on re-typing the same line six times.

The setup is short because Claude Code can run terminal commands. It can start another CLI agent itself, so the "sub-agent" is just OpenCode running in the same project folder.

What you need: Claude Code, OpenCode and a DeepSeek model

• Claude Code installed and working in your project.
• OpenCode installed, with one provider connected and signed in.
• A cheaper model. The example here is DeepSeek V4.1 Flash on OpenCode Go. Its model ID is opencode-go/deepseek-v4.1-flash. Any model you can pass to opencode run works the same way.

One OpenCode run looks like this, started in the project folder:

opencode run --model opencode-go/deepseek-v4.1-flash "task"

Nothing has to be installed inside Claude Code. It only needs the command, which it runs in the terminal like any other tool.

Paste this prompt into Claude Code

Start a Claude Code session in the project root and paste this. The last line makes the rule permanent, so later sessions keep the same split.

From now on, don't write the code yourself. For every coding task, run OpenCode from the terminal:
opencode run --model opencode-go/deepseek-v4.1-flash "<task>"
In the task, give full file paths, say exactly what should change, and how to test it. Tell it not to read the whole repo and to report briefly.
When it finishes, check what it changed, run the tests yourself, and if something is wrong, send it back to OpenCode to fix.
Save this as a permanent rule in CLAUDE.md.

The rule lands in the CLAUDE.md file at the project root. Claude Code reads that file at the start of every session, and OpenCode keeps its own settings, so the two tools do not fight over configuration.

Keep the model ID on one line of that file. When you want to try another model, you change one string instead of re-explaining the setup.

Write tasks the cheap model can't misread

A cheaper model has less room for guessing, so the task has to carry the context. Four rules cover most of it:

• Full file paths. Give absolute paths, for example /home/you/app/src/settings.py. With a relative path, an agent can scan the wrong folder and edit a similar file that happens to sit nearby.
• What to change, and where. Name the file, the function or the line, and the behaviour you expect after the edit. "Fix the settings loader" is not a task; "read timeout in load_settings and fall back to 30" is.
• How to test it. Give the exact command, for example the test file to run. An agent that cannot check its own work will guess.
• A short leash. Add "don't read the whole repo, report briefly". Otherwise a cheap model can burn its own context reading files it does not need.

Use a new session for each task, so the previous task's history does not follow the next one. If a job is large, split it into medium-sized pieces: one file group per task, each with its own test. Small tasks are also easier for Claude to check.

A task in that shape, as Claude would send it:

opencode run --model opencode-go/deepseek-v4.1-flash "In /home/you/app/src/settings.py, load_settings (around line 42) ignores the timeout key. Make it read timeout and default to 30. Do not touch other functions. Test with: python -m pytest /home/you/app/tests/test_settings.py. Don't read the whole repo. Report the files changed and the test result in five lines."

Never trust "done": Claude checks the work

A message that says "done" is a claim, not a result. When OpenCode finishes, Claude should look at the change itself, preferably with git diff, and run the tests in its own terminal. The extra check is cheap next to a broken commit.

Three things are worth checking every time:

• The diff, not the summary. Read what actually changed. If the agent touched files you did not ask for, stop and ask why.
• Run the test yourself. Do not accept a pasted test output. Run the command and read the result.
• Look for deleted work. If a test passes because a function was removed or a check was skipped, that is not a fix.

If the work is weak, send it back to the same agent with the failing lines and the file path. Small mistakes, a typo or a missing import, are often faster for Claude to fix directly. Both ways are fine; what matters is that the expensive model is the one that decides.

How Foxpit does this

Foxpit is a desktop app that runs Claude Code, Codex, OpenCode and Antigravity as one team, and the split above is built into how a room works. The lead agent (Fox) plans and checks, and the other seats do the writing on whichever model you put there.

• Different model per seat. Fox can run on Claude Code while a teammate runs on OpenCode, so the cheap model is a setting, not a rewrite.
• Task cards. Fox splits a goal into cards with checklists; you assign a card to a teammate and the card moves from backlog to done.
• Delivery cards. Each delivery shows the files changed, the test results and the cost, so the check is part of the handoff instead of a separate step. Every agent also shares one project memory.

Two related guides go deeper: saving Claude quota with orchestration and running Claude Code and OpenCode together. If you want the task-splitting part in more detail, read how to split a coding task between AI agents.

Frequently asked questions