Preview vs GA AI Models: What the Labels Mean
Preview, beta, experimental, GA. The labels on a model release are commitments about what the vendor may change without warning. Here is what each one buys you.
When a lab ships a model tagged preview, experimental, or beta, it is not making a statement about quality. It is making a statement about obligation. A preview model can change its behaviour, its price, or its existence with little or no notice. A generally available model, usually written GA, comes with a deprecation policy and a notice period.
That is the difference in one sentence. Both labels can sit on a model that produces excellent output. Only one of them is a promise.
What each label actually commits the vendor to
The exact terms vary by provider, and the words are not standardised across the industry, which is why reading the specific provider's policy beats pattern-matching on the label. The general shape holds, though:
Label | Behaviour can change | Notice before removal | Price stability | Typically covered by SLA |
|---|---|---|---|---|
Experimental / research | Any time, silently | None promised | None | No |
Preview / beta | Any time, sometimes noted | Short or none | None | Usually not |
GA / stable | Only via a new version | Documented period | Held for the version | Yes |
Deprecated | Frozen | Announced end date | Held | Usually reduced |
The row that costs people money is "behaviour can change". A preview model that gets a quiet quality update overnight can break a prompt you spent two weeks tuning, and nothing in your monitoring will tell you why. Your inputs are the same, your code is the same, and your outputs are different.
Providers publish their commitments. Anthropic maintains a model deprecations page with retirement dates, and OpenAI publishes a deprecations list covering models and endpoints. Read the one for the model you are about to depend on, not the one for the vendor generally.
Why labs ship previews at all
Not as a marketing trick. A preview buys the lab three things: real traffic patterns that internal testing cannot produce, safety signal from adversarial users at scale, and the freedom to fix problems fast without breaking a stability promise. That last one is genuinely in your interest, because the alternative is a lab sitting on a fixable flaw for months to avoid violating a GA commitment.
It also means the preview period is when the model is most likely to improve. The version you tested in week one may be meaningfully better in week six, with no announcement and no version bump.
When building on a preview is defensible
The question is not whether the model is good. It is what breaks if the model changes tomorrow morning while you are asleep.
Reasonable on a preview:
Internal tools and prototypes. A human is in the loop, and a bad day is an annoyance rather than an incident.
Non-critical enrichment. The feature adds value when it works and degrades quietly when it does not. Tag suggestions, draft summaries, optional autocomplete.
Anything you are prepared to pin to a fallback in one line of config. If you can route to a GA model with a config change, the preview is a bet you can exit.
Hard to defend on a preview:
Anything a customer pays for directly. You are selling a promise the vendor has not made to you.
Anything in a compliance or contractual path. If you must document behaviour, you cannot build it on behaviour that may change without notice.
Anything where a silent quality change is invisible to you. If you have no eval running, you will find out from a customer.
How to build on a preview without getting hurt
Pin the most specific identifier available. Where the provider offers dated snapshots, use them rather than the floating alias. AI model version numbers, decoded covers how to read those strings.
Keep a GA fallback wired and tested. Not documented, wired. A fallback you have never exercised is a plan, not a fallback.
Run your eval on a schedule, not only on deploys. With a preview the model changes when you have not deployed anything, which is precisely the case a deploy-triggered check misses.
Watch cost per request, not just quality. Preview pricing is provisional, and previews sometimes go GA at a different price.
Set a review date. Put a calendar entry for the day you decide to either move to GA or accept the risk deliberately. Previews that drift into production without that decision are how teams end up surprised.
The transition is its own event
A model leaving preview is not a non-event, even though the label change sounds cosmetic. Pricing often changes, rate limits usually change, and the preview endpoint may stop accepting traffic on a date you have to find in a changelog. DeepSeek V4-Pro leaving preview is a worked example of that transition and what moved with it.
Treat the day a model you depend on goes GA as a small migration: check the pricing table, check the rate limits, re-run your eval against the GA identifier, then switch. It is a twenty-minute job when you plan it and a bad afternoon when you do not. If the transition is going the other way and your model is being retired, what to do when an AI model gets deprecated covers that path.
Keeping an eye on these transitions without reading every changelog is its own skill, and keeping up with AI news is the version of this problem that applies to everything else too.
Frequently asked questions
Is a preview model less capable than a GA model?
Often it is more capable, because it is newer. Preview describes the stability commitment, not the quality. The newest and strongest model a lab offers is frequently the one with the weakest guarantees attached.
Are preview models cheaper?
Sometimes, and sometimes free during the preview window. Treat introductory pricing as temporary. Budget on the assumption that the GA price is the real price.
Can a provider delete a preview model without warning?
The terms usually allow it. In practice, providers with large developer bases tend to give some notice even on previews, because breaking paying customers is expensive for them too. Do not build on that courtesy where the contract does not require it.
Should I tell my users I am using a preview model?
You do not need to name the model, but if its behaviour is user-visible and may change, saying so in your changelog is cheap insurance and good practice.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
