AI

How-To: How to Compare AI Model Release Pace (Step-by-Step)

How-To: How to Compare AI Model Release Pace (Step-by-Step)

You open a vendor notice and learn that the image model behind one of your tools is being retired in a few weeks. The replacement has a new name, a new price, and a version number that skips ahead. That is what AI release pace looks like from the user's side, and it is why counting launches from headlines tells you less than it seems. To compare AI model release pace across labs, you need four things. First, define what counts as a release. Second, fix one date rule and a rolling 12-month window. Third, log every qualifying release in a spreadsheet. Fourth, calculate median days between releases and between flagship replacements, then read those numbers next to shared benchmarks, API prices, and deprecation dates.

Plan on three to four hours to build a first comparison covering four or five labs, then about 15 minutes a week to keep it current. The difficulty is moderate. If you can write a COUNTIFS formula, you can do this.

At Verityadaily we publish daily breakdowns of model launches for Indian readers. After a heavy launch week, readers ask some version of the same question: are the labs shipping faster now? This is the method I use to answer it without guessing.

The short version

Release pace is comparable only when every lab is counted under the same rules. Separate flagship generations from variants, previews, and minor revisions. Date each release consistently, and use a rolling 12-month window for current pace. Report median intervals instead of averages. Publish a flagship-only count next to an all-release count, and keep deprecations in the same log, because a forced migration changes your work as much as a launch does.

What the headline numbers say, and what they hide

The AI Release Analytics tracker lists 253 major AI models from 11 labs. That is enough history to see a trend instead of a mood. Its year-by-year tallies climb from 22 major releases in 2023 to 58 in 2024 and 92 in 2025.

The growth rate tells a different story from the count. By my arithmetic, the first jump added 36 releases, roughly 164%. The second added 34, a rise of about 59%. So the count is still climbing, but the growth rate has already cooled by more than half. Both readings are true, and a single chart usually shows only one.

The tracker's own summary is a roughly 4.2-fold increase in monthly release rate between 2023 and 2025. Divide each year's count by the months it covers and you get about 1.8 releases a month in 2023, 4.8 in 2024, and 7.7 in 2025. The 2026 data runs through September 27, when the tracker had logged 80 major releases. That works out to nearly nine a month.

If you annualize that 2026 pace, you land somewhere around 107 releases for the year. Treat that as an extrapolation, not a reported figure. Launch schedules cluster around conferences and competitor announcements, and one quiet quarter would pull the number down fast.

Community discussion lines up with the tracker. On r/accelerate, readers describe the gap between major releases as shrinking quickly. Others in the same subreddit ask whether public launches lag behind capabilities the labs already run internally, and by how much. Both points belong in your framing: a release log measures what shipped, not what exists inside a lab.

The larger problem sits in the word "major." Every tracker makes judgment calls about which releases qualify. You cannot audit a headline count unless you can see those calls, which is why the steps below start with definitions rather than totals.

Before you start

Gather these before you open a blank sheet:

Step 1: Define what counts as a release

Write down your release categories before you count a single model. Every later number depends on this list, and changing it halfway through quietly breaks your comparison.

Five categories cover almost everything the major labs ship:

  1. Flagship generation: a new top-tier model that replaces its predecessor as the lab's headline offering.
  2. Family variant: a sibling model tuned for speed, cost, coding, audio, images, or agent tasks, usually sharing a generation label with the flagship.
  3. Minor revision: a dated snapshot or point update to an existing model.
  4. Preview: limited, experimental, or waitlisted access before general availability.
  5. Deployment change: a new region, an alias that moves to a newer snapshot, or an app integration. These add no new model.

Families are where most counts go wrong. I call the effect variant inflation. A lab ships a family of five models in one week, the all-release count jumps by five, and the frontier has moved once. OpenAI's current naming shows the pattern: gpt-6-astra, gpt-6-sol, and gpt-6-luna share a generation label but sit at very different price and capability points. Anthropic's split between Claude Opus and Claude Sonnet works the same way. If you count each sibling as equal to a new flagship, the lab that splits its lineup most finely looks like the fastest shipper.

Add a yes/no column called "flagship replacement" and decide it for every row. It is the single most useful field in the log.

Warning: Do not count alias moves as releases. When a "latest" endpoint starts pointing at a new snapshot, log it as a deployment change. Labs often publicize these moves, and treating them as launches is the fastest way to inflate one provider's pace.

Step 2: Fix your date rules and comparison window

Record two dates for every release, the announcement date and the general-availability date, and pick one as the date you use for pace. I use announcement dates for pace and availability dates for anything operational, such as when a vendor could realistically adopt the model.

