The LLM Never Tells You It Changed
Will you notice?
Your eval suite passed clean for three months on a case that used to be a real problem: dates in generated citations. Then a routing change in your LLM vendor’s systems moves your production traffic onto a different checkpoint. The same failure comes back in the place you stopped looking at. Your code didn’t change, your prompts didn’t change but now the result has changed.
The LLM never tells you it changed
LLMs change frequently in ways we can’t see. Weights update. Routing decisions send your query to a different checkpoint than it hit last week. Retrieval indices refresh. System prompts get tuned server-side, sometimes as an A/B test you were never told you were in. None of this shows up in the interface. The chat box looks the same whether or not the thing answering you is the same.
In some ways, this is similar to Google Search ranking. Google made roughly 4,725 changes to its ranking systems and interface in 2022 alone, something like thirteen a day. It confirms only a handful of those as named core updates each year. Everyone who’s used Google has felt the downstream effect. A site that used to rank well disappears. A type of query that used to return good results starts returning junk. Nobody’s ever told why or when. That’s the same silent-drift pattern, running for two decades on a product with billions of users. In SEO circles, blaming “the algorithm” has become a standing joke, not an actual diagnosis. It shows that the pattern is old and durable, not that anyone has solved it.
The model card won’t tell you
A first reaction might be that SaaS vendors change things all the time and we have learned to deal with it, why is this different? There are two main differences:
The first: vendors publish model cards and release notes, so isn’t the information available if you go looking for it? It is, but it’s the wrong granularity of information. A model card gives you aggregate statistics across broad benchmark categories. It doesn’t tell you whether the specific behavior you calibrated your trust against moved. Does it still handle ambiguous medical terminology in your discharge summaries the way it used to? Is the uncertainty phrasing in code review comments still what you learned to read? That’s the detail that matters, and model cards don’t give you that. You’d need the vendor to tell you about changes the vendor itself is probably not tracking at that granularity.
The second objection is stronger: every SaaS product updates silently, all the time, so why treat this as new? Three reasons compound here.
Amplitude. A UI update might move a button. A model update can shift qualitative reasoning behavior, the kind of change that decides whether an answer is trustworthy, not just where you click to get it.
Invisibility. A UI change is instantly identifiable the moment you see it. A change in how a model handles edge cases in your domain stays invisible until it bites you.
Entangled causation. When a website changes, you know it was the website. When your AI output shifts, you often can’t tell whether it was the model, a system prompt change, a routing decision, or your own prompting drifting over months.
Any one of these differences would be manageable on its own. Together they mean the ordinary “software changes, users adapt” story doesn’t transfer.
This already happened in public
In December 2023, a wave of ChatGPT users started reporting that GPT-4 had gotten lazier: shorter answers, more refusals, tasks half finished with an instruction to complete the rest yourself. The company said it hadn’t touched the model in nearly a month, called the behavior change unintentional, and conceded that model behavior can be unpredictable. A follow-up post went further. Differences in behavior can be subtle enough that only a fraction of prompts are affected. It can take a long time for anyone, customer or employee, to notice the pattern and track it down.
This is the important part: The vendor is telling you it may not reliably know when its own product changed, or why, or for whom. That’s not evasiveness. That’s the entangled causation problem. It’s playing out at the scale of a company with more visibility into its own system than any of its users will ever have. If OpenAI can’t always tell whether behavior actually shifted, individual vigilance on the user’s end is never going to catch it reliably.
The incentive runs the other way
There’s a reason no vendor ships a “your calibration may be stale” warning, and it isn’t only technical difficulty. Admitting that behavior drifts is a competitive liability. A vendor who discloses instability looks less reliable than a competitor who says nothing. That’s true even if the competitor is drifting just as much and simply isn’t telling you. The first company to be honest about this doesn’t get rewarded for honesty. It gets read as the shakier product. That’s not a reason to expect dishonesty from any specific vendor. It’s a reason to expect the whole category to under-disclose, regardless of any individual vendor’s intentions.
The metrics a vendor actually optimizes for compound the problem. Retention, usage volume, satisfaction scores: none of them reward closing your calibration gap. A prompt that asks users to reconsider how much they trust the product reads as friction, not as a feature. Even a vendor that wanted to build the right signal runs into the measurement problem the GPT-4 case exposed. Knowing whether a specific task-level behavior shifted for a specific kind of user is a hard, expensive, mostly unbuilt instrumentation problem. And software versioning itself was never designed for a system with no discrete release to hang a version number on.
Nothing tells you when to recalibrate
Software has version numbers for a specific reason: so a user knows the moment their mental model needs refreshing. Nothing plays that role for behavioral trust in a probabilistic system. There’s no signal that says the thing you calibrated your trust against three months ago is not quite the thing answering you now.
A team with enough discipline can build a piece of this themselves. Log the inputs, outputs, and model version for a canary set of prompts that map to the behaviors you depend on. Diff the outputs over time instead of scoring pass or fail. That catches the case where the qualitative shape of an answer shifts on a prompt you already knew to worry about.
It does not catch the failure from the opening of this piece, the one that comes back in the place you stopped looking. A canary set only tests what you thought to test. And when the diff does fire, you know something moved. You still don’t know whether it was the model, a system prompt, a routing decision, or your own prompting drifting over months.
Partial, effortful, incomplete detection is available to anyone willing to build it. A real recalibration signal, the kind a version number gives you automatically, is not.
What would that signal even look like, for a system whose behavior is continuous, not versioned, and whose changes are often invisible even to the people who made them?
Nobody has built it yet.
Sources
OpenAI’s response to GPT-4 “laziness” complaints, via Search Engine Roundtable (December 2023). https://www.seroundtable.com/openai-chatgpt-gpt-4-getting-lazier-36529.html
Search Engine Land, Google Algorithm Updates library: cites 4,725 changes to Google Search in 2022. https://searchengineland.com/library/platforms/google/google-algorithm-updates