Claude Code vs Codex vs Cursor: Which Tools They Pick
The Short Answer
On September 3, 2026, Armature published the first large-scale measurement of a question nobody had quantified: when you tell a coding agent to “add payments” or “add email,” which vendor does it actually install?
The methodology: 75 synthetic repositories across 10 languages, 16,893 sessions run against the real pinned CLIs of Claude Code, Codex and Cursor, with 5,292 valid sessions retained for the first analysis.
The headline: all three agents chose the same tool in only 42% of category cells.
| Claude Code | Codex | Cursor | |
|---|---|---|---|
| Voice agents | Twilio | OpenAI Realtime API | Vapi |
| Agreement across all categories | colspan | 42% | of cells |
In the majority of categories, your choice of coding agent is a choice of vendor — made silently, at the moment the agent runs npm install.
Why This Is Different From a Benchmark
Most agent evaluations ask: did it produce working code? This one asks: what did it build with?
That distinction matters because of how these tools actually behave. As Armature frames it, the agent is the real product, not a stand-in for one:
It does not stop at a recommendation. It installs the tool and writes the code. If the first choice does not work, it moves to the second one, the way a developer would.
A recommendation you can ignore. A dependency in your lockfile with 400 lines of integration code around it is an architectural decision that has already happened. By the time it reaches code review, the cost of reversing it is real.
Where the Disagreement Comes From
1. Different models, different priors. Claude Code defaults to Claude Opus 5, Codex to GPT-5.6 Sol, Cursor to its own Composer models plus whichever frontier model you select. Each carries a different distribution over “what is the standard tool for X,” shaped by different training data and cutoffs.
2. Different search behaviour. The study found the three agents search the web in notably different ways — different trigger conditions, different query formulations, different amounts of verification. Different candidate sets in, different choices out. An agent that searches less falls back harder on training priors, which skews older.
3. Different harness defaults. System prompts, tool sets and permission models differ per product. An agent that is cheap to let run will explore more options than one gated behind approval prompts.
The Self-Preference Signal
The voice-agent row deserves attention on its own: Codex chose the OpenAI Realtime API.
That may well be a defensible technical choice for that task. It is also, unavoidably, the agent’s own vendor’s product. The study does not establish deliberate self-preference, and a single category cannot — an OpenAI-trained model plausibly knows OpenAI’s APIs better and has more of that documentation in its training data, which produces the same outcome without any thumb on the scale.
But the practical implication holds either way: if you use a vendor’s coding agent, expect a bias toward that vendor’s platform services. Whether the mechanism is intent or training-data density does not change what lands in your dependency tree.
What This Costs You
Three quiet failure modes:
Fragmented stacks. Two teams, two agents, two payment providers. Now you reconcile across both, maintain two integrations, and train everyone on both.
Unbudgeted vendor spend. Twilio, the OpenAI Realtime API and Vapi have materially different pricing shapes. An agent choosing on technical fit alone has no view of your negotiated rates or committed spend.
Silent lock-in. The most expensive dependency is the one nobody decided to take. Six months in, the migration cost is a quarter of engineering time.
What to Do About It
Pin your stack in the repository, not in your head.
Every major agent reads a project instruction file — AGENTS.md, CLAUDE.md, .cursorrules, or the equivalent. Put your approved vendor per category in it, explicitly:
- Payments → the specific provider
- Email → the specific provider
- Auth, queues, storage, observability, voice → same
- “Do not add a dependency outside this list without asking”
Two rules make it stick:
- Commit it to the repo. Personal settings do not propagate to teammates or to CI-driven agent runs.
- Treat an unlisted dependency as a review failure, the same as a failing test. A lint rule over the lockfile diff enforces this better than good intentions.
Then verify. Once per quarter, give all three agents the same greenfield task and diff what they install. If a category has drifted, your instruction file is stale — the underlying models change every few weeks, and their priors change with them.
Does This Change Which Agent to Pick?
Mostly no — and that is the useful conclusion. The 42% figure is not evidence that one agent has better taste. It is evidence that tool choice is under-specified, and under-specification gets resolved by whichever model happens to be driving.
Choose your agent on the criteria that actually differ in kind: autonomy versus supervision, terminal versus IDE, cost structure, policy controls. Then remove tool choice from the agent’s discretion entirely by writing it down.
Last verified: September 6, 2026.