The Phenomenon

In my two years in the AI field, I’ve witnessed many tool switches. Recently, at least seven or eight friends have switched from Claude Code to Codex over the past three months. One person switched, then another posted on social media saying, “I switched too,” leading to a chain reaction.

When I asked them why they switched, the answers varied: “Codex is cheaper,” “the limits are frustrating,” and “I don’t have to babysit my code anymore.” However, digging deeper, none of these reasons fully explained the switch.

A Reddit post about “Claude Code usage limits” received 388 upvotes. In a blind poll of over 500 comments, 65% said they used Codex daily, yet 67% admitted that Claude Code produced higher quality code. The better quality option was abandoned.

Looking solely at model benchmarks, the reasons for this shift are not immediately clear.

The Real Reasons Behind the Switch

There are generally three reasons cited for the switch:

1. Cost: For the same Express.js refactor, Codex costs $15 while Claude Code costs $155. That’s a tenfold difference. For a one-person company, every dollar counts.

2. Model Performance: On SWE-bench Verified, Claude Opus 4.7 ranks first at 87.6%. However, on Terminal-Bench 2.0, GPT-5.3-Codex scores 77.3%, while Claude Code only scores 65.4%. In practical use, Codex is indeed faster.

3. Usage Limits: Claude Pro has a 5-hour window where complex prompts can consume up to 50% of the limit. Codex, at $20, has a Reddit post with 232 upvotes stating, “You can use it all day without hitting limits.”

These points seem valid but do not penetrate the core issue. If it were just about cost, model performance, or usage limits, long-time users wouldn’t switch. I personally run 54 skills on Claude Code, and the migration cost of these established skills is not trivial.

People do not abandon months of investment for minor savings or speed improvements. Therefore, the decision to switch must involve something deeper than just saving money or gaining a few seconds.

Tool Selection: A Shift in Mentality

After pondering this for a week, I realized the issue isn’t that Codex has suddenly become superior. It’s that the paradigm of Claude Code has made users feel like they are working in reverse.

Claude Code offers a “commander mentality.” It provides 26 lifecycle hooks, cascading CLAUDE.md, a skill library, permission levels, sub-agents, and plan modes. Each feature embodies an engineer’s romance, giving the sense of complete control over the agent.

However, the trade-off is that the time spent coding decreases while the time spent configuring the agent increases. A user quoted by SemiAnalysis stated, “Most of my engineering time is not spent writing code.” Instead, it’s spent configuring hooks, adjusting CLAUDE.md, writing skills, and managing permissions.

I’ve experienced this myself. One Friday evening, I intended to write a feature but ended up spending three hours adjusting the order of hooks. The next day, I checked my commit log and found zero lines of business code and 14 configuration files. At that moment, I realized I was not using the tool; the tool was using me.

Codex represents a different mentality. It places you in the role of a project manager. You input a requirement, and it writes the code in its sandbox. Once completed, it returns to report. You review the pull request, merge it, or send it back.

There are no hooks, no CLAUDE.md (though there is a lighter AGENTS.md), and no 26 layers of lifecycle events to manage. A commander must be present at all times, while a project manager can step away for coffee.

This isn’t a problem with the tools; it’s a shift in expectations of the tools.

It may not be as intelligent. In the blind test of over 500 developers, 67% said Claude Code produced better results. Codex has a crucial advantage: it doesn’t interrupt you. When Claude Code hits its limit, it stops immediately, even if it’s halfway through modifying your code. Codex, on the other hand, completes the current task before stopping when it detects limits are approaching.

This difference lies in the product philosophy, not in technical parameters. One tool as a commander requires your constant presence; the other as an employee allows you to step away.

The Departure from Claude Code

Recently, Anthropic added a moving UI element to Claude Code, which some users criticized as unnecessary. It seems that while tools become more endearing, users feel increasingly exhausted.

This reflects the feeling of reverse labor. It’s not that Codex is stealing users from Claude Code; it’s that the philosophy of Claude Code, which equates configuration with power, has reached a critical point. Deep controllability has turned into deep concern, and accumulated knowledge has become a burden. Once the iteration speed of the tool surpasses your accumulation speed, your skill library becomes a museum collection.

You glance at your 30 skills and feel proud for a moment, then wonder when you last opened the 17th one. However, this isn’t entirely accurate. Users like Boris Cherny from Anthropic and Calvin French-Owen from OpenAI, who are heavy users, haven’t switched. This indicates that for some, managing 26 hooks is enjoyable. Not everyone is leaving, and that’s important to acknowledge.

Is Switching the End? The Truth is Dual Usage

I also need to temper my own expectations. Codex is not without issues. Developers have complained on Hacker News that Codex can fabricate plausible but non-existent problems during code reviews, making it easy to be misled during your review.

Its cloud mode is highly automated; after running for several minutes, you may lose control over the process. More critically, Codex currently does not support MCP. Any MCP servers connected on Claude Code cannot be used.

Thus, the truth is not about “abandoning” one for the other. The truth is about dual usage in different scenarios. The most upvoted solution on Reddit suggests using “Codex for keystrokes, Claude Code for commits”—using Codex for daily coding and reviewing critical commits with Claude Code. Others suggest the reverse: “Use Claude Code for clarity, Codex for execution.”

My own approach is to use Claude Code for exploratory, architectural, and uncertain tasks, while using Codex for well-defined requirements that need quick execution. For a 1000-line prompt skill refactor, I first hand it to Codex to generate the skeleton, then use Claude Code to handle the more complex parts requiring iterative reasoning. One tool is responsible for “doing,” while the other is responsible for “thinking.”

Switching to Codex means demoting Claude Code from a “full-command commander” to a “consulting doctor for critical tasks.”

Considerations Before Switching

Returning to the initial question—should you switch? Before making a decision, consider three things:

1. Inventory of Skills: Are your skills/CLAUDE.md/hooks genuinely being used? Or have they been left untouched after configuration? Personally, out of my 54 skills, I frequently use less than 15. The other 39 sit idle, much like a heavy book on my shelf—interesting but unread.

2. Task Profile: What have you been working on most in the last three months? If you’re dealing with exploratory tasks (not sure how to proceed, needing trial and error), don’t switch from Claude Code. If you’re executing tasks (knowing how to do it, needing quick completion), Codex’s lightweight nature is worth trying.

3. Reflective Questioning: When you say you’re tired—are the tools to blame, or is there an issue with the tasks themselves?

Tools can be swapped out, but the tasks cannot. If you find that after configuring 54 skills, you’re not actually working on products but just configuring tools, that’s not Claude Code’s fault. Nor is it something Codex can solve.

Tools are merely mirrors, reflecting where you’ve been spending your time.