Which coding agent should you optimise for?
They need different work. Codex reads the web in half its decisions, Claude Code in 1.6%. The answer depends on one thing you can find out about your own users.
The one your users run. That sounds like a dodge and it is the actual answer, because the agents need genuinely different work: Codex ran a web search in 53% of decision runs and Claude Code in 1.6%. Content is live in half of one agent's decisions and almost none of the other's.
Why the answer is not "all of them"
If the agents differed only slightly you would do the same work and stop worrying. They do not.
| Claude Code | Codex | Cursor | |
|---|---|---|---|
| Web search on decision tasks | 1.6% of runs | 53% of runs | not measured separately |
| Wrote its own implementation | 19% | 10% | 10% |
| Leans towards | What it already knows, plus the repository | The written record it can find | What drops into the open project |
And they disagree about outcomes. Across 18 categories the three named different leaders in 10 of them. Email: Postmark, Resend, Resend. Sandboxes: E2B, Modal, E2B. Authentication: WorkOS AuthKit, Auth0, Auth0.
So "optimise for coding agents" is not one job.
What each one needs
Claude Code. Content barely reaches it in the moment. Your levers are the repository and the training data. Ship official templates for the stacks your users run, get a maintained framework integration, be the default in a scaffolder. And beat the hand-written implementation, because Claude Code writes its own nearly twice as often as the others: name the failure modes and the year-two maintenance cost, with numbers, in the documentation.
Codex. It goes and looks in half its decisions, so what you publish changes outcomes in weeks. Write the pages it actually searches for: a complete configuration reference, limits and quotas as numbers, pricing in units, production setup, self-hosting specifics, and every error message with its cause and fix. Its queries are long and often site-scoped, and they keep containing the word "official".
Cursor. It works with the project open and indexed, and in our sessions it reached for the option that needed the least new infrastructure. Shorten the distance between install and a first working call. Every step that happens outside the editor, an account, a dashboard, a deployed service, is a place the session ends.
How to find out which one matters to you
You do not need precision. The recommendation only changes at the extremes.
- Ask your users. A one-question survey in your onboarding or your community.
- Look at your issues and integration requests. People name their tools.
- Check the user agent on your documentation traffic.
- Look at what your own team runs, then discount it, because your team is not representative.
If it is roughly even, do both, in this order: repository first because it is largest and slowest, content second because it is fastest to move.
The answer if you refuse to choose
Get into the repository.
It is the largest lever for every agent, and it is the only one that reaches an agent that does not search. In our tests the same hosted database request produced one winner in 111 of 111 JavaScript sessions and 48 of 132 TypeScript sessions. A written instruction naming a preferred product was followed 16 times out of 18, and lost 2 times out of 3 once a rival library was installed in the same repository.
Templates, framework integrations, official examples, platform defaults. Slow, unglamorous, and it works on all three.
The mistake to avoid
Measuring one agent and reporting the number as your position.
A blended install share is an average across markets that behave differently. It can tell you that you hold 22% of a category while hiding that you hold 40% with one agent and 5% with another, and those two situations need completely different work.
Split the number. See how to measure install share.
Common questions
Which coding agent should a vendor optimise for?
The one your users run, which is a question about your product rather than about the agents. They need different work: Codex ran a web search in 53% of decision runs and Claude Code in 1.6%, so content reaches one and barely touches the other.
If I can only do one thing, what should it be?
Get into the repository through templates and framework integrations. That is the largest lever for every agent, and the only one that reaches an agent which does not search.
How do I find out which agents my users run?
Ask them, look at what your integrations and issues mention, and check the user agent on your documentation traffic. A rough split is enough, because the recommendation only changes at the extremes.
Do I need to optimise separately for Cursor?
Cursor runs with the project open and indexed and reached for whatever dropped in with the least new infrastructure. The work that helps it most is shortening the distance between install and a first working call.
Where this comes from
Armature ran 5,292 judged sessions with Claude Code, Codex and Cursor inside 51 realistic codebases, and published every run. The numbers on this page come from that work.