I showed my Codex setup on Threads. Many people asked how I did it, so here is the full guide.
I use Codex Router. Cursor CLI set it up for me. Yes, I asked one coding agent to build a team for another.
My Codex setup keeps Sol or Luna responsible for the main task and its final result. DeepSeek V4 Flash searches the repository and traces bugs. It also reads logs and collects evidence.
The problem I was trying to solve
A strong coding model can burn a large part of its context finding files and following imports. It also compares logs and locates the first failed test. The work is necessary, but its output is usually easy to check.
I still want the main model to understand the request and protect existing work. It must catch technically valid changes that make no product sense. Sol or Luna keeps that responsibility. DeepSeek handles the bounded repository work underneath it.
How the setup is wired
The setup has three layers:
Codex Desktop
|
| main task
v
OpenAI parent model
|
| delegates bounded work
v
Codex Router on the local machine
|
+--> OpenAI
+--> OpenRouter
+--> Official DeepSeek API
+--> other compatible providersCodex Router sits between the app and the model providers. It merges their model entries into the Codex catalog and sends each request to the correct backend. The task and its conversation stay with the parent model.
In my current setup, the parent is Sol or Luna through my ChatGPT account. The main cheap worker is DeepSeek V4 Flash through OpenRouter. I keep a separate Sol worker for public writing in my voice.
The exact models can change. The parent holds the context and reviews the result. Workers receive narrow assignments. The router connects them to their providers, while AGENTS.md tells the parent when to delegate. A long model picker without those rules is only a long model picker.
Why the router is necessary
Codex Desktop rejected my non-OpenAI worker slug while the session used a ChatGPT account. The router transport solved that part.
The next failure came from the agent catalog. My Sol and Luna parents use multi-agent v2. A DeepSeek entry left on v1 can appear in the model picker and still fail when Codex tries to spawn it.
The error is wonderfully vague: "agent type is currently not available."
Everything looked configured, but the child still used the wrong multi-agent version.
Codex Router handles both parts. It provides the local transport and promotes selected worker models to multi-agent v2 inside the merged catalog.
Setup with the guided installer
My original installation involved several manual steps and wrong turns. The public router now has a guided setup, so I would start there.
Codex Router is an independent community project. It is not an OpenAI product. Read its repository and decide whether you trust a local routing layer before giving it provider credentials.
The Homebrew route is:
brew tap duolahypercho/codex-router \
https://github.com/duolahypercho/codex-router
brew install codex-router
codex-router setup --guidedThe project also provides a guided installer for macOS and Linux. I prefer the Homebrew route because upgrades and removal remain explicit.
The setup chooses providers and stores credentials through a hidden local prompt. It also installs the background service. Then it connects the generated model catalog to Codex and checks the local layers. Keep provider keys out of AI chats and dotfiles.
My current definition is intentionally small:
name = "deepseek_worker"
model = "openrouter/deepseek/deepseek-v4-flash"
model_reasoning_effort = "low"The model slug depends on the provider. The official DeepSeek API also worked in my tests, but I currently use OpenRouter for this worker.
My curated model initially exposed only the high reasoning level. The worker requested low, so it failed until I added that effort to the catalog. The slug must match the worker definition. The multi-agent version and reasoning effort must match too.
Tell the manager when to delegate
The worker definition only makes the worker available. I keep the delegation rules in AGENTS.md:
Delegate bounded work when a specialized worker can handle it efficiently.
- Use deepseek_worker for repository investigation, diagnostics,
file search, log reading, and bounded implementation that is cheap to verify.
- Keep architecture decisions, ambiguous requirements, final synthesis,
and public voice with the parent or a specialized strong worker.The parent then runs this flow:
User asks for a bug fix
|
Parent defines the investigation
|
DeepSeek searches files, logs, and recent changes
|
Parent reviews the evidence and chooses the fix
|
A bounded worker implements it
|
Parent verifies the resultGood worker jobs end with evidence the parent can inspect. "Find where this value is created and return the relevant files" works well. Architecture decisions stay with the parent.
Verify the complete loop
A successful chat response proves very little. Codex also sends tool definitions and search options. Structured schemas are part of the request too. A provider can answer text and still fail on those requests.
After changing a worker or routing rule, I quit Codex and open a new task. Existing tasks may cache the old catalog.
Then I ask Sol or Luna to spawn deepseek_worker for a file search. DeepSeek must call the search tool and return file evidence. Control must then pass back to the parent.
The failures that wasted the most time
The error about an unsupported model meant that the ChatGPT session was missing the router transport. The vague "agent type is currently not available" error meant that the child was still on multi-agent v1.
If the model needs manual promotion, the advanced router controls look like this:
./bin/control subagents set \
openrouter/deepseek/deepseek-v4-flash on
./bin/control subagents verify \
openrouter/deepseek/deepseek-v4-flashAfter rebuilding the catalog, I check that the model is visible and marked multi_agent_version: v2.
Chat compatibility was another false positive. One proxy accepted ordinary prompts but rejected search options and parts of the tool schema. I moved the worker to OpenRouter. The official DeepSeek route also passed the complete agent flow.
One catalog operation removed the router transport and changed the parent model. Since then, I check both after every catalog change.
The local gateway can also take time to start. A broken watchdog treated a slow boot as a dead service and kept restarting it. The tool intended to prevent downtime created an endless restart loop.
Sometimes the correct debugging technique is to stop helping for a minute.
Why the economics make sense
I compared coding models by performance and approximate API cost per task. In my August 18 snapshot, DeepSeek V4 Flash scored 55 at $0.07 per task through its direct API. Sol Max scored 67 at $7.08.
The configurations differ by model and effort. They also use different harnesses. Treat this as a directional comparison. The live sortable table stays updated.
I use that cost gap for work whose output I can check. Repository search returns files and lines. Bug tracing returns logs and failing tests. DeepSeek collects the evidence. Sol or Luna decides what to do with it.
Architecture and product judgment are harder to verify. So is final communication. I keep the stronger model responsible for those decisions.
Delegation also has a cost. The parent has to explain the task. The worker has to return enough context. The parent has to review it.
For a tiny task, I solve it directly. For a large repository investigation, the handoff saves expensive context. Somebody still bills every token. The router moves file reads and search results to the cheaper worker. Failed paths go there too.
Source: Codex Router. The project is independent and is not affiliated with or endorsed by OpenAI or the model providers mentioned here.
Or you can skip this entire article. Paste it into your local coding agent and ask it to set everything up on your machine.
That is pretty much what I did.
Good luck :D