Claude orchestrating Codex agents is the workflow I didn't know I needed for coding

Published Jul 29, 2026, 7:30 AM EDT Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He's covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he's also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023. He was the kid who took apart every toy to see how it worked, even if it didn't exactly go back together afterward. That's given him a solid background for explaining how complex systems work together, and he promises he's gotten better at the putting things back together stage since then. I’ve been testing agentic coding workflows by swapping between Claude Code, Codex, and local LLMs via Crush, but no matter how adjusted to the process I get, none of them return perfect results. The harness around each model works differently, but maybe by using the two together we could get better results. I came across a plugin the other day that would allow me to use Claude as an orchestrator for Codex agents, and started looking for a project to run with it. The obvious answer was the harness Claude used to overclock my PC via KVM, which worked well, but I wanted a dry-run safety mode for testing. Not only did the plugin work, but it also found problems I didn’t know I had. And along the way, it saved the entire project from the biggest agent of chaos inside my home lab. Me. How I put Claude in charge of OpenAI's Codex Handoffs are claims, not evidence I’ve noticed throughout my usage that Claude Code is better at planning, while Codex likes to get stuck into the code. That’s how the orchestrator plugin divides labor: Claude does planning, verification, journaling, and the final commit. Codex implements via codex exec. When Claude built the overclocking harness with me, it included multiple runtime arguments but no way to verify them without doing a full run. That could derail an overclocking session, so the idea was to add a —dry-run argument so that I could use arguments like boot-to-bios --key Delete --seconds 50 without touching the hardware. It also had to work without touching the network, because the harness design was to control a PC via KVM-over-IP remotely. The orchestrator pair had to capture the current behavior into fixtures and commit them before any refactor happened; otherwise they may rewrite the whole thing as they wanted, and I’d be none the wiser. And there was one more trap. A Codex agent reporting “tests pass” wasn’t proof of anything until Claude ran the same checks and observed the same results. That’s maybe the most important part of how the plugin is structured. Codex Orchestrator Claude is best at planning; Codex is token-efficient for making code. This tool uses the best of both to make an agentic coding pipeline that works. The review caught three problems I missed I would have been yanking my hair out for days The system found things I had failed to notice. A dependency error: the venv had pytest, but it needed requests and websocket-client for the harness to work. An issue with the 50-second button-mashing plan, where it shouldn’t take 50 seconds to run a dry-run. And that my request for “byte-identical HID reports” was missing a definition for byte-identity. All logged with suggested fixes in the first decision document. When it was time for Claude to read the decision doc, it didn’t take it at face value. It ran the imports and recorded the observation to confirm that the Codex decisions had merit. The journal recorded both the reviewer's claims and the orchestrator's verification. The fix was better engineering than I did on my own Due to the missing dependencies, any import of the harness would fail. Instead of installing them, the orchestrator added fake modules that satisfy the import but fail loudly if anything tries to use them. My dry-run prompt said to prove no network traffic, and with the stubs in place, if the dry-run tries to use the network, the stub raises an error and the test fails. The refactor also splits the send path into an interface with two implementations: MockTransport (records what would be sent), and the real transport via WebSocket. My test design didn’t account for two paths, and the fake path via MockTransport would have passed even though the harness would have been broken. The orchestrator decided to run the equality tests against both paths, with a recording WebSocket stub underneath. I can’t say I would have found these issues. My starting prompt created them, and the agentic layer fixed them for me. I killed the run by accident, and it didn't care The journal turned out to be the product, not the codebase I said I’m the chaos agent in my home lab and I own every letter. For the first run of the orchestrated layer, I was too excited to see what would happen, and pasted in the prompt without filling in the placeholder. I thought the error might have cost the run, or at least more tokens than I expected, but it ended up testing the orchestration layer's architecture. The restarted session read journal.json1 as designed, and carried on the same run ID rather than restarting. I compared the agent’s self-summary against the raw journal paste, and they matched, so it recovered from the record and not from the existing chat snippets. Adding the corrected arguments and two fixture sequences turned into a recorded decision by the orchestrator, and it continued working. The dry-run output passed, using 179 taps/358 HID events to create the 50-second window it was supposed to button-mash Del to get into BIOS after a reboot. Then pytest ran eight tests that all passed, and the commit chain was the final proof of the updated codebase with the new feature. None of that would have been recoverable without the journal. Prompts, decisions, and events were all recorded to disk before any code changed. Good design wins every time. This won't be something I reach for every time It costs you in other ways Okay, the first thing I have to explain comes from the project’s README. The author ran both the orchestrated setup (the 0.4.1 release) and the solo agents on the same bug-fixing set. The orchestrated setup got 9 out of 10, while the solo agents each got 8 out of 10. Seems like a clear win, but for one thing: the orchestration setup had no time constraints, while the solo agents were time-boxed. That added time is what the orchestration costs you. The process of planning, reviewing, implementing, then verifying takes longer than a single agent would. It’s arguably a better output, but time (and tokens) aren’t free. I’m not sure how many tokens my Claude and Codex subscriptions give me per week. I can tell you how many tokens each used in the orchestrated setup, and it surprised me. Claude used almost 520K tokens on the run I had to stop before even doing anything. In total, it used over 9 million tokens, while Codex used about 1.2 million. That’s roughly 8x the usage for the orchestrator, and it wrote 3.5x as much. And there’s one other cost. Without adding commands that can check the agent’s claims, the whole loop might as well not exist. My testing run used py_compile, pytest, a timed dry-run, and diff inspection, and that’s the only reason it worked. The orchestration layer did catch things that solo tooling probably wouldn’t have, because it didn’t catch it when I built the harness we were upgrading. That’s an auspicious start after one real-world test, and I’ll be keeping an eye on it while I build other features. The value here isn't two models agreeing The orchestration layer here wasn't to get Claude Code and Codex to agree, but rather to disagree constructively. And it did just that, giving me a better codebase as a result. Just at an increased token count, which is why I won’t be using it all the time.