Sources checked: October 6, 2026. An impressive AI demonstration can arrive weeks or months before a dependable production release. For readers, developers, and editors, the useful question is not simply whether a model has been announced. It is which version is available, through which product, under which conditions, and what evidence supports that status.
This guide shows how to build a release-status timeline that separates an announcement, preview access, a stable release, and later retirement. It uses current primary documentation and a documented historical example. The tracking method is an editorial recommendation; it is not a claim that every AI provider follows the same lifecycle.
What preview and general availability mean
Start with the provider's definition. Google Cloud describes preview offerings as suitable for customer testing, with no default service-level or support commitments, while general availability describes production-ready offerings with applicable support and service-level coverage. These are Google Cloud definitions, not universal promises about every AI service. See its product launch stages.
The Gemini API documentation makes a different practical distinction: stable, preview, latest, and experimental model versions. Its model guide says preview versions may be used for production, while experimental versions are generally unsuitable for production. A latest alias can point to different release types. Check the official model version definitions before interpreting a model name.
The editorial lesson is to preserve the provider's terminology. Do not convert “public preview” into “generally available” because access is open or billing is enabled. Similarly, describe a stable model as stable unless the provider explicitly uses GA for that release. A status label tells part of the story; access restrictions and operational readiness need their own checks.
Identify the exact release you are tracking
Create one record for one identifiable release. Record the provider, product surface, exact model identifier, region when relevant, and feature under discussion. “The new model is live” is too broad to verify. “The named model identifier is listed as preview in this API's catalog” is narrow enough for another editor to reproduce.
A consumer chatbot, developer API, enterprise workspace, and cloud marketplace integration can expose related capabilities on different schedules. Avoid treating access through one surface as proof of access through all surfaces. Likewise, a text endpoint becoming stable does not automatically establish the lifecycle stage of a separate speech, image, or live interaction endpoint.
Keep aliases separate from fixed identifiers. An alias is convenient for a user but can change what version a request reaches. In your tracking sheet, reserve fields for the requested identifier and any resolved version disclosed by the provider. If the resolved version is not observable, write “not disclosed” rather than inferring it from the quality of an answer.
For a hands-on integration workflow, see our Gemini API and AI Studio guide. Use this release timeline alongside implementation testing, because lifecycle evidence and application behavior answer different questions.
Collect evidence in the right order
Start with dated official release notes or an announcement. Capture the event date, the exact lifecycle language, the affected identifier, and the source URL. A publication date identifies when the provider communicated a change. It does not necessarily identify when your account first received access.
Next, check the current model catalog and product documentation. These help establish today's documented state. Then review access requirements, pricing, supported locations, quotas, and lifecycle notices as applicable. A pricing entry can establish billing information without proving a transition from preview to GA.
If you can test access with an authorized account, record that observation separately. A successful minimal request establishes that this account reached this endpoint at this time. It cannot establish access for all users, regions, or subscription tiers. An unsuccessful request also has several possible causes, including account permissions, invalid configuration, quota exhaustion, or an unavailable endpoint.
Keep your evidence packet small enough to review: a release-note link, a current documentation link, a relevant lifecycle link, and an optional redacted access result. Never place API keys or private customer inputs in a public evidence packet. Save a short excerpt or internal snapshot with the observation time so later edits do not erase your reasoning.
Build a release-status timeline
Use an append-only event table. When the state changes, add a row instead of overwriting the previous state. This preserves the distinction between what was announced previously and what is documented now. The following blank template works in Excel, a shared document, or an editorial database.
| Field | What to record | Why it matters |
|---|---|---|
| Event date | Date stated by the provider, or unknown | Orders documented changes |
| Observed at | Your review date, time, and timezone | Shows when the evidence was checked |
| Release identity | Provider, surface, identifier, and feature | Prevents unrelated releases being combined |
| Provider status | Exact lifecycle label | Preserves the original meaning |
| Access scope | Documented plans, regions, or account limits | Qualifies availability claims |
| Evidence | Official URL and a short supporting note | Makes the claim auditable |
| Editorial conclusion | Confirmed, provisional, or unresolved | Separates evidence from interpretation |
Use “unknown” deliberately. If a documentation page shows a stable release but provides no transition date, record the date you observed that state. Do not present it as the launch date. If an announcement says access is rolling out, preserve that phrase and record any explicit scope instead of calculating an imagined completion date.
Set a clear promotion rule for your own coverage: a dated first-party source must explicitly establish the transition, and the current documentation must be consistent with that interpretation. If only one source supports it, publish the narrower supported claim and flag the remaining question. This is a recommended editorial rule, not a provider requirement.
A documented preview-to-stable example
The Gemini API release notes provide a useful historical sequence. On June 5, 2025, Google recorded a Gemini 2.5 Pro preview update. On June 17, it recorded the stable Gemini 2.5 Pro release. On June 26, it recorded redirects from specified older preview identifiers to the stable model.
| Documented date | Recorded event | Editorial interpretation |
|---|---|---|
| June 5, 2025 | A named Pro preview version released | Preview availability; not yet evidence of this stable transition |
| June 17, 2025 | Stable Gemini 2.5 Pro released | A dated stable-release milestone |
| June 26, 2025 | Specified older preview identifiers redirected | Migration behavior changed after the stable milestone |
This example is historical, not a recommendation to adopt that model today. Its value is the separation of a release event from subsequent routing changes. One family name can conceal several operational events, so a useful timeline tracks each event independently. Current deployment decisions require checking today's catalog and lifecycle notices.
Resolve conflicting availability signals
Suppose a hypothetical announcement calls a release generally available, but a catalog still labels the relevant endpoint preview. First check whether the sources describe the same identifier and product surface. A stable successor and an older preview endpoint can coexist, which creates an apparent contradiction without an actual disagreement.
If the identities match, record both sources, their dates, and the exact disagreement. Avoid silently selecting whichever wording sounds more exciting. Use qualified wording such as “The announcement describes the release as GA; the endpoint documentation still shows preview when checked.” Then recheck the documentation or seek clarification before claiming a resolved status.
Also distinguish entitlement from lifecycle. A model can retain its documented lifecycle label while your account lacks access. Conversely, working access does not promote a preview release to stable. Treat account observations as a separate column so they cannot accidentally override official lifecycle evidence.
Publish and maintain accurate updates
Write the headline only after completing the timeline. Include the exact product or model family where useful, and describe the verified event rather than the most dramatic possible interpretation. In the opening paragraph, explain the release stage, access scope, and evidence date. Put material limitations near the claim they qualify.
Link directly to the supporting primary documents. Internal links should help a reader take the next practical step, such as understanding an API workflow. An implementation guide can help readers test a service, but it should not be treated as independent evidence of a provider's release classification.
Recheck your record when the provider posts a release update, changes an identifier, announces retirement, or alters access documentation. During an active rollout, assign an editor a specific next review date. Afterward, choose a maintenance interval based on reader impact. These intervals are editorial choices, so do not describe them as guaranteed provider schedules.
Keep a correction log when evidence changes. Explain what was corrected and which source supports it. Updating a checked-on date without actually reviewing the sources creates false freshness. A reliable article can openly retain a historical example while updating the current documentation checks surrounding it.
Frequently asked questions
Does public preview mean general availability?
No. Public access describes who can try an offering, while a lifecycle stage describes the provider's release classification. Use the provider's exact label and check the associated conditions rather than treating open access as a GA announcement.
Can a paid model still be in preview?
Yes. For example, Gemini's model documentation says preview versions typically have billing enabled. Payment establishes a commercial condition; it does not by itself establish a stable or generally available release.
Does a successful API request prove worldwide availability?
No. It proves access under the tested account and request conditions at the observed time. Record the region, product surface, and account scope when relevant, and verify broader availability in official documentation.
What if the stable release date is missing?
Record the date you observed the stable label and mark the transition date unknown. Look for dated release notes, but do not infer a launch date from a screenshot, an edited page timestamp, or your first successful request.
Should a timeline stop at general availability?
No. Continue tracking relevant replacements, redirects, deprecations, and shutdowns. A release that was suitable previously may no longer be the appropriate endpoint for a new project. Keep historical events while making today's status easy to find.
