In March 2023, GPT-4 correctly identified whether a number was prime 84% of the time. By June 2023 — same model, same name, no version number changed, no changelog published — that number had fallen to 51%. Researchers at Stanford and UC Berkeley found this by running identical prompts against the API three months apart and comparing the answers. Nobody outside OpenAI had to be told the model changed, because nothing said it had. They just noticed the answers got worse.

That’s model drift, and it’s the part of the AI supply chain almost nobody puts in their risk register. We audit prompts. We red-team jailbreaks. We rarely ask what happens when the thing behind the API you didn’t touch quietly stops being the thing you tested against.

For the rest of us: three kinds of drift, one shared symptom

Drift is a catch-all word, so it helps to split it into what’s actually moving.

Model drift is the provider changing the model itself — a silent update, a re-tuning pass, a safety adjustment — while the name and version string stay the same. You didn’t retrain anything. The ground moved under you.

Input drift is your users changing, not the model. A product that launched with power users gets a wave of new ones who phrase things differently, ask different questions, use unfamiliar vocabulary — and the system that was tuned on the old population starts to underperform on the new one, with the model completely unchanged.

Output drift is what you actually observe: the answers look different than they used to. It’s the visible symptom, and it can be caused by either of the other two — or by a retrieval index quietly going stale, which produces the exact same downstream effect as the model itself drifting, even though the model never moved.

The shared symptom across all three: nothing crashes. There’s no error message. The system just gets a little worse, a little at a time, until someone notices — usually a user, rarely a dashboard.

The study, and why the details matter

The Stanford/Berkeley result (Chen, Zaharia, and Zou, 2023) tested GPT-4 and GPT-3.5 on the same battery of tasks in March and June of the same year: math problem solving, sensitive/opinion questions, code generation, visual reasoning. The prime-number test is the number that travels because it’s so stark — 84% to 51% is close to a coin flip getting worse than chance would predict on a task the model was previously good at.

Two other findings from the same paper matter more for anyone running this in production. Code generation quality changed — the June model wrapped code in markdown formatting that the March model didn’t, breaking any pipeline that executed the output directly without stripping it first. And the model’s willingness to answer certain categories of questions shifted, which is a behavior change with legal and compliance implications, not just an accuracy number.

None of this was communicated. “GPT-4” in March and “GPT-4” in June were, functionally, two different systems answering to the same name.

Why this is an enterprise architecture problem, not a research curiosity

If you’ve built a product, an internal tool, or an automated workflow against a foundation-model API, you’ve taken on a dependency that can change its behavior with zero notice, zero versioning, and zero changelog. That’s not how any other dependency in a serious engineering organization is allowed to work. A cloud provider that silently changed how their storage API rounded numbers would trigger an incident review. A model provider doing the equivalent gets absorbed as “huh, weird” because there’s no established norm yet that it shouldn’t happen.

The fix isn’t to distrust the model. It’s to treat it like what it actually is: a live, versionless dependency that needs the same regression discipline you’d apply to any third-party API you don’t control. Concretely, that means keeping a small, stable eval set — the tasks you actually care about, not generic benchmarks — and running it against production traffic on a schedule, not just at initial deployment. It means logging embeddings of your input distribution so you can tell input drift (your users changed) apart from output drift (something else changed) instead of guessing. And it means treating a drift signal as a lead to investigate, not an alarm to act on by itself — drift without a measurable drop in your actual eval scores is usually noise, and chasing every fluctuation burns the team that’s supposed to be watching for the real one.

What this means

The uncomfortable part of this story isn’t that GPT-4 got worse at identifying prime numbers. It’s that an entire category of production AI systems has no equivalent of a changelog, no SLA on behavioral stability, and — in most organizations — nobody whose job is specifically to notice when the ground has moved. Enterprise architecture spent two decades building governance around dependencies that changed on a schedule you could plan for. Foundation models change on a schedule nobody publishes. Until that changes, the burden of noticing sits entirely with whoever built on top.

References