The honest answer to "Claude or Codex?" is: it depends on the shape of the job in front of you, not on which one you happen to like. Most people pick a favourite and use it for everything. That's a waste. The two assistants have different tempers, and once you notice that, you stop defaulting and start choosing.
I want to be careful here. I'm not going to quote benchmarks or claim one is objectively better at some category of task. That changes, and it depends on far too much to be a useful rule. What I can offer is how I actually decide in the moment, from having shipped real work with both.
Fuzzy problems versus defined ones
The single most useful distinction I use is how well-defined the problem is when I start.
When the problem is fuzzy, when I'm still working out what I even want, I reach for the assistant I find better at thinking out loud with me. I'll describe the mess, float a couple of half-formed options, and let it help me frame the thing. This is the conversational, "talk me through the trade-offs" mode. The output I want at that point is clarity, not code.
When the problem is already defined, when I know exactly what needs building and could almost write the ticket myself, I reach for the assistant that's happiest grinding through well-specified work. Here I don't want a conversation. I want the thing built, correctly, with the fiddly bits handled. Less chat, more output.
Which assistant plays which role for you is worth discovering by feel rather than taking my word for it. The point is the distinction, not the assignment. Ask yourself before you start: do I need help deciding what to do, or help doing a thing I've already decided?
The everyday tells
A few situations where I've learned which way I lean:
- Naming and structure: when I'm unsure how to organise something, I want the more discursive partner that will push back on my first idea.
- Mechanical, repetitive changes: when I need the same edit made carefully across many places, I want the assistant that just does it without narrating.
- Explaining unfamiliar code: for "what on earth is this doing," I want the one that's better at plain-English summaries.
- A clear feature with a clear spec: hand it over and let it run.
These are not laws, just the accumulated feel of doing the work, and yours may differ. But having any framework beats reaching for whatever tab was already open, which is what most of us actually do.
Switching mid-task is the normal case
Here's the thing nobody tells you: you'll often use both on the same task, and that's fine. A job starts fuzzy, so you frame it with one. It becomes defined, so you build it with the other. Then a weird bug appears and you're back to fuzzy, so you switch again.
People treat this switching as a sign they picked wrong at the start. It isn't. The task genuinely changed shape as you worked it, and the right assistant changed with it. When I was building htmlEdit, my visual editor for AI-generated HTML documents, I moved between the two more times than I could count, and each switch was a response to the work in front of me, not a failure of planning.
The only real cost of switching is re-establishing context, because the two don't share memory. That's a reason to keep your tasks well-defined and self-contained, which I've written about separately in dividing the work, not the context. If each piece stands alone, handing it to whichever assistant suits it is cheap.
Notice your own pattern
After a few weeks you'll have a pattern. You'll reach for one instinctively when you're stuck on the shape of a problem, and the other when you know exactly what you want and just need it done. Lean into that. The goal is to get the work done well, not to be even-handed.
The worst outcome is loyalty. If you've decided one assistant is "yours" and you use it for everything, you're leaving the easier half of your work harder than it needs to be. Match the tool to the job. The job will tell you which one it wants if you stop long enough to ask.