Claude vs GPT vs Gemini for Business in 2026: Compare the Retirement Clocks, Not the Benchmarks

Every model comparison is a photograph of a moving object. The useful question for a business is not which model scores highest this quarter; it is which vendor will give you enough warning when the model you built on is switched off. That answer is published, it is different at all three vendors, and it does not appear in any of the comparison articles currently ranking for this question.

This guide gives the current model IDs and prices as of August 2026, then the part that outlives them: the three vendors’ published lifecycle policies side by side, the platform split that quietly changes your dates, and the token-accounting change that makes headline prices misleading. It ends with a portability checklist you can work through this week. Model selection is one decision in a larger stack — the AI for commerce teams guide hub covers the rest.

Contents

• What the current models actually are, as of August 2026
• Why a model comparison expires before the integration does
• What each vendor promises before it switches a model off
• Notice period and planning horizon are two different guarantees
• The same model can be retired on one platform and running on another
• Why per-token prices are not comparable across model generations
• What the three families cost today
• Matching a commerce workload to a model tier
• The portability checklist
• How to audit your own exposure this week
• When this framing does not apply

What the current models actually are, as of August 2026

Three families are current. Anthropic lists claude-opus-5, claude-sonnet-5 and claude-haiku-4-5-20251001 as active, alongside claude-fable-5 as its most capable widely released model. OpenAI’s current flagship series is GPT-5.6, in three tiers: gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna. Google lists gemini-3.6-flash, gemini-3.5-flash, gemini-3.5-flash-lite and gemini-3.1-flash-lite as generally available.

Two spec facts matter more than any ranking. Anthropic documents a 1M-token context window on Claude Fable 5, Opus 5 and Sonnet 5, and 200k on Haiku 4.5. OpenAI documents 1.05M tokens across the GPT-5.6 tiers. Those numbers decide which jobs are possible at all; benchmark positions decide which are marginally better.

Names carry no version information, which is the first practical trap. gpt-4o is still listed and still sold at $2.50 per million input tokens, but the gpt-4o-2024-05-13 snapshot underneath it was deprecated on 22 April 2026 with a shutdown date of 23 October 2026. A dated snapshot ID and an undated family name behave differently under a deprecation, and only one of them is safe to hard-code.

Why a model comparison expires before the integration does

An integration written against a model outlives the comparison that chose it, usually by years. The comparison rots first, and it rots on a schedule the vendors publish in advance.

The dates are specific. Google lists gemini-2.0-flash, released 5 February 2025, with a shutdown date of 1 June 2026, and gemini-2.0-flash-lite, released 25 February 2025, on the same shutdown date. Anthropic records claude-sonnet-4-20250514 and claude-opus-4-20250514 as deprecated on 14 April 2026 and retired on 15 June 2026. Any article published in June 2026 recommending “Gemini 2.0” or “Claude 4” was recommending endpoints that had already stopped answering, or were days from it.

This is not a criticism of the vendors, who published every one of those dates ahead of time. It is a statement about what a comparison can and cannot carry. A capability verdict is true for a quarter. A lifecycle policy is true for the life of the contract, and it is the thing that determines whether a shutdown is a scheduled afternoon of work or an outage. Treat the model choice as reversible and the vendor choice as the commitment.

What each vendor promises before it switches a model off

All three publish a deprecation policy, and they are not equivalent. The table below is assembled from the three vendors’ own documentation pages, checked 11 August 2026. Read it as the contract you are signing, because it is the part of the choice that does not change next quarter.

Verdict: OpenAI gives the longest guaranteed reaction window on generally available models and the shortest on preview ones, so the safety of an OpenAI build depends entirely on which tier you pinned. Anthropic gives the shortest stated guarantee of the two vendors that commit to one, but it is the only vendor of the three that publishes both a guaranteed notice period and a forward-looking earliest-retirement date. Google publishes dates without committing to a notice period, so its planning horizon is good and its floor is undefined.

Notice period and planning horizon are two different guarantees

A notice period and a planning horizon answer different questions, and most teams conflate them. The notice period tells you how long you get to react once the announcement lands. The planning horizon tells you, today, the earliest date a model you are already running could disappear. You need both, and no vendor’s marketing frames it this way.

Anthropic’s page states the reaction guarantee directly: it notifies customers with active deployments “at least 60 days” before retirement for publicly released models. Its status table simultaneously supplies the planning horizon, listing tentative retirement dates such as “Not sooner than July 24, 2027” against models that are currently active.

