The Case for AI LTS: Why the Real World Needs a Stable Release Cycle
On what a college loses when a model is deprecated, and the case for a supported release that stays where it is.
If you spend enough time around the current discourse in artificial intelligence, it is easy to get the impression that the only metric that matters is the frontier. Every few weeks, the industry holds its breath for a new leaderboard topper. A model arrives with a larger context window, a few percentage points gained on a coding benchmark, or a faster time-to-first-token, and the ecosystem is expected to reconsider its tools, rewrite its prompts and migrate.
In my response to Dario Amodei's _We Must Pace the Frontier_, I argued that slowing the pace of frontier development serves a purpose beyond giving researchers more time to make AI safe. It gives the rest of us time to absorb what already exists: to learn how these systems behave, build practices around them, and make them part of working lives and institutions.
Even when we have a capable system, why should we have to keep replacing it?
The AI industry needs the equivalent of an Ubuntu Long Term Support (LTS) release: a stable, maintained version that organisations can depend on for years, while development continues at the frontier.
Two release cycles, two different purposes
Linux settled this a long time ago. Run a rolling release and you get the newest kernel, the newest packages and the occasional breakage, which is part of the bargain. Run infrastructure that other people depend on and novelty stops being an advantage: what you want is a defined support period, predictable maintenance, and changes that do not casually break existing work. Ubuntu designates a long-term support release every two years and maintains it for five, which has never stopped Canonical shipping interim releases for anyone who wants them.
A supported release is not a frozen one. Vulnerabilities get fixed, bugs get addressed, supported components get updates. The commitment is to maintain a known release rather than continually replace it with the newest one.
AI has no comparable commitment. Pinned model snapshots and enterprise deprecation windows provide some stability, but pinning a version is not a guarantee of long-term availability, maintenance and compatibility.
The nearest thing anyone has offered is Anthropic's undertaking, published in November 2025, to preserve the weights of all publicly released models for at least the lifetime of the company. That matters, and it answers a different question. Preserved weights protect the model. A support window protects the people who built their work around it.
The cost of moving ground
Consider how a school, further education college or NHS trust actually operates. These organisations are not resistant to change because the people inside them lack imagination. They are cautious because the cost of failure is high, budgets are constrained, and the consequences of disruption fall on people who may have little power to absorb it.
Imagine a college spending six months developing an accessible teaching workflow around a particular model. Staff are trained. Safeguarding procedures are written. The model is tested against complex student queries. Guidance is developed for students with additional needs, and teachers learn which instructions work, where the model makes mistakes and when its answers need checking. Every one of those decisions turns on the question I put in _The Scribe Rule_, whether a given use removes a barrier or removes the lesson, and it has to be answered for the model actually in front of you.
The workflow begins to work. Staff become familiar with it, and students develop routines that allow them to work more independently.
Then the model is deprecated, its behaviour changes materially, or its replacement handles familiar tasks differently. The college must reassess its procedures, retrain staff and test the new system. Some of the work has to be done again, and the disruption falls on the people who had finally learned how to use the previous version.
The replacement may be more capable, but capability does not make the transition costless.
Anyone who has built software or structured workflows on top of language-model APIs will recognise the same problem on a smaller scale. A silent model update can alter formatting, tool selection, refusal behaviour or the way a model handles an awkward edge case. A system that once returned valid JSON may start producing structures that break the application consuming them. A model may become better at the general task while becoming less predictable on the particular task a business relies on, a mismatch I wrote about from the user's side in _The Middle_.
In traditional software, we recognise the difference between an improvement and a breaking change. In AI, a release can improve benchmark performance while quietly breaking the assumptions on which a working system depends. What a working system needs is for change to arrive visibly, with a route through it.
What an AI LTS would promise
Imagine a major AI lab designating a capable model as a five-year Long Term Support release. The commitment would be more substantial than leaving an old model name in an API menu. It would establish a defined relationship between the provider and the people building on its technology.
Three commitments would form the basis of such a release.
1. Versioned behaviour and controlled change
The model checkpoint, inference configuration and interfaces would be documented and versioned. Providers would publish compatibility criteria and maintain regression tests covering the tasks and output formats on which downstream applications depend.
The aim would not be to promise that every prompt produces an identical answer forever. Language models are probabilistic, and outputs can vary even when the underlying weights remain unchanged. Behaviour can also depend on system prompts, inference software, safety filters, tool definitions and other parts of the serving stack.
The aim would be to make material changes visible, measurable and controlled. A provider should not silently alter a supported release in ways that invalidate existing workflows. Where a change is necessary, it should be documented, tested and accompanied by a migration path.
2. Security and safety maintenance without unnecessary disruption
An LTS model would still need security updates and improvements to its safeguards. Stability cannot mean preserving a vulnerability simply because fixing it might change behaviour.
The provider would distinguish routine maintenance from changes that materially affect model behaviour, publish change notes, and test updates against regression suites covering both safety and task performance.
Sometimes those objectives will conflict. A serious vulnerability may require a change that breaks an existing workflow, and an urgent security issue may not allow a long migration period. The commitment should be to explain those decisions, minimise unnecessary disruption and provide a clear route forward, not to pretend that safety and compatibility can always be reconciled perfectly.
3. Predictable availability and economics
Institutions would receive a defined support period, meaningful notice before retirement, transparent pricing or agreed pricing terms, and a documented migration path when support ends.
A model that remains technically available but becomes prohibitively expensive is not a dependable foundation, and as I argued in _The Meter_, consumer AI has already shown how little of this pricing is built to be planned around. Nor is a model dependable if its provider can withdraw it at short notice to free up computing capacity for a newer release.
Open or locally hostable weights would offer an additional route to continuity. They can reduce dependence on a single provider's commercial decisions, although they do not remove the costs of hardware, inference infrastructure, security and maintenance.
The point is not that long-term support must be free, only that the cost and conditions of relying on a model should be known well enough for organisations to plan around them.
Stability is part of safety
There is a deeper reason to take this seriously.
People who have used a system for long enough develop an understanding of its behaviour. They learn what it does well, where it tends to fail, and what an unusual answer looks like. That familiarity is not a substitute for formal testing, but it can help people recognise when something has gone wrong.
A workforce that is permanently learning a new model has less opportunity to develop that familiarity. A teacher who knows how a system normally responds to a student's question may notice when an answer is out of character. A care worker who has learned the limits of an administrative tool may be better placed to catch an implausible result.
_Eighty-Seven_ put the harder version of this: oversight only works while the person doing it retains the expertise to recognise a plausible mistake, and that expertise is often grown by the very work being handed over. A release cycle that resets the clock on familiarity is working against the same thing.
Changing the system can improve safety, of course. A new model might be substantially less error-prone, and retaining an inferior version indefinitely would be irresponsible. But the decision should weigh the benefits of the improvement against the costs and risks of migration. It should not assume that replacing a model is automatically beneficial because the replacement is newer.
In that earlier essay, I used commercial aviation as an example of a safety-critical field in which capability and change coexist with rigorous training and controlled procedures. Aircraft do not remain unchanged forever. Their modifications are managed through processes designed to keep operators informed, qualified and able to work safely with the machines they use.
AI needs an equivalent respect for the human and institutional work that surrounds the technology. Reliability is not solely a property of the model; it is also a property of the system of people, procedures and infrastructure built around it.
The frontier does not have to stop
The obvious objection is that long-term support would consume resources that could otherwise be spent developing and serving newer models. Maintaining older versions costs money, engineering time and computing capacity. Providers have legitimate reasons to retire systems they can no longer support economically or safely.
An LTS programme would make those costs explicit rather than simply transferring them to users when a model disappears. _The Timestamp_ was about the same asymmetry somewhere else: the costs that get counted are rarely the costs that land. Support could be offered at a price that reflects its real cost, with a defined period and a clear end date.
Nor should every model receive long-term support. Some will be experimental, short-lived or unsuitable for sustained deployment. The distinction is between models intended for rapid experimentation and models deliberately offered as dependable foundations for long-lived work.
The two tracks can coexist. Frontier research can continue to push the limits of reasoning, scientific discovery and multimodal capability. Users who need the newest performance can adopt it, while organisations that prioritise stability can choose a supported release and migrate when the benefits justify the effort.
From impressive demonstrations to dependable tools
Invention and adoption are different processes, which is the burden of Paul David's work on factory electrification: the motor was available for decades before the productivity gains arrived, because those gains needed the factory reorganised around it.
AI faces a similar challenge. A more capable model does not automatically produce a more capable institution. Organisations need time to develop procedures, train people, assess risks and discover where the technology genuinely helps. They need to do this without constantly wondering whether the system beneath their work will still exist, or still behave as expected, a few months later.
A stable release cycle would not solve every problem of AI adoption. It would not make unreliable models reliable, eliminate hallucinations or remove the need for human oversight. But it would give organisations a firmer basis on which to address those problems.
The AI industry has spent enormous effort making models more capable. It should now treat long-term support as a first-class part of the product, not an afterthought reserved for enterprise customers who negotiate special arrangements.
A tool gets adopted when people can rely on it long enough to build something lasting around it, which is rarely the moment it looks most impressive.
The frontier should remain ambitious. The release cycle beneath the real world should be stable enough to trust.
- * *
Certainty Note
The observations in this essay on institutional inertia, staff training, and the human cost of changing assistive workflows come directly from my day-to-day experience working in further and special educational needs (SEN) education. Similarly, the technical points regarding Linux release cycles, API breaking changes, and the difference between frozen weights and serving-stack behaviour are grounded in my own experience building software and working on Linux systems.
The sections on Ubuntu's release cadence refer to Canonical's published lifecycle documentation (specifically the five-year standard LTS maintenance window and Ubuntu Pro extensions). Anthropic's weight-preservation commitment is its own published statement of November 2025. The historical parallel in the conclusion draws on Paul A. David's 1990 _American Economic Review_ paper, _"The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox."_
Where this piece is necessarily more speculative is on the internal economics of frontier AI labs. While providers do offer pinned model snapshots and enterprise deprecation windows, I do not have visibility into the exact server-side economics of keeping legacy inference clusters warm versus consolidating compute for newer architectures. The three-part LTS framework proposed here is therefore a normative policy and engineering argument, an account of what public services and businesses need from the industry, rather than a claim that doing so is currently cheap or trivial for providers to implement.