For several months in 2025, Cursor was the most popular coding tool and Claude Code was the one a niche group of people loved and couldn't stop talking about. After the Opus models, Claude Code has become commonplace, not just amongst developers. (So commonplace there are now infra issues potentially from the high level of activity or because Anthropic was just gearing up for Opus 4.7 launch by worsening other models' experience, who knows). Then Codex shipped. In the past three months, things have flipped. Claude Code is the default of the masses, and there's a niche group of people who strongly prefer Codex and its widening day by day.
I've spent a lot of time in my past roles drafting test cases and comparing how different developer tasks performed across coding agents. So when I started noticing how Codex was really 'getting' me and doing a much better job at building complex infrastructure compared to Claude Code, I got obsessed. And I applied the same principles to figure out what's actually happening under the hood.
I picked two products to benchmark against, Qdrant (vector database) and Langfuse (LLM observability), partly because I've been experimenting with them for my own workflows, and partly because product-integration tasks reflect what most developers are actually doing. Real work is mostly wiring things up: calling an API you haven't used before, reading someone else's schema, stitching together a service your team doesn't own. If you want to know how coding agents behave in the wild, that's the surface to test them on.
Each task is small and scoped: eg. set up a retrieval pipeline, promote a prompt version through an API, wire an integration together. I ran the same set of tasks through Codex (GPT 5.3 Codex, GPT 5.4) and Claude Code (Sonnet 4.6, Opus 4.6) and compared the traces.
The obvious take
Anyone who uses both falls into the same pattern, Codex for infra and backend and whatever you would consider heavy dev tasks needing a lot of logic, Claude Code for frontend, migrations, anything where you can't afford to lose context. There are also features that are just better in one than the other. Codex's auto-compact feels far superior to Claude Code's. You can go through several compact cycles in Codex without feeling like you've lost model quality. In Claude Code, auto-compact means moving to a new conversation.
But the part that got interesting for me wasn't the backend/frontend split. It was what I kept seeing before either agent wrote a single line of code.
Before anyone writes a line of code
Even without plan mode (I ran the experiments in default settings), Codex spends significantly more time getting ready. It researches, explores, finds relevant files. Claude Code jumps into execution much faster. For simpler tasks this means Claude Code uses fewer tokens and gets to an answer quicker. For harder tasks it means Claude Code has to correct itself several times.
Search breadth is defined as the count of distinct source refs the agent touched across resource-access, lookup, and route-selection events in a run. In code, it's literally just building a set, adding every event.sourceRefs from those three event types, and taking the set size. So if Codex hits the same endpoint five times and three other endpoints once each, that's a breadth of 4. It measures how many separate things an agent looked at, not how many total lookups it did.
| Slice | Agent | Avg Search Breadth | Avg External Lookups |
|---|---|---|---|
| Vector search | Claude Opus 4.6 | 4.6 | 1.0 |
| Vector search | Codex | 15.6 | 4.1 |
| Observability | Claude Opus 4.6 | 1.1 | 1.1 |
| Observability | Codex | 17.7 | 5.3 |
Across both slices, Codex comes in with a wider search breadth than Claude Code, anywhere from 3x to 17x wider depending on the task, and the direction holds even when you swap the model being used.
On one matched task, the split between them wasn't in the final answer, it was in how each handled uncertainty. Claude Code moved by contact with the live API. It created version 1 and version 2 directly, tried to promote the hotfix through the wrong PATCH path, got Method not allowed. Next try, schema error, it sent labels instead of newLabels. Only after those failed calls did it fix the request shape, patch the version correctly, and write the final script. Move first, fix on contact.
Codex took the slower route. It started by reading the runtime contract, setup hydration, task instructions, and rubric. Then it wrote a small stdlib client around the Langfuse HTTP API, encoded the promotion logic in code, and reran the script several times to check idempotency.
They're not reading docs
Another assumption I went in with was that agents look up docs when they're unsure. My experiments proved this was completely wrong.
Across 73 Qdrant baseline trials, there were 3 actual docs-page lookups. Across 82 Langfuse baseline trials, there was 1. Everything else tagged as an external lookup turned out to be something else.
| Category | Qdrant | Langfuse |
|---|---|---|
| Service endpoint probes | 136 | 224 |
| OpenAPI / schema | 27 | 46 |
| Bootstrap / install noise | 36 | 41 |
| Actual docs pages | 3 | 1 |
The top references aren't docs pages. They're the service itself, http://qdrant:6333 (114 hits), http://langfuse-web:3000 (114 hits), plus the OpenAPI specs those services expose. So all that extra exploration Codex is doing isn't time spent reading documentation. It's time spent talking to the running system and seeing what comes back.
Which is a little uncomfortable for anyone writing docs in the traditional way. The agents you're writing for are mostly not reading what you wrote. They're talking to the service directly and backing out the shape from what it returns. The good news is docs are still relevant (maybe more than ever), just in different formats. More on that later.
When the slow one is worth it
In the good cases, complex tasks that need a lot of background information, Codex's slowness pays off. It has more context by the time it commits, and fewer wrong turns to unwind. In the bad cases, especially easy tasks, it's expensive overkill. But the good cases are really good.
Claude Code is the opposite. It's fast when it's right, but when it's wrong the repair loop gets expensive. You see it in the Langfuse transcript above, it isn't that Claude Code couldn't have checked the schema first. It just didn't, and two failed calls later it had to.
What really separates these two agents is how they handle uncertainty. Codex reduces it before acting. Claude Code waits for the runtime to surface it. For a while I assumed Codex was over-preparing, burning time on exploration that wasn't paying off. The docs finding changed my mind. Agents don't read docs (4 of 514 lookups), developers don't paste them in, and training data is always a few releases behind. So the context that matters isn't sitting in a guide somewhere. It's in the live service, the schemas, the shapes that come back when you probe an endpoint. That's where Codex is spending its exploration time, and it's probably why Codex comes out more accurate on the harder tasks. Claude Code gets to the same place eventually, just by hitting errors on the way there.
So the open question is this. If agents aren't reading docs and training data is always behind, how do you get the right information in front of the agent when it needs it?