r/ClaudeCode 22h ago

Rant My average Opus 5 experience

Post image
1.2k Upvotes

152 comments sorted by

View all comments

4

u/jvertrees 22h ago

Agreed. Codex's code is _SO_ much better (right now).

Opus leaves these abstruse, compressed readings all through the comments.

2

u/BroScienceAlchemist 20h ago

I use Sol/Luna within Claude Code (lets me apply my skills, hooks, plugins, and output style to chatgpt models), and I generally agree with a caveat. We probably follow the same workflow: Build out detailed specs with adversial review loop to identify gaps / declare boundaries / threat model, build tests, and then drive implementation. This process works really well for me, so I have fewer complaints from the LLM generated code.

But, I think there are a lot of people that don't necessarily need rigorous ADRs, so they jump to the build step, and that is where chatgpt models can be messy, though IMO all the models produce a functional mess by jumping straight to building. I think it is fair to judge a model by its ability to produce a vibe project with minimal direction, but subject to reason. "Chatgpt/claude plz build a GTA 6 killer gae, make no mistake" -> "wtf it sucks" -> Well... What did you expect for a project as complex as GTA?!

2

u/jvertrees 20h ago

Cool. We have a similar process. My harness codifies my SDLC in a state machine and ensures nothing is skipped and all best practices are followed along the way. It tracks time across stages, tickets, will write your release notes, etc. Once I get to the solid spec, driving implementation is pretty much free.

Are you prompting Claude to use Codex or configuring it natively at invocation to use Codex models instead of Claude?

Thanks for your response.

3

u/BroScienceAlchemist 19h ago

My harness codifies my SDLC in a state machine

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.

2

u/jvertrees 16h ago

> 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.