Short version: the context window stopped being the deciding factor. Both families now ship a million-token window, so the choice moved to three things you only feel in production - how reliably the model returns the shape you asked for, what your bill looks like once caching is on, and how much of your system is already welded to one vendor. Prices below were checked on 10 September 2026 and they move; treat them as a shape, not a quote.
I run 2pizza.team. We are an official Anthropic partner and we also ship systems on OpenAI, because clients arrive with what they already have. Over the last two years I have watched this comparison get rewritten by both sides roughly every quarter, and almost every article about it ages badly within a month because it is built on a spec table.
This one is built on what actually breaks. If you are picking a model for an automation system rather than a chat toy, the spec table will not help you much. What follows is the shortlist of things that have decided the answer on real projects, and the one section most comparisons leave out: what does not work.
The context window argument is over
For two years the honest answer to "which model handles long documents" was Claude, because 200,000 tokens against 128,000 is a real gap when you are parsing contracts. That gap is gone. Claude Opus 5 and Sonnet 5 both carry a 1M token window; the current OpenAI flagships are in the same territory. Haiku 4.5 sits at 200K, which is still more than most pipelines need.
What replaced it is subtler and costs more money: long-context pricing tiers. OpenAI applies a higher rate above a length threshold, so a request that crosses it can roughly double in price without you changing a line of code. Anthropic's published rates for Opus 5 and Sonnet 5 are flat. If your workload is bimodal - mostly short calls with occasional monsters - model the monsters separately before you commit.
What we actually pay, and where the bill really comes from
Anthropic list prices per million tokens: Opus 5 at $5 input and $25 output, Sonnet 5 at $2 and $10, Haiku 4.5 at $1 and $5. On the OpenAI side the September 2026 aggregator figures put GPT-6 Astra at roughly $10 and $50, the 5.6 family from about $5 and $30 down to $0.20 and $1.20 at the small end, with an August price cut on the mid tier. Check the vendor pricing page before you budget; both change these more often than they announce them.
Now the part that matters more than any of those numbers. In every production system we have built, the model rate was not the main cost driver. Two mechanics were: prompt caching and retries. Both vendors bill cached input at about a tenth of the standard rate, and both halve everything on batch. A pipeline that reuses a large system prompt across thousands of calls and gets caching right pays a fraction of what the rate card implies. A pipeline that invalidates its cache on every request - a timestamp in the system prompt, an unsorted JSON blob, a tool list that reorders - pays full price forever and nobody notices, because the bill looks plausible.
The retry tax nobody budgets for
If a model returns malformed JSON on five percent of calls and your code retries, you are paying 105 percent of your token estimate and adding latency to every slow path. At a hundred thousand calls a month that is not a rounding error. This is why output reliability shows up in the cost section rather than the quality section: it is a cost line.
Structured output is the thing that decides most builds
An automation system is a machine that routes on a field. If the model returns a JSON object where status is sometimes "approved", sometimes "Approved", and once in a while a sentence explaining why it chose approved, the router breaks. Not loudly. It breaks on the two percent of records that then sit in a queue nobody watches.
Both vendors now solve this properly rather than by prompting. On the Anthropic side you set a response format through output_config, or mark a tool strict so its arguments validate exactly against your schema. That is a real constraint enforced server side, not an instruction the model may drift from on turn forty. If you are still parsing free text with a regex and a prayer, that is the single highest-leverage change you can make this week, on either vendor.
One caveat from our own postmortems: current models may escape strings inside tool arguments differently than older ones - Unicode, forward slashes. If any of your code does raw string matching on a serialized tool input instead of parsing it, it will fail silently after a model upgrade. Parse the JSON. Always.
Thinking became a dial, and the dial has a price
The biggest practical change since 2025 is that reasoning stopped being a checkbox. Anthropic's current models use adaptive thinking - the model decides how much to reason - and you control spend with an effort setting from low through max. The old fixed thinking budget is gone and returns an error on the current generation. Code written against that pattern breaks on upgrade.
This matters commercially because effort is now your first quality-versus-cost lever after caching. In our experience the interesting finding is counterintuitive: a newer model at low effort often beats an older model at high effort, and costs less. Before you build a cascade that routes cheap work to a small model, measure the flagship at low effort on the same tasks. A cascade also forfeits cache reuse, because caches are scoped per model - people forget that and are surprised when the savings do not appear.
Lock-in is a real cost and it is asymmetric
If you already have twenty OpenAI integrations, an embeddings store, and a team fluent in that SDK, the correct answer is usually to stay unless something is actually failing. Migration is not a model swap. It is a prompt rewrite, a re-tune of every temperature and format assumption, and a fresh eval run. We quote that work honestly and it is rarely the cheapest thing a client could do with the same budget.
The exception is when the failing thing is reliability rather than capability. If your system breaks on output format or long-document handling, a migration pays for itself. If it breaks because the prompt is vague, no vendor will fix that.
Rules of thumb we actually apply
Long documents in a single call, contracts and invoices: either family now, but check the long-context price tier before you commit
Output that must validate every time: use enforced structured output, not prompt instructions, on whichever vendor you are on
High volume and latency-tolerant: batch it and halve the bill, on either side
Already deep in one ecosystem and nothing is broken: stay, and spend the migration budget on caching and evals instead
Real-time voice: OpenAI's realtime stack is still the more mature one
Cost is the problem: fix caching and retries first, change model second, build a cascade last
What does not work
Picking on benchmark scores. Public benchmarks measure things that are not your workload, and both vendors optimise for them. We have had models that led a leaderboard lose to a cheaper one on our own extraction eval, because the task was mostly about following a schema, not about reasoning.
Migrating without an eval. If you cannot measure the current system, you cannot tell whether the new one is better; you will be arguing from vibes about a change that costs real money. Build a small eval on your own traffic first - a few dozen real records with known correct answers is enough to make the decision non-religious.
Copying a prompt across vendors unchanged. Prompts carry assumptions about how a specific model behaves, and those assumptions are usually invisible until they are wrong. Prompts written for older models are often too prescriptive for current ones and actively reduce output quality. Rewriting the prompt is part of the migration, not an optional polish step.
How we choose on a real project
We start with the constraint that is hardest to move. Usually that is an existing integration or a compliance requirement about where inference runs. Then we look at the output contract: if the system routes on a field, structured output support decides it. Then we model cost at the client's actual volume with caching switched on, not at list rate. The model name is usually the last thing we pick, and on about half our builds we end up using two - a capable model for the judgment step and a small one for bulk extraction.
That is less exciting than a verdict, but a verdict would be dishonest. Both families are good enough that the deciding factors are in your system, not in theirs.
If you are choosing right now and want a second opinion that is not selling you a migration: book a free 30-minute call. We will look at your output contract, your volume and your existing stack, and tell you which way we would go. If the answer is stay where you are, you will hear that.
Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.
Top comments (0)