Claude or ChatGPT? A Decision Grid You Can Re-check

Most comparisons of these two are written once and never touched again, which is why so many of them quote prices that stopped being true two model generations ago. This one is built to be updated. Every number carries the date it was checked and the page it came from, so when something moves you can replace one cell instead of rewriting the argument.

The date on all of it is 3 August 2026. If you are reading this much later, treat the structure as durable and the cells as stale, and go and read the two pages linked below for yourself.

Is one of them simply better than the other?

No, and the reason is more interesting than the diplomacy suggests. The two families have converged on the specifications people used to compare them on, so the remaining differences are in pricing structure, failure behaviour and operational limits rather than in raw capability.

Both now publish flagship models with a one million token context window and up to 128,000 tokens of output per request. Both support text and image input. Both offer structured output and tool calling. Five years of comparison articles were built on gaps that have closed.

What has not converged is how you get billed, what happens when you hit a wall, and what each one does when it declines to answer. Those are the things that decide a real deployment, and they are also the things a benchmark cannot show you.

The specification table, checked 3 August 2026

Anthropic's figures come from its models overview page. OpenAI's come from its API pricing page and its models reference. Prices are per million tokens.

Three things in that table are worth more than the rest.

The first is the two tier pricing on one side and not the other. GPT-5.6 Sol costs $5 per million input tokens on a short context request and $10 on a long one, with output moving from $30 to $45. Claude Opus 5 costs $5 and $25 regardless of how much context you send. If your workload is short prompts, the OpenAI rate is competitive. If you routinely push several hundred thousand tokens of context, the effective rate is the long context one and the comparison inverts.

The second is Claude Sonnet 5's footnote, which the overview page carries against its price: introductory pricing of $2 per million input and $10 per million output applies through 31 August 2026. That is a real discount with an expiry date on it, and building a cost model on it without noting the date is how a budget surprises you in September.

The third is the knowledge cutoff column, which most comparisons omit. Claude Opus 5's reliable knowledge runs to May 2026, the latest of any model in the table, and Claude Haiku 4.5 stops at February 2025. For anything touching recent events that is a bigger practical difference than a benchmark point.

Which one is cheaper for real traffic?

Neither, until you say what your traffic looks like. The headline rate decides very little once caching and context length are in the picture.

Cached input is where the largest multiplier sits. OpenAI's pricing page lists cached input for GPT-5.6 Sol at $0.50 per million against $5.00 uncached, a tenth of the rate. Anthropic's rate limits documentation states the same ratio from the other direction, noting that cached input tokens are billed at 10 percent of the base input token price. If your application sends a large fixed system prompt or a long document on every request, the cache hit rate is doing more for your bill than the choice of vendor.

There is a second, less obvious effect on the Anthropic side. Its documentation states that for most models only uncached input tokens count toward the input tokens per minute rate limit, and that tokens read from cache do not count at all. The worked example given is a 2,000,000 token per minute limit with an 80 percent cache hit rate producing an effective 10,000,000 tokens per minute of throughput. That is a capacity effect, not just a cost effect, and it is not something the pricing page tells you.

So a fair cost comparison needs three inputs from you before it can produce a number: the share of your prompt that repeats, the typical context length, and the output to input ratio. Output is priced between three and six times input across every row in the table, so an application that generates long answers is dominated by the output column, while a classification pipeline that returns one word is dominated by input and caching. We worked through how to build that estimate properly in the piece on what a real feature costs once you price the whole call, and the companion on why the bill comes in above the estimate covers the parts people forget.

What limits will you hit before quality matters?

A monthly spend cap and a tokens per minute ceiling, in that order, and both are documented rather than discovered.

Anthropic's rate limits page publishes the tier structure. The Start tier carries a monthly spend cap of $500, Build $1,000 and Scale $200,000, with the Custom tier uncapped. Once an organisation reaches its cap, API usage pauses until the next month unless a higher limit is requested. For a small team that number is the single most important line in the documentation, and it is not on any pricing comparison page anywhere.

