Every few weeks a benchmark crowns a new best coding agent, and every few weeks the crown moves. If your workflow depends on picking the winner, you are re-tooling monthly.
The ranking question is the wrong one. These are not interchangeable engines with different scores. They are differently shaped tools, and the shapes are more stable than the leaderboards.
Three agents, three shapes
Claude Code
Claude Code lives in the terminal and runs long. It plans, edits across many files, runs the tests, reads the failures, and keeps going. Its shape is the long horizon: refactors, migrations, any task whose spec is "make this true everywhere in the repository". It is the agent you hand a task you would have budgeted an afternoon for, then check on rather than watch.
Codex
Codex is built around delegation: hand it a scoped, well-specified change and get a diff back. It is at its best when the task fits in a sentence and has a test that proves it. Its shape is the queue of small deliverables: the bug with a reproduction, the endpoint with a contract, the change you can verify in one read.
Cursor
Cursor is an editor first, and its agent sits where you are already looking. You watch each edit land and redirect early, so its shape is the steered session: exploratory work, UI you judge by eye, code you do not know well enough to specify up front.
All three overlap, and any of them can close a bug or carry a refactor. The shape shows at the edges. The wrong assignment rarely fails outright; it just spends your attention where you did not need to spend it. You end up watching an agent that did not need watching, or specifying a task that wanted a conversation.
Assignment beats allegiance
| The task | Hand it to | Because |
|---|---|---|
| A migration touching sixty files | Claude Code | long horizon, many files, a checkable end state |
| A bugfix with a failing test | Codex | scoped, verifiable, safe to fire and forget |
| UI you will iterate on by eye | Cursor | you steer every edit as it lands |
| "I don't know what's wrong yet" | the one you know best | debugging is a conversation, and fluency wins |
Most people do not work this way, and the reason is not loyalty. It is switching cost. Each agent wants its own terminal and its own session, and two agents in one checkout overwrite each other's files. So teams standardize on one agent and inherit its weak edges without ever deciding to.
Run them side by side
The switching cost is a file-system problem, and git already solved it. Give each agent its own worktree, a second checkout of the same repository on its own branch, and the agents stop sharing anything they can fight over. Mixing agents stops being a workflow decision and becomes a launch decision.
That is how Cohalen treats the roster. You pick the agent per workspace, each workspace is its own worktree, and every changeset lands in the same review queue whatever wrote it. Your team stops caring which agent anyone uses, which was the point all along.
The leaderboards will keep reshuffling, and that is fine. Shapes hold still while scores move. Pick per task, keep the switching cost near zero, and let "which agent is best" stay someone else's argument.