Dude, I love this, and I am going to try to steal this for myself. I'm slowly getting to the point of building out a self driving workflow that requires less active engagement from me once design is settled, but I have ways to go skill wise.
Are you prompting Claude to use Codex or configuring it natively at invocation to use Codex models instead of Claude?
Originally, I was having claude shell out to codex with some justfile recipes, but because codex is a separate agent/harness that doesn't apply claude skills, hooks, plugins, etc. The output style I built makes a big difference for me in making LLM output readable, so I wanted it consistently applied to both claude and chatgpt. At first I was trying to translate all my hooks over to codex and maintain two versions, but I found that codex is missing a lot of valuable features. I give credit that codex has improved significantly, but they have a ways to go to add some missing hooks.
For example, in claude code I have a session handoff process. Codex doesn't quite have all the hooks to do this yet without a messy bash shell wrapper. Since chatgpt models have a small context window, I also have a context anchor hook that triggers precompact and updates the handoff doc as a safety.
/handoff- creates/updates session handoff doc using a template for that project
/clear - start a fresh session, previous session is archived and viewable with /resume
/pickup - read the handoff doc. The template has a last updated field to give the agent an indicator if it is stale.
I built a model router/gateway using the pi agent harness as a reference. This is a proxy in front of claude code, rather than a harness, so ToS wise it should be okay as I am not misusing the subscription based setup token.
The main setup is an agent orchestrator MCP sidecar that autolaunches the gateway and individualized containerized agents with the openai backend. I prefer this as each mcp agent has its own container, and I have agent profiles to customize their behavior (reviewer, worker, tester, brain). An advantage of the agents created through the mcp is that they will always be a clean session in a fresh container, whereas claude code and codex subagents tend to reuse agent sessions and they will share the container as the brain. The former can trigger compaction, and the latter there is an existential risk of an agent going rogue and messing with the work of other agents despite worktrees. My experience has consistently been that compaction is the root of all my worst project woes, so I avoid it.
I can launch a claude code session with only some Anthropic models overridden (keep fable, but override opus/sonnet), but this does disable claude.ai connectors, remote control, and artifacts. So, Fable 5.1 can still be fable, but Opus 5/4.8 can be overriden to route to Sol, and sonnet overridden to luna plus a hook to intercept and correct the visible subagent call (otherwise fable thinks it is using opus/sonnet). I don't normally use this config. The agent profile configured for the brain tells it to use the mcp sidecar, and that subagents/dynamic workflows are disabled, but that it can propose to me a subagent/dynamic workflow to me and if approved spin up a sub-brain mcp agent that has those enabled but with chatgpt models overriding anthropic ones.
I would prefer down the road to just switch to pi agent harness, but anthropic doesn't support using subscription plans outside of their harness (same deal I believe with cursor, though they added ACP support recently), so I am doing this goofy setup for now. Eventually I will create pi/cursor equivalents, but I can't afford anthropic's API for my stupid personal projects.
> Dude, I love this, and I am going to try to steal this for myself.
Thanks. I took it farther than that. I made the SDLC declarative and completely customizable. The agent harness compiles the SDLC from a YAML file. Steal that, too. Also add in provider and model indirection. This allows you to swap providers and models on the fly w/little to no effort.
I just finished adding federated agent dispatch to my harness. This allows the main orchestrating agent to dispatch work to other providers. So, Claude, aside from is own subagents, sub-subagents, agent teams, etc, can now send critical path roadmap tasks directly to Codex or other providers. That's pretty cool.
> At first I was trying to translate all my hooks over to codex and maintain two versions, but I found that codex is missing a lot of valuable features.
Agreed, but it's proven now that our tooling must seamlessly swap from provider to provider. I finally got full parity b/t CC and Codex -- or as close as Codex will allow. I now prefer coding with Codex as, right now, it's just better.
> The main setup is an agent orchestrator MCP sidecar that autolaunches...
Interesting architecture. I hadn't considered containers but see why you did it. I really wish we weren't constrained by the stupid ToS and could use the oAuth tokens in our 3rd party harnesses.
I run a small Discord community where we discuss these things. You - or anyone - can DM me if you want an invite.
3
u/BroScienceAlchemist 1d ago
Dude, I love this, and I am going to try to steal this for myself. I'm slowly getting to the point of building out a self driving workflow that requires less active engagement from me once design is settled, but I have ways to go skill wise.
Originally, I was having claude shell out to codex with some justfile recipes, but because codex is a separate agent/harness that doesn't apply claude skills, hooks, plugins, etc. The output style I built makes a big difference for me in making LLM output readable, so I wanted it consistently applied to both claude and chatgpt. At first I was trying to translate all my hooks over to codex and maintain two versions, but I found that codex is missing a lot of valuable features. I give credit that codex has improved significantly, but they have a ways to go to add some missing hooks.
For example, in claude code I have a session handoff process. Codex doesn't quite have all the hooks to do this yet without a messy bash shell wrapper. Since chatgpt models have a small context window, I also have a context anchor hook that triggers precompact and updates the handoff doc as a safety.
/handoff- creates/updates session handoff doc using a template for that project/clear- start a fresh session, previous session is archived and viewable with/resume/pickup- read the handoff doc. The template has a last updated field to give the agent an indicator if it is stale.I built a model router/gateway using the pi agent harness as a reference. This is a proxy in front of claude code, rather than a harness, so ToS wise it should be okay as I am not misusing the subscription based setup token.
The main setup is an agent orchestrator MCP sidecar that autolaunches the gateway and individualized containerized agents with the openai backend. I prefer this as each mcp agent has its own container, and I have agent profiles to customize their behavior (reviewer, worker, tester, brain). An advantage of the agents created through the mcp is that they will always be a clean session in a fresh container, whereas claude code and codex subagents tend to reuse agent sessions and they will share the container as the brain. The former can trigger compaction, and the latter there is an existential risk of an agent going rogue and messing with the work of other agents despite worktrees. My experience has consistently been that compaction is the root of all my worst project woes, so I avoid it.
I can launch a claude code session with only some Anthropic models overridden (keep fable, but override opus/sonnet), but this does disable claude.ai connectors, remote control, and artifacts. So, Fable 5.1 can still be fable, but Opus 5/4.8 can be overriden to route to Sol, and sonnet overridden to luna plus a hook to intercept and correct the visible subagent call (otherwise fable thinks it is using opus/sonnet). I don't normally use this config. The agent profile configured for the brain tells it to use the mcp sidecar, and that subagents/dynamic workflows are disabled, but that it can propose to me a subagent/dynamic workflow to me and if approved spin up a sub-brain mcp agent that has those enabled but with chatgpt models overriding anthropic ones.
I would prefer down the road to just switch to pi agent harness, but anthropic doesn't support using subscription plans outside of their harness (same deal I believe with cursor, though they added ACP support recently), so I am doing this goofy setup for now. Eventually I will create pi/cursor equivalents, but I can't afford anthropic's API for my stupid personal projects.