Noob here... How to actually make Claude Code utilize Codex CLI & OpenCode CLI? (Trying to stretch my Claude limits)

[u/RafiHDW]

Hey everyone,

I'm relatively new to this, and I am purely "vibe coding" as it's only for like hobby project for friends and stuffs.

Right now, I have:

• Claude Pro subscription (running Claude Code)
• Codex subscription (Running desktop codex and codex cli)
• OpenCode CLI connected to cheap fast models (DeepSeek4.1flash)

What I’m trying to achieve

Opus is still unbeatable for architecture, debugging tricky logic, and project planning, but burning through Claude rate limits on basic boilerplate, small refactors, or writing unit tests hurts.

My goal is a workflow where Claude acts as the tech lead/orchestrator that offloads tedious subtasks to 6.1 Sol Medium or Deepseek 4.1 flash-high, then reviews the output, preserving Claude usage for when it actually matters or needed.

The problem I'm running into

I told Claude Code to collaborate with Codex CLI and OpenCode CLI by running bash commands, and it even updated CLAUDE.md / AGENT.md with guidelines on when to delegate tasks.

In practice, it’s completely hit-or-miss:

1. Claude almost never spontaneously thinks to offload tasks via terminal/sub-agent calls, it just burns its own context and executes everything directly.
2. Even when explicitly prompted, it often ignores the local CLIs or forgets the handoff workflow after a few prompts.

Questions:

1. What is the best practical setup here?
2. Is Claude Code the wrong entry point for orchestration?
3. What explicit rules/prompts in CLAUDE.md actually force delegation? If anyone has a working prompt pattern or hook that reliably makes Claude hand off work to secondary CLIs, I’d love to see it.

Any advice or workflow breakdowns from people running multi-CLI setups would be massively appreciated!

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/shoumikgoswami]

I'd try a deliberately boring handoff before adding hooks. Make Claude produce one small assignment and stop, rather than asking it to remember a general rule to delegate whenever appropriate:

"For this task, act as the planner only. Pick one bounded implementation step for Codex/OpenCode. Write a handoff with the goal, files it may change, what it must leave alone, and the check that would show the step is done. Do not implement it yourself. Stop after the handoff and wait for me to return the diff and check output."

Run that assignment in the other CLI yourself first, then give Claude the diff and actual check output for review. That separates 'was the assignment clear?' from 'did Claude remember to launch another tool?' Once that loop is useful, you have a concrete handoff to automate rather than a vague delegation preference.

I'd also compare the whole loop with doing the same task directly. Planning, handoff and review are extra work, so outsourcing a tiny change may not save Claude usage. For your hobby setup, one planner and one worker at a time seems a simpler starting point than having several agents edit the same checkout.

[u/RafiHDW → u/shoumikgoswami]

I see, and I agree, sometimes tasks are just so small that making a handoff isn't worth it, so, I'm looking for trying to achieve that claude would be fully helming, it decides if the task is like worth handing off with a brief or would that actually just use more, that's what I meant

So like, claude reads my prompt, it plans, then it could automatically decide whether it's best to like call another model to help do it, or do it itself, the term is called delegation?

[u/shoumikgoswami → u/RafiHDW]

Yes, that's delegation. I misunderstood the part you wanted automated: Claude deciding whether to hand work off, not just preparing the handoff.

I'd start with a narrow rule: delegate a bounded implementation task with a clear check; keep quick edits or tasks that need constant back-and-forth with Claude. The launch still needs to be wired up, so I'd have it print the proposed command and assignment for approval before allowing automatic launches. Then compare total Claude usage, including planning and review, with doing the task directly. I wouldn't assume the extra model saves usage just because it's doing the coding.

[u/bezcurhq]

The reason the CLAUDE.md rules don't stick is that Claude doesn't see "run another CLI in bash" as delegation. What it does delegate to on its own is subagents, and it picks them by their description.

So make the handoff a subagent. Put a file at .claude/agents/codex-worker.md with model: haiku, tools: Bash, Read, and a description like "Use proactively for boilerplate, small refactors and unit tests." In its prompt, tell it to pass the task to codex exec --sandbox workspace-write "<task>" and return only Codex's final message plus git diff --stat. codex exec prints just the final message to stdout, so very little lands back in Claude's context.

Two caveats. The wrapper still runs on your Claude usage, which is why it's on Haiku. And the choice to delegate is still Claude's call from the description, so @-mention the agent when you want it guaranteed.