Normalize time zones before you calculate intervals. Many US labs announce in the Pacific-time afternoon or evening, which is already the next calendar day in India. If half your log uses IST dates and half uses Pacific dates, some intervals will be off by a day. That sounds trivial until you are computing medians over a handful of flagship releases. Convert everything to UTC and note that in your methodology.

Next, choose the window. Calendar years are fine for history. For current pace, use a rolling 12-month window, because year-to-date figures mislead in a predictable way. The tracker's 80 releases through late September 2026 look smaller than 2025's 92. Per month, though, 2026 is running faster, at close to nine against 7.7. A reader who compares the raw totals concludes the reverse of what happened.

In Google Sheets or Excel, a rolling count for one provider looks like this:

=COUNTIFS(ProviderCol,"Anthropic",DateCol,">="&EDATE(TODAY(),-12))

Previews need a rule too. My recommendation is to count a model once, on the date it first becomes publicly usable, whether that is a public preview or general availability. Record the other date in its own column. Counting the preview and the GA as two releases double-counts labs that preview heavily, and some labs preview almost everything.

Release Growth, Two Ways: 253 major models tracked, 11 labs included, 22 releases in 2023, 58 releases in 2024, 92 releases i

Step 3: Build the release log

Create one row per release, with these columns:

Take the source link from the lab, not from press coverage. News write-ups often round context windows, drop tier conditions from prices, or describe a preview as a launch. When a figure changes later, which pricing does often, the primary link lets you check it in seconds.

Once the log covers the same period as your reference tracker, reconcile the two. Small gaps are normal, but explain them. The AI Release Analytics yearly counts, for example, add up to 252 (22 + 58 + 92 + 80), one short of the headline 253. That could be a model from before 2023, a late addition, or a classification call. It is the kind of discrepancy to ask a maintainer about before you publish a number built on it.

Maintenance is where most logs die. Checking eleven changelogs every morning is tedious. A daily news digest works as a trigger instead: if anything relevant shipped, you add the row and go to the primary source for the details. Our own The Daily Brief newsletter delivers the day's trending technology news each morning, which is enough to prompt a check. For a fuller routine, our guide to building an AI news workflow for daily briefings covers the setup. If Anthropic is one of your labs, the Claude news guide shows how its rollouts tend to be staged.

Step 4: Calculate the pace metrics

Compute four numbers per provider: total qualifying releases, releases per month or quarter, median days between releases, and median days between flagship replacements.

The first two are counts divided by time. The interval metrics take one more step. Sort each provider's rows by date, add a column that subtracts the previous row's date from the current one (=C3-C2), then run =MEDIAN() over that column. Repeat on a filtered view that shows only flagship replacements.

Use the median rather than the average, because release schedules are lumpy. Here is a hypothetical provider whose gaps between releases were 25, 28, 30, 31, and 180 days. The mean is about 59 days. The median is 30. One long quiet stretch doubled the average, while the typical wait stayed around a month. Clusters distort in the other direction: three launches in one week pull a mean down just as far.

Same-day family launches deserve a specific rule. If a lab ships four variants on one afternoon, your interval column fills with zeros and the median collapses toward nothing. For interval calculations, collapse same-day releases from one provider into a single event. Keep the individual rows for the all-release count.

The flagship interval is the number I would lead with if you only report one. It answers the question most readers mean when they ask about pace: how long until this lab's best model is replaced? Variant counts answer a different question, about how many options a lab ships. That matters for procurement but says little about the frontier.

Tip: Report the flagship interval with a sample size next to it, for example "median 96 days (n=4)." With only a handful of flagship replacements per lab, a single launch can move the median a lot, and readers deserve to know how thin the data is.

Step 5: Check release concentration

Calculate each provider's share of total releases in your window. If one lab accounts for half the log, your "industry pace" is mostly that lab's pace.

The simplest check divides each provider's count by the total. For a single summary number, use the Herfindahl-Hirschman Index, a standard concentration measure from antitrust economics. Square each provider's percentage share and add the results. Eleven labs with equal shares would score about 909 on the index's 10,000-point scale. A result far above that tells you a few providers dominate the sample.

Concentration matters because it changes what a rising total means. Suppose the count rose because one lab started splitting every generation into six variants. That is a different story from eleven labs each shipping a little faster, and a headline trend line cannot tell the two apart.

A useful habit is to report the aggregate pace twice, once with all providers and once without the single most prolific one. If the trend holds without the top lab, it is broad. If it flattens, you have learned something the total hid.

