What Sources Does the Index Use to Verify Model Release Dates?

A model’s release date sounds like a simple fact. In practice, it can mean several different things: when a company announced a model, when customers could first use it, when an API began accepting requests, or when an updated model identifier appeared in documentation. Those dates may not match.

That distinction matters to anyone comparing model versions or deciding whether to upgrade. An announcement date tells you when a lab made news. A verified availability date helps answer when a model could actually be used. A well-maintained model index should preserve both rather than choosing one and treating it as the whole story.

For Suprmind Data Lab, verification means recording the evidence behind a date, not just collecting dates from headlines. The most useful evidence usually comes from primary sources: lab announcements, API changelogs, official documentation, and other records published by the model provider. Independent sources can help confirm context, but they should not quietly replace the underlying evidence.

Why One Release Can Have More Than One Date

Labs do not all release models in the same way. A model might be announced in a blog post, made available to a limited set of customers, added to an API, and rolled out more broadly over several days or weeks. Some providers publish a dated changelog. Others update a model catalog without saying exactly when each customer gained access.

For that reason, a useful index separates at least two concepts:

• Announced date: when the lab publicly described or introduced the model.
• Verified availability date: the earliest date supported by evidence that users could access the model through a stated route, such as an API, product, or downloadable release.

In some cases, the evidence supports only an announcement date. That is still valuable, as long as the index labels it accurately. “Announced on” should not be rewritten as “available on” unless there is evidence of availability. If the exact first-access date is unclear, the responsible answer is “not verified,” not a more precise-looking guess.

The Source Hierarchy

Sources are not equally strong for every question. An official launch post is usually strong evidence for what a lab announced, but it may not establish when an API endpoint became usable. An API changelog can be better evidence for API availability, but may not explain a gradual product rollout. The index evaluates sources according to the claim being verified.

Source type What it can verify What to watch for Official lab announcement Model name, announcement date, stated capabilities, intended availability “Coming soon” or “rolling out” is not proof of broad access that day API changelog or model catalog API identifiers, documented access, deprecations, and dated changes A current catalog may not show when an entry was first added Official product documentation Product access, usage instructions, plan limits, and regional details Documentation can be updated after the initial release Provider repository or model card Weights, code, configuration, license, or a downloadable release A repository timestamp may reflect a later edit, mirror, or commit Independent reporting Additional context, corroboration, or a documented access observation Reports may repeat an announcement without independently checking access

Primary Sources Come First

The first stop is the lab’s own record. For OpenAI, Anthropic, and other providers, that can include official announcements, API changelogs, documentation pages, and model catalogs. These sources are the most direct way to establish what the lab said and when it said it.

“Primary source” does not mean “complete source.” A launch post can confirm that a model was announced on a given date while leaving the actual rollout schedule vague. An API changelog may identify a model name but omit whether access was available to every account, only to selected customers, or only in particular regions. The index should preserve those limits in its notes.

When a source is changed after publication, date verification also becomes a recordkeeping problem. A current documentation page may show a model that was not present on the day it was first published. Useful supporting evidence can include dated changelog entries, archived copies, repository commit history, and contemporaneous official posts. These materials help distinguish an original release record from a later edit.

Announcements and API Changelogs Answer Different Questions

Lab announcements are best for confirming an announcement. API changelogs are often more useful for confirming API changes. Neither source should be stretched beyond what it says.

For example, if an announcement says a model will “begin rolling out today,” that establishes the start of a rollout, not necessarily universal access. If the API changelog lists a model identifier on a later date, that can support an API availability date. The index can record both dates and state which one it uses for each comparison.

This is especially important when comparing release cadence across labs. A company that announces models early and rolls them out gradually may appear more active than one that waits to announce until access is broadly available. Using the same date definition across providers reduces that distortion.

How Secondary Sources Fit In

Secondary sources are useful for corroboration, particularly when an official page has changed or the rollout was not documented clearly. Credible reporting, dated technical analyses, and archived observations can help narrow down when a model became accessible. But a secondary source should be labeled as such, and the index should identify what it top AI model release tracker actually supports.

A report that repeats a lab’s launch post is not independent confirmation of availability. A report that documents successful API access on a specific date is more relevant to an availability claim, though it may still reflect one account, one region, or one access tier. The method should state that limitation rather than implying a universal rollout.

Consider a pricing example: “Reported about 40% higher cost than GPT-5.1” for GPT-5.2 should be labeled as a lab claim with a secondary source, not presented as an independently verified universal price comparison. The index should retain the source, the date checked, the units or pricing basis if available, and any scope limits. “Higher cost” could refer to a particular usage scenario or pricing measure; without that context, the comparison is easy to misread.

What Counts as Verification?

