Sep 24, 2026

Codex Is Hard to Use Because I Can't Catch What It Hands Me

Ye Weirui

On September 21st my Claude Code quota reset. The first thing I typed was:

I've built a lot with Codex these past few days. Can you review it? I keep feeling it's a bit weaker than you.

I'd had that "keep feeling" for months. Codex was hard to use. I couldn't say exactly why. It just was.

This time I wanted a number instead of a feeling. Both tools keep full session logs on my machine, so I went through everything since June. I only counted what I typed myself in the terminal or desktop app. Scripted runs and subagents are excluded.

The result wasn't what I expected.

1. It's my backup, not my pick

First, how much I used each one:

	Codex sessions	Claude Code sessions
June	136	0
July	240	100
August	14	395
September (to the 24th)	151	486

Codex was my main tool in June and July, nearly stopped in August, then came back with 150-odd sessions in September.

Where those September sessions came from is obvious once you lay them out by day:

Date	Codex	Claude Code
Sep 12	15	7
Sep 13	36	4
Sep 14–18	5	121
Sep 19	31	3
Sep 20	38	1
Sep 21	8	36

The two lines interlock perfectly. When Claude drops to single digits, Codex takes over. When Claude's quota comes back, Codex steps aside and is at zero by the next day. In the first 24 days of September, there were 13 days I didn't open Codex once.

The logs say it plainly, too. On the 9th, my first message to Codex ended with: "Claude ran out of quota halfway through..."

So let me admit something up front: Codex isn't a tool I choose. It's what I fall back on when the quota runs out. Every time it comes in, it's picking up something someone else left half-done, or something I'm already a bit fed up with.

2. Turn by turn, they're nearly identical

I assumed "hard to use" would show up in the conversations: that I'd have to nudge it more, ask "why" more, interrupt it more.

Here's September:

September	Codex	Claude Code
Messages I sent	515	1950
Median message length (chars)	17	12
Pure nudges ("continue", "go", "ok")	11%	10%
Containing "why" / "how come it still"	7%	5%
Median time per turn	~3.3 min	~5.9 min

July, when I used both, was about the same: 12% vs 11% nudges, 6% vs 4% "why."

The gap is small enough to ignore. Two more points of "why" is a faint signal at most, nowhere near enough to explain "hard to use." And Codex's turns are actually shorter.

From the conversations alone, I couldn't tell which was which.

3. Every time it finished, I called Claude to check

This is where things are lopsided. I found four times when, after Codex finished a stretch of work, I opened Claude just to review it:

Late July: "please help me review what codex have done recently"
September 7th: "I've had Codex work on this project for 8 hours. Review what it did, I didn't really follow it"
September 19th: "review Codex's recent changes"
September 21st: the message at the top

I asked Codex to look over Claude's work only once.

That direction says something on its own: I couldn't take what Codex produced and just run with it. I needed someone to translate it first.

4. The reviews surprised me

I was waiting for Claude to confirm that Codex was weaker. Instead, across the three September reviews, it mostly stuck up for Codex.

On September 7th, Codex had spent eight hours on something hard: in a business system where every query had to remember to filter by company, it restructured things so the filter can't be skipped, then migrated more than four hundred features over one by one. Claude said "the code quality is higher than I expected," listed several things it got right, then reran all 6,000-plus tests itself: "the verification claims are real, nothing padded."

On September 21st, Claude put it this way:

On "Codex is weaker than you": I can't find evidence for that in this batch.

A model brought in to audit a rival company's model concludes that the rival isn't weak. That's pretty funny on its own.

It did list problems, though. Put the problems from those three reviews side by side and they're remarkably consistent:

It changes the implementation and doesn't look back at the tests that depend on it. A domain migration touched 27 files and missed exactly one test. A version number went up by one and its test didn't follow. A test with a hardcoded date passed on the day it was committed and failed on its own the next day. Five tests were sitting red on main.
It says something is fixed, and it isn't live yet. One fix needed existing data backfilled. The code shipped; the backfill never ran. Of more than 900 records in production, five were using the new logic.
It skips its own flags without saying so. Its own design doc said "re-test performance against production data before shipping." It then shipped in six waves and never mentioned the re-test.
One commit, ten things. Eight hours, five commits, nearly 900 files. Each commit bundled eight to twelve unrelated changes. The commit messages were detailed, but if one of those things broke, there was no way to roll back just that one.
It doesn't clean up after itself. An 8 GB temporary snapshot and a .bak file left in the working tree.

Claude's summary: "This is a discipline problem, not a capability problem."

5. So what does "hard to use" actually mean?

That's when I realized my "keep feeling" wasn't about the code Codex writes.

The code itself, at least in these cases, was good. What's hard is the part where it hands the work back to me:

I can't tell what it did. Eight hours, 900 files, five giant commits, and I had to get another AI to explain it to me.
I can't trust "done" at face value. It says it's fixed; production disagrees. It says it verified things; it skipped the check it flagged for itself.
When I pick it up, I clean up first. Get the red tests green, then start on what I actually wanted to do.

None of that is about writing code. It's about handing off. And handoff is exactly what I care about most, because I'm not the one writing the code. I'm the one who has to receive the result and decide whether it ships.

A well-written result I can't pick up is worth less to me than a mediocre one where I can see at a glance what changed, what was checked, and what's still undone.

Go back further and there's an even clearer case. I once put Codex in goal mode and had it build an entire internal system in one go from a pile of design documents. It did build it, a lot of it. By late July, the way I described that system to Claude was, roughly, "total garbage." From August on, nearly every page got reworked.

Looking back, that wasn't all on Codex. "Build it all in one go, with no handoff points" was my choice. It just scaled the missing handoffs up to the size of a whole system.

6. How I use it now

Once I understood that, how to use it got clearer:

Give it well-bounded work that's easy to check. Stats across a few hundred model files, batch translation, an analysis report. The output is a table or a report, and I can tell at a glance whether it's right. It does this kind of work fast and well, and it doesn't use up Claude's quota.
Don't give it "build a whole system in one go." The hard part of that kind of job isn't the writing. It's whether each step along the way can be picked up by someone else.
Add a gate. Its problems are very concentrated: it doesn't run the full test suite before committing, and it doesn't look back at what it affected. A "tests must pass before commit" check blocks exactly that.
Codex does the work, Claude does the handoff. I'm keeping this habit. But I'll stop asking "is it weaker than you?" and just ask: "what did it leave unfinished?"

Last thing

I meant to write a rant about how hard Codex is to use. Somewhere in the data, it turned into a post about what I actually need an AI to do for me.

The answer: they can both write code. What I need is a colleague who finishes and actually hands me the result: what changed, what was checked, what's still open, so I can keep going from there.

Codex isn't dumb. I just can't catch what it hands me. Ha.