This is the tool CodexHow was actually built to hold. Ask any developer working across both ecosystems the same question — "is Codex or Claude cheaper for what I'm actually doing?" — and the honest answer is that nobody publishes a side-by-side answer, because neither vendor has a reason to, and every third-party comparison you'll find either compares list prices with no workload attached or quietly picks a winner.

What this tool actually does

You describe one workload — an input token count and an output token count — once. That same workload is priced twice: once against OpenAI's published Codex/API rates, computed from this site's own facts module, and once against Claude rates you supply yourself. Both totals use the exact same token counts, so the comparison is apples to apples rather than two different scenarios dressed up to look comparable.

The OpenAI side is not a guess. It reads the real published price bands for the model and service tier you pick, and it correctly applies the long-context repricing rule when your workload crosses the published threshold — which reprices the entire request, not just the tokens over the line, and is exactly the kind of detail a naive comparison gets wrong.

Why you enter the Claude numbers yourself

This site's own research is OpenAI-only, on purpose — every figure it publishes is checked against a dated OpenAI source, and CodexHow will not invent, estimate, or quietly borrow a Claude price from somewhere it can't cite directly. Rather than publish a stale or unverifiable number for the other side of the comparison, this tool asks you for it. ClaudeHow runs the same kind of computed, cited approach for the Claude side — its own token & cost estimator will hand you exactly the rate figures this tool wants, already computed for the model you're actually comparing against.

Why there's no "winner"

A workload-priced comparison like this one will always favour one side for a specific input/output ratio, model choice, and service tier — and favour the other side the moment any of those change. A tool that collapsed that into a single verdict would be lying by omission. What this tool gives you instead is the actual number for your actual workload, plus the two totals sitting next to each other so you can see exactly how close or how far apart they are — and the freedom to change the inputs and watch the answer move, because it isn't fixed.

How to read the result

The comparison table shows both totals for the token counts you entered, with the cheaper side marked the way a diff marks an addition. If the difference is small relative to the total, that's worth noticing on its own — it usually means the decision should be made on grounds other than price: context window headroom, model quality for your specific task, or which ecosystem your team already has tooling around. If the difference is large, change the service tier or model on the OpenAI side and watch how much of that gap is really about the model choice versus the provider choice — they are not always the same question.

A note on service tiers

Batch and Flex processing are priced identically to each other for OpenAI's text models but have different delivery semantics — Batch guarantees a fixed completion window, Flex doesn't carry the same guarantee. If your workload can tolerate either, picking between them is a reliability decision, not a cost one, and this tool's numbers for both will look the same on purpose.

A worked example, to show the shape of the answer

Say you're running a nightly job that reviews a moderate batch of pull requests, each one sending a meaningful chunk of diff and surrounding file context as input and getting back a shorter written review as output. Priced on the OpenAI side at the Standard tier against the CLI's actual default model, that's a real, specific dollar figure for the night's run. Priced on the Claude side at whatever rate you've read off ClaudeHow's own reference pages for a comparable model, that's a second specific figure for the exact same token counts. Neither number means anything general on its own — what matters is that they were computed from the same workload, so the difference between them is a real difference in provider cost for that job, not an artifact of comparing a small request on one side against a large one on the other.

Now change one variable at a time. Switch the OpenAI model to the Codex-optimized one instead of the CLI default, and watch the gap move — sometimes it closes, sometimes it widens, depending on how your token counts split between input and output, because the two models' input and output prices don't move together. Switch service tier to Batch, and the OpenAI total drops by the published Batch discount while the Claude side, if you're comparing against a synchronous rate, doesn't move at all. This is the actual value of a linked, editable comparison over a static blog post's numbers: the shape of the answer for YOUR workload only becomes visible once you can see it change.

What "showing your working" means here

Every input this tool uses is visible on the page while you use it — the model, the service tier, the token counts, and the Claude rates you typed in are all sitting in the URL, so a result you get here is a link you can send someone else, and they'll see the exact same assumptions rather than a number with no context behind it. That's deliberate: a cost comparison that can't be checked or reproduced by the person reading it isn't really a comparison, it's a claim.

Cross-Provider Cost Comparison