The per minute limits vary by model in a way that is worth reading before choosing one. On the Start tier, Claude Opus 5 gets 1,000 requests per minute, 2,000,000 input tokens per minute and 400,000 output tokens per minute. Claude Fable 5, the more capable model, gets 1,000 requests per minute but only 500,000 input tokens and 100,000 output tokens per minute. The stronger model has a quarter of the throughput on the same tier. If you are running a batch job, that is the number that decides how long it takes.

Do the coding benchmarks tell you which to use?

They tell you something real and narrow, and the narrowness is documented on the benchmark's own site rather than hidden.

The SWE-bench Verified leaderboard is the one most often quoted. Its own description explains what it is: a human filtered subset of 500 instances, built in collaboration with OpenAI, where annotators checked that problem descriptions are clear, test patches are correct and tasks are solvable from the information given. That filtering is what makes it credible.

The methodological note underneath is the part that should change how you read a score. All language models on that leaderboard are evaluated through mini-SWE-agent in a minimal bash environment, with no tools and no special scaffold, just a simple loop. The site is explicit that this exists to make comparison between models fair. Which it does, and which is precisely why it does not predict your result: your application has tools, a scaffold, retrieval, and a system prompt, and every one of those changes the outcome more than the gap between two adjacent leaderboard rows.

There is a second caveat on the same page. Results produced under different mini-SWE-agent release versions are not necessarily comparable to each other, because the way actions are invoked changed between them. So a number screenshotted from a vendor announcement six months ago may not be comparable to one published this week even on the same benchmark. Our explainer on how SWE-bench Verified actually grades a coding agent goes through the mechanics, and the piece on choosing a coding model without a leaderboard covers what to measure instead.

Job by job: where each one earns its place

This is the section most comparisons skip because it requires taking a position. Four jobs, four verdicts, including the cases where the answer is neither.

Writing

Genuinely close, and the deciding factor is style rather than capability. Anthropic's own documentation describes its models as producing engaging responses suited to rich, human-like interactions, and adds that if you prefer more concise output you should say so in the prompt. That is an unusually candid admission of a house style, and it matches what people report: one family runs long and warm unless told otherwise. If your brand voice is terse, you will spend prompt budget on restraint. If it is conversational, you will spend less.

Neither is a good choice for publishing unedited, which is a separate argument covered in our piece on how much editing an AI draft needs before it ships.

Coding

The cheapest honest answer is to test both on your own repository for an afternoon, because the leaderboard caveat above means published scores will not settle it. What the documentation does settle is the operational side. Anthropic publishes a dedicated effort parameter for controlling how much thinking a model does, defaulting to high on its API and coding tool for the current flagship models. That is a real cost lever on long agentic runs and it is worth knowing exists.

Analysis over long documents

This is where the pricing structure decides it rather than the model. Both sides offer around a million tokens of context. Only one charges more per token once you use it. If your analysis genuinely fills the window, run the arithmetic on the long context column before assuming the model with the lower headline input price is cheaper.

Agents and long running tasks

The most differentiated of the four, and the one where the documentation is most worth reading before committing. Anthropic's launch notes for Claude Fable 5 describe behaviour that changes how you write an integration: the model always has thinking enabled and cannot have it disabled, the raw chain of thought is never returned, and safety classifiers can decline a request. A refusal arrives as a successful HTTP 200 with a stop reason of refusal rather than as an error, which means naive error handling will not catch it.

The billing detail attached is unusually specific and worth knowing: you are not billed for a request refused before any output is generated, and retrying on another model earns a credit that refunds the prompt cache cost of the switch. Whether you build on that model or not, the shape of it tells you something about what long horizon agent work now involves. Our overview of whether you need an agent framework or just the loop covers the layer above this decision.

What about the chat subscriptions rather than the API?

Different product, different decision, and the honest position is that we could not verify current consumer plan prices from either vendor's own pages on 3 August 2026. One returned a server error and the other blocked automated access, so rather than repeat a figure from a third party we have left the row out. That is the rule this page runs on: a number appears here only if we opened the page that states it.

What can be said without a price is structural. The subscription and the API are billed on completely different logic. A subscription buys a person's usage with soft caps; the API buys tokens with hard ones. Teams routinely compare a subscription price against an API price and conclude one is cheaper, which is a category error. If you are building something that runs without a person watching, the subscription is not an option regardless of its price.

Does data retention differ between them?

