Claude Code vs. Codex vs. Cursor Agent vs. OpenCode: stop trying to pick one

Every few weeks someone asks me which coding agent they should standardize on. Claude Code or Codex? Cursor Agent or OpenCode? They want one answer they can commit to, wire into their setup, and stop thinking about. I understand the impulse. It is also the wrong question, and I want to explain why before I talk about the four tools themselves.

The honest version of the comparison is less satisfying than a leaderboard. All four of these are terminal-driven agents that read your code, run commands, edit files, and iterate. They are closer to each other than they were a year ago. The differences that matter are not “which one is best” but “which one is best at the thing in front of you this afternoon,” and that answer moves.

The four, as they actually feel to use

I have driven all four on real work, so here is a fair characterization rather than a spec sheet. Treat these as tendencies, not verdicts. The models underneath change monthly, and any hard claim I make today has a short shelf life.

Claude Code is the one I reach for on ambiguous, multi-file work. It tends to plan before it acts, ask a clarifying question when a task is underspecified, and keep a coherent thread across a long session. Its tool use, running a command, reading the result, adjusting, feels deliberate rather than frantic. If a change touches a dozen files and needs judgment about how they fit together, this is usually where I start.

Codex leans into structured, self-checking execution. It is comfortable running in a loop against a concrete target: make the test pass, make the build clean, satisfy the spec. When the task has a crisp definition of done, it stays on task well. Its reasoning tiers are exposed at the CLI level, so you can dial effort up for a gnarly problem or keep it modest for routine work.

Cursor Agent carries the DNA of the editor it came from. It is fast, fluent at navigating a codebase, and pleasant for the tight loop of “find this, change that, show me.” If your mental model is “I know roughly where the change goes, go make it,” it fits that shape naturally.

OpenCode is the open one, and that is its whole appeal. It is model-agnostic by design, so it is the natural home for people who want to point an agent at a provider of their choosing without being locked to a single vendor’s stack. If you care about the harness being open and swappable underneath you, it earns a look.

Notice what I did not do there. I did not give you benchmark scores, because the ones I could quote would be stale by the time you read this, and because they rarely predict how a tool behaves on your codebase. Interaction style, planning behavior, and how gracefully a tool recovers from its own mistakes matter more day to day than a number, and those you can only feel by running the thing.

Picking one is optimizing the wrong variable

Here is the turn. The premise behind “which one should I use” is that a coding agent is a platform decision, like picking a database. It is not. It is a per-task choice, like picking which colleague to hand a ticket to.

You would not give the same engineer the delicate cross-cutting refactor, the five-minute typo fix, and the tedious test-writing pass just because they happened to be the first person you hired. You would match the work to the strength. Agents are the same. A big architectural refactor rewards the tool that plans and holds context. A quick, well-scoped fix rewards the fast one that does not overthink. A “write tests for this module until they pass” job rewards the one that loops against a concrete gate. Committing to a single harness for all three means you are using the wrong tool two-thirds of the time, on purpose, for the sake of a tidy setup.

The other half of the argument is time. These tools do not hold still. A model release can flip which agent is strongest at a given category of work in a single month. If you standardized on one agent last quarter because it won a comparison, that comparison has already expired, and you are now defending a choice that the evidence no longer supports. The only stance that survives the churn is refusing to marry any of them.

So the professional move is not allegiance. It is fluency across all four, and a habit of asking “who is best at this specific task, right now” every time you start one. There is a sharper version of the same idea: when a task is important and you genuinely are not sure who will do it better, do not guess. Hand the identical task to two agents at once, let them both produce a diff, and keep the better one. The loser cost you nothing but a little compute you were already paying for. You stop theorizing about which agent is better and just read the two answers.

That sounds great and is completely impractical if each agent lives in its own terminal, with its own output format, editing the same working tree. I know, because I tried exactly that and it fell apart. Running four different harnesses by hand, each shouting in its own dialect, is how you end up standardizing on one out of sheer exhaustion. The per-task idea only works if switching is free.

Making the switch cost nothing

That is the problem Fletch exists to remove. Fletch is a macOS app that drives the official CLIs you already install and pay for, claude --print, codex exec, cursor-agent, opencode run, behind one consistent interface (Pi and Antigravity are there too, experimental). It does not ship a model of its own. It uses your own keys and subscriptions directly, with no middleman keys and no markup. The credential that talks to the provider is yours.

Two things about how it works make the per-task habit practical. First, whichever agent you pick, Fletch normalizes its live output and its on-disk transcript into one common event model. Messages, reasoning, tool calls, results, they all render the same way regardless of which CLI produced them. You read a Codex session and a Claude session with the same eyes, so switching between agents does not mean relearning how to read the screen. Second, you choose the agent, and where the CLI allows it the model and reasoning level, at the moment you spawn a workspace, and it stays fixed for that workspace’s life. Choosing per task is the default motion, not a workaround.

Racing two agents becomes literal rather than aspirational. Each agent runs in its own isolated checkout, so you can spawn the same task on two of them, let both finish, and keep the better diff without either one touching the other’s files or your real working tree. And because the model list is built live from each installed CLI and enriched from an online catalog, newly released models show up without you updating anything, so the “which is strongest this month” question stays answerable instead of frozen at whatever was current when you installed.

None of that requires you to believe any single agent is best. That is the point. The tools will keep leapfrogging each other, and the right response to a field that reshuffles monthly is not to bet on a winner. It is to hold all the tickets and play whichever one the moment calls for. Pick the agent for the task, not for the year.