Why I Switched from Claude Code to Codex

I have been using Claude Code for real work. Not casually. Real repos, real context, real constraints, real output.

It helped me rebuild my resume, LinkedIn, website, and blog. It helped me get a lot of momentum back on projects I had been avoiding. So this is not a “Claude is bad” post. Claude worked well for me.

I switched anyway.

Right now, Codex is working better for how I build, write, and manage projects. That opinion could change quickly. This space moves too fast for anyone to act like a tool choice is a permanent identity. I might try Claude again next week if the balance changes.

But as of now, I am getting better results from Codex.

The obvious reason is 5.5

The headline reason is simple: 5.5 is strong.

The best analogy I have is cars. For my workflow, the jump from 3.x to 4.x felt like going from a Toyota Corolla to a Mustang. The jump from 4.x to 5.x feels like going from a Mustang to a Ferrari. It is not just faster. It changes what kind of work feels practical.

For my workflow, it is the biggest practical difference. I am seeing better behavior on the things I care about most: reading the repo before acting, following project instructions, making scoped changes, handling messy context, and carrying work through to verification.

That last part matters. I do not want an agent that gives me a beautiful explanation of what should happen. I want an agent that understands the work, does the work, checks the work, and tells me what changed.

Codex has been better at that for me.

This is not a benchmark claim. It is not a universal ranking. It is the outcome of using both tools actively and noticing which one is saving me more time.

Verbose planning started getting in the way

The less obvious reason is how Claude handles Plan mode.

I use Plan mode constantly. It might be the most useful feature in this whole category.

For serious work, the first plan should be detailed. I want the agent to spend real time and tokens reading the repo, checking assumptions, naming risks, and thinking through the path before it edits files. That is the point. Slowing down before changing files is a good instinct, especially in a repo with real risk.

My normal pattern is to spend three to five follow-up prompts tightening the plan if something does not look right. If I need more than that, I probably did not plan the work correctly.

The problem is not planning. The problem is planning output that becomes too bulky to use.

Claude often gave me way too much planning surface area: restating the task, listing broad phases, hedging around obvious constraints, and expanding every step until the actual decision was harder to see.

Codex has been more concrete and concise. Read the relevant files. Tell me the decision. Name the risk. Make the smallest useful change. Verify it. Keep moving.

That is the balance I want. Plan hard, then execute cleanly.

The friend who kept pushing Codex

A friend had been trying to get me to spend more time with Codex.

I was not against it. I just had switching friction.

By that point, Claude was not just a model I opened in a terminal. It was part of my workflow. I had project instructions, durable memories, repo conventions, tone preferences, and little pieces of operating context built up around it. That context is not glamorous, but it is valuable. It is the difference between a cold agent and an agent that knows how you actually work.

So the real question was not, “Can I install Codex?”

Of course I could install Codex.

The real question was, “How much work is it going to take to make Codex useful on day one?”

That was the barrier.

The hard part was memory migration

The biggest switching cost was migrating memory and context.

These tools get better when they know your preferences. They get better when they know your repo workflow. They get better when they know what not to do. They get better when they understand which instructions are global, which are project-specific, and which are stale.

Losing that context makes the new tool feel worse than it really is.

So I took the obvious lazy route: I asked Codex to migrate it for me.

I had Codex read the existing Claude-oriented context, separate durable preferences from noise, convert the useful pieces into Codex instructions, and preserve the repo-specific rules that actually matter. It handled the migration better than I expected.

That is probably an open source idea by itself.

Call it memport or something like that: a tool for moving agent context between Claude, Codex, Cursor, local Markdown files, and whatever comes next. It would need to be careful. Agent memory can contain sensitive details, stale assumptions, and project-specific rules that should not leak into global instructions. A serious version would need dry runs, diffs, redaction, snapshots, and rollback.

There are already useful open source CLI tools around this general space: Aider, OpenCode, Gemini CLI, Codex CLI itself, and the growing AGENTS.md ecosystem. But the harder problem is not proving that a CLI can move text from one place to another.

The harder problem is maintenance.

Claude and Codex are changing so quickly that an open source migration tool can become stale almost immediately. Someone can launch a useful helper on Monday, and by the next week one of the underlying tools has changed its config shape, memory behavior, hooks, permissions model, skill format, or default assumptions. Then the maintainer moves on, the README drifts out of date, and the tool quietly becomes a trap.

That is the part a serious memport would have to solve. It could not just be a one-time converter. It would need active maintenance, version detection, test fixtures against real tool versions, and conservative dry-run behavior by default.

But the core idea is useful: your agent context should be portable. If the best model changes, your workflow should not be trapped in last month’s tool.

Codex is working better for me

Once the context moved over, the difference became much clearer.

Codex is getting me closer to what I am actually asking for. It feels less like I am steering around the assistant and more like I am collaborating with something that understands the target.

That does not mean it is perfect.

I still think Codex has work to do in the frontend space. I am guessing the team knows that. Frontend agents need more than code correctness. They need design judgment, responsive QA, visual taste, and a good instinct for when something technically works but still looks off. That is a harder bar than passing a build.

Even with that caveat, Codex is the better fit for me right now.

For writing, repo work, workflow automation, local tooling, and project cleanup, I am getting stronger output and spending less time correcting course. That is the practical test.

This is not a loyalty program

I do not want fewer strong tools in this space. I want more of them.

Claude being good is good for Codex. Codex being good is good for Claude. Competition is the reason these systems are improving so quickly. Nobody benefits if one vendor runs away with the category and everyone else gives up.

So I am not interested in turning this into a team sport.

Claude worked for me. Codex is working better for me. That is the whole point.

The smart move is to keep evaluating the tools against real work. Not vibes. Not leaderboard screenshots. Not whatever people are yelling about this week. Real tasks, in real repos, with your actual constraints.

My current rule

If you are happy with Claude, I would not switch just because someone online said Codex is better.

Run the same kind of work through both. Give both tools the same repo context. Ask both to do something concrete. Then look at the result:

• Which one understood the task faster?
• Which one respected your instructions?
• Which one made the smallest useful change?
• Which one verified the work?
• Which one required less steering?

For me, the answer has been Codex.

The model quality is the obvious reason. The lower friction is the reason I stayed. The memory migration was the only thing that made me hesitate, and I solved that by making Codex do the migration.

That feels like the right lesson.

The agent should not just write code. It should help you move your workflow forward.