Yes, and on at least one model it is a documented hard constraint rather than a setting. This is the axis most likely to make the decision for a company with a compliance function, and it almost never appears in a comparison.

Anthropic's launch notes state that Claude Fable 5 and Claude Mythos 5 carry 30 day data retention and are not available under zero data retention, because both are designated covered models. If your organisation has committed to zero retention with a client or a regulator, the most capable model in that family is off the table regardless of how it performs, and no amount of configuration changes that.

The practical lesson generalises beyond this one model. Retention terms, regional routing and endpoint types are settings that live several pages away from the pricing table, and they are the ones with contractual consequences. Before running a capability comparison at all, it is worth checking whether the model you are about to prefer is even permissible for your data. That check takes ten minutes and has ended more evaluations than any benchmark.

What if you are already committed to one?

Then the useful question is not whether to switch but where the second one earns a place alongside the first, and for most teams there is at least one place.

Routing by job is the cheapest version. A classification step, a summarisation step and a generation step have completely different cost profiles, and there is no rule that says they must run on the same provider. Sending the cheap high volume step to the cheapest adequate model in either family and reserving the expensive model for the step that actually needs it is usually a larger saving than any negotiation.

Fallback is the second. Both providers have outages, and both have per minute ceilings that a traffic spike will find. A second provider wired behind the same interface converts a service interruption into a slower response. The work is small if the interface was built with two implementations in mind from the start, and painful if it was not, which is the real argument for the adapter mentioned later on this page.

The one thing not worth doing is running both continuously on the same task to compare quality in production. It doubles the bill, produces inconsistent output for your users, and answers a question a fixed test set answers better for a fraction of the cost.

When is the answer neither?

More often than a comparison article usually admits, and it is worth naming the cases plainly.

• The data cannot leave your building. Neither hosted API solves this. An open weight model on your own hardware does, at a real cost in quality and effort, which we covered in what your hardware can actually handle.
• The task is classification at very high volume. At millions of calls, the smaller models in each family, and often a smaller model from neither, will beat both flagships on cost by an order of magnitude with no quality loss on a simple label.
• The task is deterministic. A regular expression, a lookup table or a database query is cheaper, faster and correct. A surprising share of features people build on a model are this.
• You need a guarantee rather than a probability. No model in this comparison provides one. That constraint belongs in the layer around the call.

How to keep this decision current

The reason this page is structured as a grid with dates rather than a verdict is that the verdict decays and the grid does not. Four habits keep it useful.

Re-read the two pricing pages quarterly, not when you notice the bill. Both vendors change rates and introduce discounts with expiry dates, and the Claude Sonnet 5 introductory price expiring on 31 August 2026 is a live example sitting in the table above.

Keep twenty of your own real inputs as a fixed test set. Running the same twenty against a new model takes an hour and tells you more than every leaderboard combined, because it samples from your distribution rather than someone else's. Our note on how to tell whether a prompt change actually helped covers doing that without pretending it is science.

Write down which limit you are closest to. Most teams cannot answer whether they are near a spend cap, a tokens per minute ceiling or neither, which means they will find out during an incident.

And keep the integration switchable. Both APIs speak a similar enough shape that a thin adapter is a day of work, and having one converts a vendor decision from a commitment into a preference. If you are building a product on top of these calls, that adapter is also where structured output enforcement and retry logic belong, as we set out in the piece on forcing a model to hold a schema. For the pricing of building on our own platform rather than assembling this yourself, the plans and credits page lays out what a build costs end to end.

The short answer, stated plainly

If you send short prompts and generate short answers, the lower output price wins, and on 3 August 2026 that favours the Claude column at every comparable tier. If you send very long context, check whether your provider charges a premium for it, because one of them does and that reverses several rows. If you are running unattended production work, read the rate limit page before the pricing page, because the $500 monthly cap on an entry tier will stop you before the per token price ever becomes the problem. And if the task involves long running agentic work, read the refusal and fallback behaviour before you write the error handling, because a decline that arrives as a successful response is the kind of thing you find out about in production.

Everything else is preference, and preference is a perfectly good reason to pick one. It is just not the same thing as an answer, and articles that present it as one are the reason this comparison needed writing again.