Verification is not a claim that every customer had access everywhere at the same moment. It is a documented judgment that the available evidence supports a particular date and a particular type of release. A practical verification record includes:

• The model name and any official API or product identifier.
• The date and time, when available, of the source being cited.
• The source type, such as an official announcement, API changelog, or independent report.
• The event the date represents: announcement, API availability, product rollout, or open-weight publication.
• Any known scope limits, including access tiers, regions, or staged rollout language.
• A confidence note when the evidence is incomplete or sources conflict.

Keeping these fields separate makes later corrections easier. If a lab updates a changelog or clarifies that an earlier release was limited, the index can amend the relevant claim without erasing the original announcement date.

Benchmarks Are Not Release-Date Evidence

Performance results can tell you something about a model. They do not, by themselves, verify when that model new AI models was released. This distinction matters because launch coverage often combines a date, a benchmark score, and a broad claim that the new version is better. Those are three different claims, and they need different evidence.

Launch benchmarks are typically selected and reported by the lab. They can be useful for understanding what the provider wants to demonstrate, but they are not the same as independent evidence of day-to-day preference. Results depend on the task set, prompts, scoring method, model settings, and comparison versions. A benchmark result should be read with its methodology and date, not treated as a universal ranking.

Blind-vote preference data answers a different question. LMArena, formerly LMSYS Chatbot Arena, collects comparisons in which people choose between model responses without initially seeing which model produced each answer. Its text leaderboard with style control is a useful reference for comparing preference outcomes while accounting for response style. The Hugging Face dataset lmarena-ai/leaderboard-dataset can provide a route to inspect related leaderboard data and its recorded fields.

That makes Arena-style data relevant to model evaluation, not to release-date verification. A leaderboard result may help teams ask whether users preferred one model’s responses under a particular setup. It cannot establish when the lab announced the model or when a specific customer first had access. Those dates still need primary-source evidence or clearly labeled corroboration.

Why This Matters for Upgrade Decisions

Teams rarely upgrade just because a version number changed. They need to know what changed in daily use: quality on their tasks, latency, reliability, tool use, context handling, price, and compatibility. Release dates help establish the timeline, but they are not an endorsement of the new version.

A new model may improve on some tasks and regress on others. It may produce stronger reasoning but follow a preferred format less consistently. It may be cheaper for one workload and more expensive for another. A benchmark can surface a promising difference, while blind preference data can reveal how responses are received in paired comparisons; neither replaces testing against a team’s own prompts and constraints.

A date index is most useful when it lets teams connect evidence over time: the announcement, the first documented API availability, the later pricing or deprecation change, and any evaluation results. That timeline can prevent a common mistake: attributing a change in behavior to a model version when the actual cause was a prompt update, a provider-side routing change, or a configuration difference.

Release Cadence Across Labs

Release cadence comparisons are only fair when the dates mean the same thing. One lab may publish frequent small model updates. Another may bundle changes into fewer named releases. A third may offer a model in a product before exposing a stable API identifier. Counting announcements alone can make these patterns look more comparable than they are.

A careful index can report cadence in more than one way: time between public announcements, time between verified API releases, or time between major documented changes. These measures answer different questions. They also help teams plan evaluations. A fast cadence may mean more opportunities to adopt improvements, but it can also mean more version tracking and regression testing.

For upgrade planning, the useful question is not simply “Which lab shipped more models?” It is “How often did the capabilities or interfaces we depend on change, and how much verification work did each change require?” Reliable dates make that analysis possible without mistaking publicity frequency for usable release frequency.

A Practical Checklist for Reading the Index

1. Check the date label. Is it an announcement date, an API availability date, or a product rollout date?
2. Open the cited source. Prefer the original lab announcement, API changelog, or documentation entry where possible.
3. Read the wording. “Announced,” “starting to roll out,” and “generally available” do not mean the same thing.
4. Look for scope. Note access tiers, regions, staged rollouts, and whether the evidence concerns an API or a consumer product.
5. Separate release facts from evaluation results. Leaderboards and benchmarks can inform testing, but they do not verify release dates.
6. Track uncertainty. If the evidence supports only a date range or an announcement date, the index should say so.

The Short Answer

The index should use primary sources first: lab announcements, API changelogs, official model documentation, and release records. It should use secondary sources to corroborate or clarify, with their role clearly labeled. Most importantly, it should distinguish announced dates from verified availability dates and avoid implying broader access than the evidence supports.

That discipline is useful beyond keeping a timeline tidy. It gives teams a better basis for comparing release cadence across labs, interpreting evaluations, investigating regressions, and deciding when an upgrade is worth the retest. Dates are small data points. The evidence and definitions behind them are what make those data points useful.