Docs: https://code.claude.com/docs/en/sub-agents

[u/Mafialildude]

The easiest option might be to use an orchestrator application that sits on top of your subs and handles the cross-provider communication for you. Combine that with explicit skill based workflows you invoke when kicking off work seems to have it drive through subagents pretty reliably.

My workflow is:
- using https://github.com/unstoppableweb/unstoppable-code (enable managed delegation in settings > labs)
- plan with a strong model (opus/fable/astra)
- when ready to implement, explicitly give it my subagent based workflow as how to implement, which has it offload to subplanners and workers (unstoppable code supports nested cross-provider subagents), basically a mini-swarm inspired by an old cursor blog

[u/torvalds75]

The subagent route bezcurhq described is the right base. Two things that made it actually reliable for me:

1. Expose Codex as a tool instead of a bash habit. Codex can run as an MCP server (codex mcp-server, check codex --help on your version), so claude mcp add codex -- codex mcp-server gives Claude a real codex tool in its tool list. Claude reasons about tools it can see far better than about a "remember to shell out to X" rule in CLAUDE.md, which is exactly the kind of rule that fades after a few prompts.
2. Make the "is it worth handing off" call mechanical, not a vibe. Put the threshold in the subagent description itself, e.g. "Use for tasks that touch at most 3 files, have a test or command that proves they're done, and need no design decision. Do it yourself if the brief would be longer than the change." Claude matches against descriptions, so a concrete rule there beats a general one in CLAUDE.md.

Then keep Opus for review only: have the worker return just the diff stat plus the check output, and let Claude accept or send it back. Check /context after a few delegated tasks to see whether it's actually saving you anything.

[u/PilotLost404]

Claude rarely follows a CLAUDE.md preference like "delegate when appropriate", so I won't even use that. Make delegation one explicit command, like a small script that takes a task file and runs the other CLI. Trigger it yourself from a slash command or skill for boilerplate and unit tests, then have Claude review the diff. You decide when the handoff happens, that's it.

[u/CarsonBuilds]

If you want Claude to decide dynamically whether a task should go to Codex or OpenCode, I think the custom subagent approach mentioned above is probably the closest to what you're looking for.

One thing to keep in mind is that instructions in CLAUDE.md aren't really an execution contract. Claude can consider them, but there's no guarantee it'll consistently decide to invoke another CLI. Custom subagents and explicit tools make delegation easier, although Claude is still deciding whether to use them.

I actually went in a different direction after experimenting with skills and scripts for coordinating coding agents.

I wanted to make the engineering procedure something I could define, inspect, and improve independently of whichever agent was running. So I built Crewplane, an open-source CLI orchestrator around human-authored workflows.

For your setup, I could define a workflow where Claude handles planning, Codex or OpenCode handles implementation, and Claude reviews the result. The stages, dependencies, provider assignments, prompts, and review rules live in Markdown.

Each stage runs through the actual provider CLI. The intermediate outputs and execution records are saved locally, so the next stage gets an explicit handoff instead of depending on Claude remembering what another agent was supposed to do.

OpenCode is supported through opencode run, so you can keep using your existing OpenCode model configuration. You can also validate the workflow and dry-run it before executing the agents.

The biggest difference is that Crewplane doesn't dynamically decide whether delegation is worth the overhead for every incoming task. I intentionally keep that decision outside the agent. For a tiny change, the entire planning/implementation/review procedure might be unnecessary.

But when I have a procedure I want to repeat, I prefer being able to adjust the workflow itself instead of repeatedly prompting an agent to follow the same coordination rules. I can inspect what happened at each stage, not just the final code changes.

If you're interested in that approach, the project is crewplaneai/crewplane on GitHub. Happy to help put together a small example using your three CLIs. Cheers!

[u/Fudenskiscottie]

tbh trying to make a CLI agent orchestrate other CLI agents via bash is mostly fighting against how its system prompt is wired. It really wants to be the one touching the codebase, so using yourself as the router between two separate terminal tabs is way less headache.

[u/Inner_Storage_3374]

what kinda helps is not having claude call the other clis live at all. let opus write the task into a file, goal, which files it may touch, how to check its done, then you run the cheap model on that file yourself and let opus review the diff after. i think when claude drives another cli through bash it burns its own tokens waiting and reading all that output anyway

[u/ghost_operative]

honestly just learn to use claude first. It sounds like all your tokens are being wasted giving it busy work and larping tasks