Does Meta “Deprecate” Llama Models? What That Means for Open Weights

Every other model family in this library has a deprecation schedule: a date after which the endpoint returns an error. Llama has no such date, and it cannot have one. But the conclusion people draw from that — that an open-weight model is permanent — does not follow either, and the gap between those two positions is where production systems break.

The claim

Meta does not deprecate Llama models, because it has no mechanism to. What actually happens is that the ecosystem around a version stops being maintained, and every dependency you have on that ecosystem expires on its own schedule while the weights themselves keep working perfectly. The practical risk is therefore not a cutoff date. It is a slow accumulation of things that used to be easy and are now your problem.

Why there is no off switch

A hosted model can be retired because the provider runs it. They own the GPUs, the routing and the response; withdrawing the model is a config change on their side, and your request starts returning an error you did not write.

A downloaded checkpoint has none of that structure. It is a set of files on storage you control. There is no call home, no licence server, no expiry field in the safetensors header, and no remote party in the request path. The inference runs on your hardware against your bytes. For Meta to stop a Llama 3.1 checkpoint running on your cluster, it would need access to your cluster.

This is not a promise Meta made. It is a property of the distribution model, which is stronger than a promise, because it does not depend on anyone’s continued intent. That is the entire security argument for open weights, and it is sound as far as it goes.

What does expire

The weights persist; the things around them do not. In rough order of how soon they bite:

• Hosted endpoints for that version. If you consume Llama through a reseller rather than running it, you have all the deprecation exposure of a closed model and none of the compensating control. Providers retire older Llama versions on their own schedules and announce them in their own changelogs, and the fact that the weights are public does nothing for you when your endpoint 404s. This is the failure that actually happens, and it happens to people who believed they were insulated from it.
• Runtime support. Inference frameworks carry per-architecture code — the RoPE scaling variant, the chat template, the quantisation kernels. Old architectures are maintained by whoever still cares. When they stop, you are pinned to an old framework version, and then to an old CUDA, and then to an old driver, and the cost of that pin compounds.
• Tooling defaults. Fine-tuning libraries, serving stacks and evaluation harnesses drop older templates and formats. Nothing errors; the template just quietly renders differently from what the model expects.
• Hardware. A checkpoint tuned for a GPU generation you can no longer rent is deprecated in every sense that matters to your budget.
• Security fixes. There is no patch pipeline for a model. A behaviour discovered to be exploitable in Llama 3.0 is addressed by releasing 3.1, not by fixing 3.0. Running the old version means running the known behaviour, forever.

The one real chokepoint

There is a single point where Meta retains genuine leverage, and it is distribution rather than execution. Llama weights are gated: the Hugging Face repositories and Meta’s own download flow require accepting the community licence, and access is granted per account. Meta could stop granting new access to a checkpoint tomorrow. Copies already downloaded would be unaffected; new deployments would have to find them elsewhere.

Add to that the licence itself, which is a contract rather than a permanent grant. Meta’s community licences include termination on breach, and the acceptable use policy they incorporate is a document Meta writes. The bytes cannot be recalled; the permission to use them commercially is a different question, and it is the question your legal department will ask. That is covered in what the Llama 3 licence actually permits.

So the honest summary of open-weight permanence is: execution is permanent, distribution is not, and permission is a contract. Only the first of those three is a property of the file.

The obvious objection

The strongest argument against everything above is that it describes a freedom almost nobody exercises. Most teams using Llama consume it through a hosted endpoint, because renting inference is cheaper and simpler than operating GPUs, and a team in that position has exactly the deprecation exposure of a closed model. If openness only helps people who self-host, and self-hosting is a minority, the permanence argument is close to theoretical.

That objection is largely right as a description of current practice and wrong as a conclusion, for one reason: an option has value even unexercised, provided it is real. A hosted closed model that is withdrawn leaves you with a migration to a different model and a re-evaluation of everything downstream of it. An open-weight model withdrawn from every hosted provider leaves you with a migration to a different host, running the same weights, producing outputs close enough that your evaluations still mean something. Those are different sizes of problem, and only one of them is survivable in a week.

But the value is conditional on the fallback being executable, and that is the part that decays quietly. If you have never downloaded the weights, never checked that your prompts render correctly against the reference template rather than against one provider’s API translation of it, and never confirmed that a checkpoint of that size can be served on hardware you can actually obtain, then you are holding an option you have not priced. The argument is not that open weights make you safe. It is that they make one specific, cheap piece of preparation possible — and that preparation, rather than the licence text, is what is actually being offered when somebody says “open”.

What follows from this

If you have concluded that open weights remove the deprecation problem, you have solved it only for the case where you actually hold the weights and actually run them. Three things follow.

1. Hold the artefacts, not a reference to them. If a model matters, keep the checkpoint in storage you control, pinned by content hash rather than by tag — see pinning a Llama checkpoint to a Hugging Face revision. A repository name is a pointer to something somebody else can move.
2. Pin the runtime alongside the weights. The combination is what produces your outputs. A model archived without the framework version, template and quantisation that served it is an archive of the easy half.
3. Treat hosted Llama as hosted. If your Llama arrives over someone else’s HTTPS, put it on the same deprecation watch as every closed model you use. The openness of the weights is a fallback plan, and a fallback plan you have never executed is a hypothesis.

None of this argues against open weights. It argues that the guarantee they give is narrower and more specific than the one people repeat: not “this model will always be available”, but “this copy of this model will always run, if you keep it and keep something that can load it”. That is a real guarantee and no hosted API offers anything like it. It is also conditional on work you have to actually do.