Google inverts the pair. Its deprecations page publishes dated shutdowns well ahead of time but states that those dates “indicate the earliest possible dates on which a model might be retired” and that the exact date will be communicated “with advance notice” — no floor attached. You can plan against the table; you cannot size a migration sprint against the guarantee, because there is not one.

OpenAI supplies the strongest floor and the weakest horizon: at least 6 months for generally available models, but the deprecations page lists models once they are already deprecated rather than publishing an earliest date for those still current. In practice that means an OpenAI build is safe to plan in half-year increments and impossible to plan beyond them.

The same model can be retired on one platform and running on another

Where you buy the model changes when it disappears. Anthropic’s deprecation page states this explicitly: its dates apply to Anthropic-operated platforms, while “partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model’s lifecycle status and dates can differ.”

AWS says the same thing from the other side. Its Bedrock model lifecycle page notes that dates there “are specific to Amazon Bedrock and may differ from dates published by model providers (such as Anthropic or Cohere)”, and that for Bedrock usage “only the dates on this page apply”. Both vendors are telling you the same thing: there is no single retirement date for a model, only a retirement date per platform.

The gap is measurable. Anthropic records claude-sonnet-4-20250514 as retired on its own API on 15 June 2026. AWS lists anthropic.claude-sonnet-4-20250514-v1:0 on Bedrock with a Legacy date of 14 April 2026 and an end-of-life date of 14 October 2026 — four months of additional life for an identical model, published by both parties, reconciled by neither.

The platform guarantees differ in structure too, not just in dates. Bedrock commits that a model “will remain on Amazon Bedrock for at least 12 months before the EOL date” and that it “will be in the Legacy state for at least 6 months before the EOL date” — a longer floor than the model provider’s own 60 days. It also adds a stage that has no first-party equivalent: after at least three months in Legacy, a model enters public extended access, where AWS states you “should expect higher pricing, which will be set by the model provider”. A retirement is not always a cliff. Sometimes it is a price rise you have to notice on an invoice.

This breaks the standard ecosystem advice, which says to pick the model your cloud already carries and stop thinking about it. Picking the cloud is not a neutral convenience choice; it silently reassigns the retirement date that governs your integration, in either direction. A team on a partner cloud can outlive the first-party retirement by a third of a year, and a team that migrates from a partner cloud to the first-party API can inherit an earlier shutdown than the one it planned against. Read the lifecycle table for the platform you actually bill through, not the one the model was announced on.

Why per-token prices are not comparable across model generations

A price per million tokens only means something if a token is the same size on both sides of the comparison. Anthropic documents that this stopped being true within its own lineup: Claude 4.7 and later models “use a newer tokenizer” that “produces approximately 30% more tokens for the same text”, with the exact increase depending on content and workload shape.

Work the arithmetic on a fixed document rather than on a rate card. A body of text that costs 1,000,000 tokens under the older tokenizer costs roughly 1,300,000 under the newer one. At an identical headline rate of $5 per million input tokens, the same document moves from $5.00 to about $6.50 — a 30% increase in the invoice with no change in the advertised price. Comparisons that rank vendors by rate card alone will get this backwards whenever a tokenizer changes underneath one of them.

The correction is to price the workload, not the rate. Take a representative sample of your real inputs — 50 support tickets, 50 product descriptions, whatever the job actually is — send them through each candidate model’s token counting endpoint, and multiply actual token counts by current rates. That is the only comparison that survives a tokenizer change, and it takes an afternoon.

What the three families cost today

Published list prices as of 11 August 2026, per million tokens, from each vendor’s own pricing page. These are the most volatile numbers in this guide; re-check them before you commit a budget.

Verdict: the low tiers are not within rounding distance of each other — GPT-5.6 Luna’s input rate is a fifth of Claude Haiku 4.5’s — so high-volume classification work is worth pricing properly rather than defaulting. The row that changes architecture, though, is the last one.

Google is the only one of the three that bills cached context by time as well as by token. Deriving from its published rate of $1.00 per million tokens per hour: a 200,000-token cached system prompt held continuously costs $0.20 per hour, or about $4.80 per day, whether or not a single request arrives. Anthropic and OpenAI charge a one-off write multiplier instead, so an idle cache costs nothing. For a support assistant with a large fixed prompt and bursty overnight traffic, that difference decides the design — on Google you cache around traffic windows, on the other two you cache and forget.

