Claude Code vs Codex CLI — what actually differs, and how to choose

Claude Code and Codex CLI solve the same problem from the same place: an agent in your terminal that reads the repository, proposes edits, runs commands and iterates on the result. They differ in the model family behind them, the extension surface, and how you configure them — not in the basic shape of the work.

This page compares what actually differs, gives a decision rule rather than a verdict, and shows how to run both from one key if you want to judge them on your own code.

Side by side

Both are actively developed and both move quickly, so treat any feature list — including this one — as a snapshot. The structural differences (model family, API surface, config format) are the stable part; specific features are not.

How to choose

There is no general answer to which produces better code — it varies by language, repository and task, and published head-to-head benchmarks rarely resemble your codebase. What you can decide up front is which one fits how you work:

The honest recommendation: both are free to install, so put the same real task from your own repository through each and compare the diffs. An afternoon of that tells you more than any comparison article, including this one.

What each costs to run

Cost is a property of the model and the number of agentic steps, not of the CLI. Both tools resend the system prompt, the task history and fresh file context on every step, so the per-token rate compounds identically in each. Compare the models you would actually run:

A typical agentic step is roughly 25,000 input and 1,200 output tokens, so a 20-step task lands around $0.74 on claude-sonnet-4-6 at these rates. Put your own numbers through the cost calculator rather than trusting a single worked example — output-heavy work shifts the ranking, because output rates differ more between these models than input rates do.

Custom endpoints: a real asymmetry

Both tools support a third-party endpoint, but not equally, and this is the most practical difference between them today.

Claude Code reads ANTHROPIC_BASE_URL and speaks the Anthropic Messages API, which many providers serve. Pointing it elsewhere is three environment variables and no extra software (setup guide).

Codex CLI is stricter. Its model_providers block has a wire_api key, and the current configuration reference lists responses as the only supported value — meaning a custom provider must serve OpenAI's Responses API at /v1/responses, not the far more common /v1/chat/completions:

# ~/.codex/config.toml — wire_api accepts only "responses"
model          = "gpt-5-3-codex"
model_provider = "kunavo"

[model_providers.kunavo]
name     = "kunavo"
base_url = "https://api.kunavo.com/v1"
env_key  = "KUNAVO_API_KEY"
wire_api = "responses"        # requires POST /v1/responses upstream

# A provider that serves only /v1/chat/completions still cannot be
# configured here, whatever base_url you give it.

That still rules out most OpenAI-compatible gateways, which serve /v1/chat/completions and nothing else. It is the reason so many “works with any OpenAI-compatible endpoint” providers quietly fail with Codex CLI: the base URL is accepted, and every request returns 404.

Kunavo serves both surfaces — the OpenAI-compatible chat endpoint and the Responses API at /v1/responses — so the config above works as written, and gpt-5-3-codex ($0.70 / $5.60 per 1M) runs from Codex CLI as well as from Cursor, Kilo Code and Cline. The full walkthrough, including the environment variable Codex reads the key from, is in the Codex CLI API key guide.

One thing worth knowing: because Codex is bound to the protocol rather than to a model family, any chat model behind that endpoint answers — including Claude. Pointed at claude-opus-5, Codex CLI runs end to end with tool calls intact, the gateway translating Responses to the Messages API and back. The cost is that Codex's opaque reasoning items have no equivalent on a non-GPT upstream and are dropped, so the model loses its private scratchpad between turns; the visible transcript is unaffected.

So the asymmetry is narrower than it looks, but it has not disappeared: Claude Code will work against almost any Messages-API provider, while Codex CLI works only against the minority that implement Responses. That is still worth weighing if running on your own endpoint — for cost, routing or governance — is part of why you are choosing between them at all.

Can either drive the other's models?

In one direction, yes. Codex CLI can run Claude models through a gateway that serves the Responses API — it is bound to the wire protocol, not to a model family, so setting model = "claude-opus-5" in the provider block above works end to end, tool calls included. The trade-off is that Codex's opaque reasoning items are dropped on the way to a non-GPT upstream, costing the model its private scratchpad between turns.

The other direction is harder: Claude Code expects Claude-family slugs on the Messages API, so reaching GPT from it needs a local router — another moving part, and some feature loss, since cache_control passes through untranslated only on the native route. The Claude Code router guide covers when that's worth the setup and when a base-URL swap does the job instead.

Running each tool on the model family it was designed for is still the simpler default. But if you want Codex CLI's sandboxing with Claude behind it, that combination is available today — see the Codex CLI API key guide.

FAQ

Which writes better code?

It depends on the task, the language and the repository, and it changes with every model release. Anyone claiming a durable general winner is overreaching. Run both on your own work — that result is the only one that transfers.

Do I have to pick one?

No. They're separate binaries with separate config and don't conflict. Plenty of people keep both installed and reach for whichever suits the task.

Is either one free?

Both CLIs are free to install; neither is free to run, because every step is a paid model call. See is Claude Code free for how the subscription and per-token routes actually compare.

What about Cursor, Kilo Code and Cline?

Those are editor extensions rather than terminal agents, and they take an OpenAI-compatible base URL in a settings field. See the Kilo Code, Cline and Roo Code guide.