Version Numbers Are a Marketing Decision, Not a Technical One

There is no regulator of model version numbers. No standards body signs off before a lab calls its next release '2.0' instead of '1.6,' and nothing stops two companies from using the exact same numbering convention to mean completely different magnitudes of change. A point release from one lab can represent a bigger architectural shift than a full version bump from another. This is not a flaw in the system. There is no system. The number on a model release is chosen the same way a chapter title is chosen: to tell a story about significance, not to report a measurement of it.

That is worth saying plainly because most of us default to reading version numbers the way we read software we grew up with, where a major version bump reliably meant breaking changes and a point release reliably meant a bug fix. Model releases borrow that visual language without being bound by its rules. At GLSRM, we treat a version number as a claim the lab is making about how its release should be perceived, and then we go verify the claim separately, the same way we would treat a headline.

Semantic Versioning Was Never a Promise

Software engineers built semantic versioning to solve a specific coordination problem: when you depend on somebody else's code, you need to know, before you upgrade, whether the new version will break your integration. A major version bump promised breaking changes, a minor bump promised new functionality without breaking anything, and a patch promised nothing but bug fixes. That system worked because it was a contract, and violating it had real consequences for developers who relied on it. Model releases adopted the same numbers without adopting the same contract. Nothing enforces that a lab's 3.0 represents a bigger leap than its 2.4 did, or that its minor releases are actually minor in scope. The digits look like the software convention you already trust. They are not bound by it.

This matters because the visual grammar does a lot of unpaid persuasive work. A jump from 1 to 2 reads as a generational leap almost regardless of what actually changed, simply because that is the pattern our brains learned from decades of software we used before AI models existed. A lab does not need to argue that a release is a big deal if the version number already makes the argument on its behalf. That is not necessarily manipulative, sometimes the number genuinely tracks a big change, but the number itself is never sufficient evidence of that on its own, and treating it as sufficient evidence is where a lot of the industry's benchmark-adjacent confusion actually starts.

It is worth noticing that much of the software world has been quietly moving away from visible version numbers altogether. Browsers update themselves silently in the background. Phone operating systems increasingly present updates as a vague seasonal release rather than a numbered milestone most users could recall. AI labs, by contrast, have leaned into version numbers precisely because a number is a convenient hook for a story, a moment worth a keynote, a headline worth writing. That is a deliberate choice in an industry that could easily have followed the rest of software toward invisible, continuous updates, and the persistence of the version number in AI releases tells you something about how much labs want each release to be an event, not just an improvement.

The Same Number Means Different Things Across Labs

There is no cross-industry agreement about what a major version is even supposed to represent, which means the number is not just uninformative in isolation, it is not comparable across companies either. One lab might reserve a full version bump for a genuine new pretraining run and treat everything else as a point release, applying that rule with real internal discipline release after release. Another might call a substantial fine-tuning pass a major version simply because enough time has passed since the last big number and the marketing calendar wants a headline moment. Both practices are internally consistent with whatever convention that particular lab has chosen, and neither owes the other any consistency at all. A reader comparing one lab's version three against a rival's version three, on the assumption that the numbers mean roughly the same thing, is comparing two words that happen to be spelled the same way in two different languages.

This is why the most useful version-number literacy is not general, it is lab-specific. Watching how a particular lab has used its own numbering scheme over several releases, whether its major bumps have historically tracked real architectural change or mostly tracked marketing timing, builds a far more reliable prior than any industry-wide rule of thumb ever could. A lab that has been disciplined about reserving big numbers for big technical changes earns the benefit of the doubt on its next major release. A lab that has previously shipped a major version that turned out to be a fine-tuning pass with a new name has taught you, fairly, to discount its next one until the change list proves otherwise.

Why Labs Skip Numbers, Reset Numbers, and Avoid Numbers Entirely

Watch for the skipped number, where a lab jumps from version two straight to version four with no three in between. Sometimes that reflects a genuine internal versioning history that never shipped a public three. More often it is a deliberate choice to avoid inviting a direct sequential comparison, either against a rival who just shipped their own version three and would otherwise look like they are one step ahead, or against the lab's own previous release, if skipping a number implies a bigger leap than incrementing by one would suggest. A number is a rhetorical device before it is an accounting record, and skipping one is one of the cheapest ways to manufacture the impression of a bigger jump.

Renaming and resetting serve a related purpose after a release that landed badly. If a version number becomes associated with a rocky launch, a wave of bad press, or a capability that turned out to be overstated, restarting the naming scheme entirely, sometimes with a new codename or a new product family name altogether, gives a lab a clean slate without technically claiming a discontinuity in its research. Codenames themselves are the most flexible tool of all: announcing a model under an internal project name defers the numbering decision until the lab has a clearer read on how the release is landing, which means the eventual version number can be chosen partly in response to public reaction rather than fixed in advance.

Point releases get the opposite treatment for a related reason: a lab with a steady cadence of small, frequent point updates is making an implicit claim about its own operational maturity, the sense of a team that ships continuously rather than one lurching between infrequent, high-drama launches. That cadence is itself a form of marketing, even when every individual point release is a modest, honestly labeled improvement. A steady drumbeat of small numbered updates tells a story about reliability and momentum that a single enormous version bump six months later cannot tell on its own, regardless of which path actually shipped more real capability over the same period. Numbering strategy is not just about any single release, it is about the shape of the whole release history a lab wants you to perceive.

Sometimes the Number Is Deliberately Modest

The manipulation is not always in the inflating direction. Sometimes a lab underplays a release deliberately, labeling a meaningfully improved model as a minor point update rather than a full version, precisely because a major version label invites a different kind of scrutiny: higher expectations, more aggressive comparison against every competitor's flagship, and a higher bar for what counts as disappointing. A modest label can be a way of shipping real improvement while keeping the conversation calm, letting the model's reputation build gradually through use rather than through a single high-stakes launch moment that critics are primed to pick apart.

Picture two hypothetical scenarios that produce the same underlying magnitude of improvement. In one, a lab calls it a major version, leads with a keynote, and invites every competitor's flagship into the comparison chart. In the other, a lab quietly ships the same magnitude of change as a point release with a short blog post, and lets the model's reputation build through word of mouth over the following months. The second path is often the safer one commercially, especially for a lab that has been burned before by a major-version launch that did not live up to its own hype. A quiet release that beats expectations builds more durable trust than a loud one that merely meets them.

How to Actually Read a Version Number

None of this means version numbers are meaningless, it means they are evidence of intent rather than evidence of magnitude. A number tells you how a lab wants its release perceived, which is genuinely useful information, just not the information most people think they are getting when they see it. The correct response to a new version number is not to infer how much changed from the digit, it is to set the digit aside entirely and go read the actual change list: what shifted in training, in fine-tuning, in the surrounding product. The number is the lab's opening argument about significance. Whether that argument holds up is a separate question, and it is one only the underlying changes can answer.

The next time a lab announces its next major version, resist the urge to calibrate your expectations off the digit alone, whether that digit is bigger or smaller than you expected. A version number is a piece of narrative design, chosen in a room full of people thinking about positioning, competitive timing, and how a headline will read, not a certified measurement of technical distance traveled. Read it as you would read a chapter title: a hint about how the author wants you to feel about what comes next, worth noting, but not worth trusting until you have actually read the chapter.