Matching a commerce workload to a model tier

Match the tier to the shape of the job, using documented specs rather than benchmark position. Four workload shapes cover most commerce and ERP work.

• High-volume, low-judgement classification — order tagging, refund-reason coding, product categorisation. Lowest tier, batched. Anthropic’s Batch API takes 50% off both input and output; price the batch rate, not the standard one.
• Large fixed prompt, many small requests — a support drafting assistant carrying a policy document on every call. Caching-dominated, so the caching shape in the table above matters more than the base rate.
• Whole-document reasoning — reconciling a long statement against ERP records, or reviewing a full contract. Context-window bound: Claude Fable 5, Opus 5 and Sonnet 5 document 1M tokens and the GPT-5.6 tiers document 1.05M, which decides feasibility before cost does.
• Anything writing to a system of record — creating sales orders, adjusting inventory, issuing refunds. Model choice is secondary here; the governance limits of the receiving system dominate, as covered in the guide to calling AI APIs from SuiteScript.

What deliberately is not in that list is a capability ranking. Benchmark scores for these families move monthly, are measured on tasks that rarely resemble order reconciliation, and cannot be verified from a vendor’s own documentation. Context window, price, batch discount and caching behaviour are all documented and stable enough to design against. Build on the documented numbers and treat capability as something you measure on your own inputs.

The portability checklist

Portability is what converts a retirement announcement from an incident into a ticket. Work down this list once, and the next shutdown costs an afternoon.

• Pin an exact model ID in configuration, never a floating family name, so a silent substitution cannot change behaviour underneath you.
• Keep the model ID in environment configuration rather than in code, so switching it is a deploy and not a release.
• Route every model call through one internal interface — one function, one module — so the provider-specific request shape exists in exactly one file.
• Record which platform issues the credential for each workload, because the retirement date follows the platform and not the model.
• Diary the published retirement or earliest-shutdown date for every model ID you run, and set the reminder before the vendor’s notice period would start.
• Keep a stored set of representative inputs and expected outputs, so a replacement model can be evaluated the day it is announced rather than the week it is forced.
• Subscribe the on-call address, not an individual’s inbox, to each vendor’s deprecation notifications.
• Confirm no prompt depends on an undocumented quirk of one model, since that is the dependency a migration discovers last.

How to audit your own exposure this week

Two hours of work establishes whether a model retirement would be routine or disruptive. The audit is mechanical and needs no vendor contact.

Start by listing every model ID actually in production, taken from usage exports rather than from the codebase — Anthropic’s Console, for instance, exports usage broken down by API key and model, which surfaces the forgotten script that no repository search finds. Then, for each ID, open the vendor’s deprecation page and record its current state and its published retirement or earliest-shutdown date. Finally, note which platform bills each workload, and check that platform’s own lifecycle table rather than the vendor’s headline one.

The output is a short table: model ID, platform, lifecycle state, published date, owner. Anything with a date inside twelve months gets a migration ticket now; anything with no published date at all is the higher risk, because it is the case where the vendor’s committed notice period is the only warning you will get. Teams that keep this table treat model retirements as maintenance. Teams that do not, discover them from a 404 in production.

When this framing does not apply

Lifecycle discipline is overhead, and three situations do not justify it. If the only use is a person typing into a chat interface, there is no integration to break — the vendor swaps the model underneath and the work continues. If the deployment is a genuine prototype with a decision date inside a quarter, pin nothing and pick on capability, because the project will be rewritten or cancelled before any retirement lands.

The third exception is the interesting one. If the model is reached through a tool someone else built, the retirement risk is that vendor’s to manage and yours to inherit without notice, which is a different exposure than the one described here and is examined in the analysis of what sits behind AI-powered SaaS tools.

Everywhere else — anything on a schedule, anything writing to an ERP, anything a customer touches — the retirement clock is the governing constraint. The same reasoning applies one layer down to the protocols these models speak, where a revision can remove a mechanism entirely rather than just a model, as happened to session handling in the Model Context Protocol specification. If you want this designed once and handed over rather than assembled in-house, that is the integration work we do.

Frequently asked questions

Related guides

• AI Invoice Reconciliation in NetSuite: A SuiteScript Pattern That Scales Past 10,000 Invoices a Month
• How AI Is Reshaping E-Commerce Integrations: Why a Model in the Data Path Breaks Retry
• LLMs Inside ERP: How AI Language Models Are Being Used in NetSuite Workflows in 2026