[extr]

Notice how pricing is the top discussion theme. People love free shit and it's hard to deny codex usage limits are more generous. My 2c for someone who uses both tools pretty consistently in an enterprise context:

- Codex-medium is better if you have a well articulated plan you "merely" need to execute on, need help finding a bug, have some specific complex piece of logic you need to tweak, truly need a ton of long range context to reason about an issue. It's great and usage limits are very generous!

- Sonnet 4.5 is better for everything else. That means for me: non-coding CLI ops, git ops, writing code with it as a pair programmer, OOD tasks, big new chunks of functionality that are highly conceptual, architectural discussion, etc. I generally approve every edit and often interrupt it. The fast iteration and feedback is key.

I probably use CC 80% of the time with Codex the other 20%. My company pays for CC and I don't even look at the cost. Most of my coworkers use CC over Codex. We do find the Codex PR reviewer to be the best of any tool out there.

Codex gets a lot of play on twitter also because a lot of the most prolific voices there are solo devs who are "building in public". A greenfield, solo project is the ideal (only?) use case for running 5 agents in parallel or whatever. Codex is probably amazing at that. But it's not practical for building in enterprise contexts IMO.

[loveparade]

Interesting, my experience has been the opposite. I've been running Codex and Sonnet 4.5 side by side the past few weeks, and Codex gives me better results 90% of the time, pretty much across all tasks. Where Claude really shines is that it's much faster than codex. So if I know exactly what I want or if it's a simpler task I feel comfortable giving it to Claude because I don't want to wait for Codex to work through it. Claude cli is also a much better user experience than codex cli. But Codex gets complex things right more consistently.

[distances]

My experience is similar. So most of the work I do with Claude as I like the small tasks / fast iteration pair coding experience. When I need to investigate some issues I let Codex handle it, and check back in 10 minutes when it's ready. But Codex is way too slow for the pair programming style of work.

Also, most of the time Codex opts to use Python to edit files. Those edits are unreviewable so it's even less interactive, you just have to let it finish and check the outcome.

[qsort]

They are similar enough that using one over the other is at most a small mistake. I prefer Claude models (perhaps I'm more used to them?) but Codex is also very good.

[extr]

Totally agree. A lot of it is simply personal preference at this point.

[quintu5]

For larger tasks that I know are parallelizable, I just tell Claude to figure out which steps can be parallelized and then have it go nuts with sub-agents. I’ve had pretty good success with that.

[DanielAtDev]

I need to try this because I've never deliberately told it to, but I've had it do it on it's own before. Now I'm wondering if that project had instructions somewhere about that, which could it explain why it happened.

[quintu5]

It sometimes does it on its own, but to get it to do so consistently, it needs to be told. Doubly so if you want it to split off more than one sub-agent.

This works great for refactors that touch a large number of files. You can knock out a refactor that might take 30 minutes, a persistent checklist, and possibly multiple conversations, and one-shot it in two minutes and a single prompt.

[another_twist]

> better for everything else. That means for me: non-coding CLI ops, git ops, writing code with it as a pair programmer, OOD tasks, big new chunks of functionality that are highly conceptual, architectural discussion..

I would argue this is the wrong way of using these tools. Writing out a defined plan in plain english and then have codex / claude write it out is better since that way we understand the intention. You can always have codex come up with an abstract plan first, iterate on it and then implement. Kind of like how we would implement software in real life.