Open Weights Now Come With a Waiting Period

Z.ai released GLM-5.3, a coding model that reportedly found more than a thousand genuine security bugs in widely used software including the Linux kernel. It also held back the open weights pending a safety review. Those two facts together are the interesting part, because for the last couple of years open has generally meant downloadable on day one, and a lot of self-hosting plans are quietly built on that assumption.

The assumption nobody wrote down

When a business decides to self-host, the reasoning is usually sound: personal information that should stay in Canada, a workload big enough that per-token pricing hurts, or a sensible reluctance to build everything on one supplier's terms. Those are good reasons and we have argued for them before in running local models in a Canadian business.

What tends to go unexamined is the next step, which is picking a specific model and building a timeline around it. That works fine while open releases are prompt and predictable. It stops working the moment availability becomes something a company decides case by case.

Why the delay is defensible

It would be easy to read a withheld release as backsliding on openness, and in this case that reading seems unfair. A model that can locate a thousand real vulnerabilities in critical infrastructure is precisely the sort of capability where thinking before publishing is reasonable. We wrote yesterday about this class of capability becoming purchasable, and the open-weight version of the same question is harder, because published weights cannot be recalled.

The point is not whether this particular decision was right. It is directional. As these models get more capable, the incentive to review before releasing grows rather than shrinks, and anyone planning around open weights should price that in.

What can actually go wrong

None of these are catastrophic on their own. They become expensive when a project timeline, a compliance commitment, or a customer promise was built on the first column.

Separate the decision from the model

Here is the fix, and it costs nothing. Your reason for self-hosting is stable. Residency requirements do not change because a release slipped. Cost pressure at volume does not either. The specific model you had in mind is the unstable part, and treating it as a fixed input is how projects get stuck waiting for something that may not arrive.

So write your requirements in terms of what the model has to do. Good enough at summarising your document types, runs on hardware you can afford, licence permits your use. Then pick whatever meets that bar when you are ready to build, and expect to swap it later. That is the same hedging logic as not marrying one AI model, applied to the open side where people assume it does not apply.

Test the fallback before you need it

Most self-hosting plans name a hosted fallback in case the open route does not work out. Very few have run anything through it.

An untested fallback is a sentence in a document. Send real work through it for a week: check the output quality against what you expect, confirm the data handling actually meets your residency requirements, and find out what it costs at your real volume rather than the volume in the pricing example. Doing that while nothing is on fire takes an afternoon. Doing it when a release has slipped and you have promised a client a date is a different experience entirely.

The wider read

Open weights have been one of the genuinely good developments for smaller businesses, because they made capable AI something you could run on your own terms rather than rent on someone else's. That case is covered in the open-weight inflection point, and none of it is undone by one delayed release.

What is changing is subtler. Open is becoming a decision a company makes each time rather than a property you can rely on. Plan accordingly, keep your requirements model-agnostic, and treat any date that depends on someone else's release schedule as a guess rather than a commitment.

Frequently Asked Questions