Step 6: Pair pace with benchmark progress

Release pace measures how often labs ship. It does not measure how much better the models get, so your comparison needs a capability column that works across providers. That is harder than it sounds.

A 2026 paper posted to arXiv, "Unsteady Metrics and Benchmarking Cultures of AI Model Builders," catalogued 231 benchmarks cited across 139 model releases from 11 builders. The spread is the problem. Almost two in three highlighted benchmarks appeared at only one builder, and 38.5% showed up in a single release and never again. When a lab introduces a new test with a new model and drops it at the next launch, you cannot use it to compare labs, or even two generations from the same lab.

The practical rule is to track only benchmarks that at least two of your providers report, and to flag everything else as provider-specific. That leaves a short list, and it should. A short list of shared benchmarks tells you more than a long list of numbers that cannot be compared.

Practitioners reach the same conclusion from the buyer's side. Users on r/LLMDevs looking for comparison tools say standard leaderboards are too narrow for choosing a model, and they want views that compare several metrics they choose themselves. Your log can do that: benchmark score, price, context window, latency, throughput, and rate limits, side by side.

One derived metric is worth adding: cost per benchmark point. Divide the blended API price by the model's score on a shared benchmark. A new flagship that scores two points higher at three times the price shows up as a regression on this measure, even though the launch coverage presents it as progress. Our AI benchmark guide explains how to read the underlying scores, and seven ways to spot misleading model claims covers the framing tricks that tend to come with a launch.

Step 7: Add price, and keep API and subscription prices apart

Record API prices per 1 million tokens, with input and output in separate columns, and never put them in the same column as consumer subscription prices. The two measure different things. An API price is a usage rate that varies by tier, context length, modality, caching, batch processing, and grounding. A subscription is a flat monthly fee for an app.

Here is how current list prices compare across the three largest providers:

Provider Model or tier Input per 1M tokens Output per 1M tokens Condition
OpenAI gpt-6-astra $20.00 $100.00 Standard
OpenAI gpt-6-sol $4.00 $20.00 Standard
OpenAI gpt-6-luna $0.20 $1.00 Standard
OpenAI gpt-5.3-codex $3.50 $28.00 Coding-oriented
Anthropic Claude Opus 5.5 $4.00 $20.00 Standard
Anthropic Claude Sonnet 5 $2.00 $10.00 Standard
Google Low-cost Gemini tier (example) $0.15 $1.25 Standard
Google Higher-capability Gemini tier $1.25 $10.00 Prompts up to 200,000 tokens
Google Higher-capability Gemini tier $2.50 $15.00 Prompts above 200,000 tokens

Two things stand out. First, a single OpenAI family spans a hundredfold range: astra's output rate is 100 times luna's, and the same ratio holds for input. That is variant inflation in price form, and it is why a count that treats every family member equally misleads. Second, gpt-6-sol and Claude Opus 5.5 carry identical list prices, according to OpenAI's pricing page and Anthropic's. So price alone will not separate those two. Shared benchmarks have to.

Conditions change the effective rate. Eligible regional-processing endpoints can add a 10% uplift for models released on or after March 5, 2026 (OpenAI, 2026). A release date can therefore change what the same workload costs. Google's higher-capability tier doubles its input rate once prompts pass 200,000 tokens, so a long-document workload pays a different price from a chat workload on the same model. Grounding adds its own line item: Google charges $14 per 1,000 requests for Gemini 3 Search grounding once the free monthly allowance runs out.

Subscriptions belong in their own section of the log. Claude Max starts at $100 a month, and Anthropic describes its Max 5x and Max 20x tiers by usage multiples of Pro, five and twenty times respectively, per its plans page. That tells you nothing about per-token API cost, so do not convert one into the other.

Step 8: Log deprecations next to launches

Add every announced deprecation and shutdown date to the same log, with the recommended replacement model. From an operational point of view, pace is how often you are forced to change, not only how often a lab launches.

A current example: Google has scheduled Gemini 2.5 Flash Image to shut down on October 2, 2026, and recommends migrating to Gemini 3.1 Flash Image or Gemini 3.1 Flash Lite Image. That migration is not a new generation. For anyone whose workflow depends on the old model, it is still a deadline with testing attached.

I call this the forced-change calendar: the dates on which some workload must move whether or not you wanted a new model. To turn it into a comparable metric

Related Reading

The Daily Brief A daily email newsletter delivering the day's trending technology, cryptocurrency, and finance news every morning.

Explore The Daily Brief

Stay ahead. For daily AI, crypto, finance & tech coverage you can trust, Veritya Daily has you covered.