Which is better: Claude Code or Codex?

During my parental leave, I have not had as much time to work with Claude Code as I did before, so I naturally reduced my budget for it. This meant that during busy periods, I frequently switched between Claude and Codex to finish projects, features, and commits.

That has given me a good basis for comparing Claude Code with Fable, Opus, and Sonnet against Codex with GPT-5.5.

It is also worth mentioning that I have mostly stopped using the terminal. Claude Code Desktop and Codex Desktop provide the same basic capabilities, but add a well-designed UI and UX layer that the terminal is far behind on.

This includes:

– An overview of multiple running projects
– Parallel plans and tasks
– Code files and changes
– Frontend previews
– History and context across chats

Claude Code

Claude generally seems more thorough in its approach to code.

Part of that impression probably comes from the amount of effort Claude puts into explaining problems, options, and technical considerations in a very developer-oriented way. It describes the issues it encounters, weighs different solutions, and often asks clarifying questions.

This creates a strong impression of thoroughness.

For example, when I ask Fable 5, Claude’s newest model, to review large older projects where Opus was responsible for the architecture, it often finds a wide range of relevant improvements.

These do not appear to be superficial suggestions generated simply to make the analysis sound impressive. There is often real substance behind them.

I programmed object-oriented frontends for around seven years. It was not in React, Python, or Vite, which are common in much of the work we do today, but it has given me a reasonable understanding of the difference between superficial observations and genuinely detailed code work.

Claude Code also has a more mature harness setup.

Its ecosystem of skills, agents, hooks, and plugins makes it easier to build and share structured workflows. Claude.md also makes it possible to define how Claude should work within a project and how things such as agent orchestration, documentation, and quality assurance should be handled.

The strengths of Claude Code

In my experience, Claude Code is strongest in:

– Thoroughness
– Transparency
– Harnesses and agent orchestration
– Community and professional relevance

It is also a platform and model ecosystem that many other professional users work with.

The weaknesses of Claude Code

Claude often overexplains, which makes it feel considerably slower from prompt to commit.

It spends many tokens on technical explanations that are not always necessary to move the work forward. When you reach your token or usage limit, it can also stop very suddenly in the middle of a task.

The desktop interface is functional, but still relatively basic and could be improved significantly.

Its tone is also not for everyone. It often communicates in a very technical way, and you feel that you should read a large part of the explanation to understand what happened.

Because there is so much text, it can sometimes create the impression that a lot of work has been done, even when that is not necessarily the case.

Its voice mode is also poor, both in the way it handles English and because it does not support Danish. It also includes every “uh” and hesitation in the transcription, which Codex does not.

Codex

Codex feels significantly faster.

It completes tasks quickly. Sometimes so quickly that, compared with Claude’s apparent thoroughness, you start to wonder:

Was that perhaps a little too fast?

In my experience, Codex has a better overall user experience.

This is not necessarily because the interface looks significantly different. The two desktop applications actually look surprisingly similar.

The difference is in the small, useful features.

These include:

– The way projects are grouped
– The overview of the entire conversation
– Encouraging you to start new chats instead of constantly clearing the same one
– The handling of parallel tasks
– The way technical workflows are collapsed

Codex can spend a long time thinking and explaining technical issues and considerations, but it does not ask questions about everything.

When it has finished thinking and begins carrying out the work, the reasoning is collapsed. When the implementation is complete, that section is also collapsed, leaving you with a short summary of what changed.

This works extremely well.

When I iterate on smaller frontend corrections, I can barely finish writing the next instruction before the previous change has been implemented.

This is particularly effective for UX and UI adjustments where you want to work quickly and iteratively.

However, it is not only fast at frontend work. It can often change the related backend logic just as effectively.

When I give Claude Code and Codex roughly the same task, Claude often produces more than twice as much text as I feel I need to read.

Codex is more likely to complete the work and provide a short summary.

That may also be part of the reason it feels faster.

When Codex reaches its usage limit, it also often attempts to finish the current task. In many cases, it manages to commit the changes before shutting down.

That is a good decision by OpenAI.

Codex does not have a direct equivalent to Claude.md. Instead, it uses an AGENTS.md file, which feels slightly different when you are coming from Claude’s harness approach.

Although I use Wispr Flow in both applications, I know that Codex’s built-in voice mode is much better than Claude’s and also works in Danish.

Which one wins on design?

Both Claude Code and Codex are very loyal to the direction you give them. This means that the quality of the design depends heavily on your own instructions, taste, and ability to guide the iterations.

My current conclusion

Claude Code feels like the better tool when I need thoroughness, technical transparency, architectural analysis, and a strong agent and harness ecosystem.

Codex feels like the better tool when I need speed, flow, short feedback loops, and a more efficient everyday user experience.

Very broadly speaking, it feels as though OpenAI has the stronger UX people, while Anthropic has hired some of the stronger engineers.

You can feel this both in the way the products are designed and in the way the models work and communicate.

So which one is better?

For me, the answer for now is:

I am currently testing PI + a open weights coding model from Mistral,
PI is a CLI that works with both models together and can bring in additional models when needed. I am looking forward to sharing my thoughts on that.