In this article:
There’s a particular kind of medical scare that doctors worry about more than the dramatic ones. A heart attack announces itself. Chest pain sends people to the emergency room within the hour, and whatever caused it gets found, named, and treated fast, precisely because it was impossible to ignore. Hypertension doesn’t work that way. It can sit quietly for years, doing real damage the entire time, without a single symptom loud enough to force anyone’s hand. The people it hurts most are often the ones who felt completely fine right up until the moment they didn’t.
Production AI systems have their own version of this split, and most engineering teams are only set up to notice the dramatic half.
When an API contract breaks in the traditional sense — a field gets renamed, a status code changes, an endpoint disappears — the system screams about it immediately. Requests fail, builds go red, someone gets paged, and the fix usually lands the same day because the failure points directly at its own cause. That’s the heart attack. Painful, but legible.
Swap a language model for a newer version and you can trigger the second kind instead. The endpoint keeps answering. The JSON keeps parsing cleanly. Every existing test keeps passing. And underneath all of that apparent health, something has changed: what a given workload now costs to run, how often the system says no to a request it used to handle, how reliably structured its output actually is, which facts a retrieval step now decides are the relevant ones. None of that trips a single assertion, because none of it was ever something your assertions were checking for. It just sits there, compounding, until a symptom finally shows up somewhere nobody thought to look — a finance dashboard, a support queue, a customer complaint that reads more like confusion than a bug report.
This is what deserves a name: the silent breaking change. Not a bug in the traditional sense, and not really a regression either, since nothing regressed against any spec anyone wrote down. Just a system that got quietly worse while every instrument built to watch it kept reporting green.
Release notes for a new flagship model tend to read like light paperwork. A parameter or two gets marked deprecated. There’s a line about token counts. Somewhere near the bottom, a suggestion to re-run your test suite before sending it real traffic. It reads like nothing. It usually contains three separate changes, and only one of them is built to be noticed.
The one built to be noticed is the parameter deprecation. Sampling controls like temperature get locked down or removed outright, and any code still sending the old values starts getting rejected. This is, genuinely, the best-case scenario buried in the release — it fails immediately, it fails obviously, and a competent engineer fixes it before lunch.
The other two are built, structurally, to go unnoticed. A new tokenizer very rarely maps one-to-one onto the old one — the same paragraph of text can come out as a noticeably larger token count purely because the counting method changed, not because anything about the request did. Any budget or context limit calibrated against the old count doesn’t error when this happens. It just quietly starts running over, or trimming context earlier than it should, and the drift stays invisible until someone reconciles an invoice against expected usage and finds a gap they can’t explain.
The tuning that governs what a model will and won’t say shifts too, release over release, in ways vendors rarely document line by line. A request pattern that sailed through cleanly last month can start collecting hedges or outright refusals this month, with no change on the calling side at all — just a different classifier sitting behind an identical-looking endpoint. What surfaces from that isn’t an error. It’s a slow rise in complaints that the tool “got worse,” arriving with no code diff attached to point at.
Stack those three changes together and you get exactly one that a CI pipeline is equipped to catch. The other two require someone to already suspect the model, which is precisely the thing nobody does, because nothing in the tooling ever pointed them there.
Once this pattern is visible, it stops looking like something confined to major version bumps and starts looking like a property of any system that hides a probabilistic component behind a fixed-looking interface.
Cost is the first place it shows up, through tokenization changes that alter what identical inputs are billed for and how much usable context budget actually remains. Behavior is the second, through shifts in default sampling values or refusal tuning that change what a workflow can reliably accomplish without a single line of calling code being touched. Structure is the third — the scaffolding around how a prompt gets assembled can change under the hood, and a parser depending on exact formatting doesn’t fail cleanly, it degrades into subtly wrong output instead. And truth is the fourth, in systems built around retrieval: a larger context window or a different ranking behavior can reshuffle which documents a pipeline treats as authoritative, quietly changing what the system believes without ever touching a line anyone would think to review.
The detail that should unsettle anyone relying on version pinning as a safety net: every one of these four can occur without the model’s name or version string changing at all. Providers update what runs behind a given endpoint more often than they rename it. Hosted inference is best-effort reproducible at best — never guaranteed — because what a request returns depends on batching and backend conditions that sit entirely outside anything the caller can see or control.
The gap in how long each kind stays hidden isn’t small, either. A rejected parameter gets caught within the hour, because it fails as loudly as anything else in the stack. A shift in refusal behavior might take days to surface as a support pattern. A tokenization change can run for a full billing cycle before anyone even has the data needed to notice it happened.
<canvas id="detectionChart" style="max-width: 700px; margin: 2em auto; display:block;"></canvas><script src="https://cdn.jsdelivr.net/npm/chart.js@4"></script><script>new Chart(document.getElementById('detectionChart'), { type: 'bar', data: { labels: [ 'Parameter rejected outright', 'Output formatting shifts', 'Response timing shifts', 'Refusal pattern shifts', 'Retrieval relevance shifts', 'Cost-per-request shifts' ], datasets: [{ label: 'Roughly how long it runs before anyone notices (hours, log scale)', data: [0.2, 6, 10, 120, 200, 500], backgroundColor: [ '#2E6FF2', '#2E6FF2', '#2E6FF2', '#FF6F59', '#FF6F59', '#FF6F59' ] }] }, options: { indexAxis: 'y', scales: { x: { type: 'logarithmic', title: { display: true, text: 'Hours, log scale' } } }, plugins: { legend: { display: false }, title: { display: true, text: 'Blue: caught by the pipeline. Coral: caught by accident.' } } }});</script>
Most testing infrastructure carries an assumption that’s rarely stated out loud because it’s rarely wrong: a given input produces a checkable, deterministic output, so a test’s job is to confirm the shape of that output and stop there. Against compiled logic, that assumption holds. Against a probabilistic component sitting behind an otherwise ordinary-looking API, it quietly stops being true, and nothing about the testing tools changes to reflect that.
A schema validator has no opinion on whether an answer is good. It has no opinion on what the answer cost to produce, or how often the system chose to say no instead of helping. It only confirms that something well-formed came back — which is exactly why a model swap can sail through an entire existing suite while the product built on top of it gets measurably worse. The suite was never asking whether things were still as good as they used to be. It was only ever asking whether something came back intact.
That’s the part worth sitting with directly: quality and cost regressions in a model-backed system are invisible to any testing setup built only to catch exceptions and malformed responses. Catching drift instead of breakage requires an entirely different instrument — closer to a checkup than a smoke detector.
None of what actually fixes this is exotic or unfamiliar. It’s the same discipline mature teams already apply to any dependency whose real-world behavior matters more than its interface does — just finally pointed at something that happens to behave probabilistically instead of deterministically.
Start with an eval set that never gets prettied up for a demo — genuinely messy, representative inputs, scored against a rubric someone actually wrote and actually revisits. Every candidate model runs against that set before it ever sees production traffic, and what gets compared is the score, not just whether a response validated.
Pair that with something that grades meaning rather than shape. Schema validation will happily pass a response that’s perfectly well-formed and noticeably worse than what came before it — which means shape was never the thing that needed checking in the first place. A second model call scoring old output against new, or a human spot-check on a sampled basis, catches what structure alone can’t.
Treat token spend as a live metric worth alerting on directly, not a number that only gets scrutinized once a monthly invoice forces the question. A percentage shift right after a model swap is the kind of signal that should surface in hours, not at the end of a billing cycle.
Track the rate at which a workflow gets refused, hedged, or wrapped in caveats over time, the same way you’d track any other quality metric. A sudden climb is one of the fastest available tells that something upstream of you changed its mind about what it’s willing to do.
Pin to a specific model snapshot wherever a provider allows it, but don’t mistake that pin for a guarantee — a provider can and does adjust what actually runs behind an unchanged name. Schedule deliberate re-checks against the eval set on a fixed cadence instead of waiting for a changelog to force the question.
And roll out every model swap the way any other risky deploy gets rolled out: a slice of live traffic first, a real comparison against the baseline, and a wider release only once the numbers hold up — not once the absence of errors gives false reassurance that they do.
None of that asks more of a team than the contract tests and canary deploys most engineering organizations already run for perfectly ordinary service dependencies. The only real shift is admitting a model version is a dependency whose contract includes cost and behavior, not just a response shape — and finally checking it like one.
This isn’t a case for moving slowly on model upgrades, or treating every new release with suspicion it hasn’t earned. Better, cheaper, more capable models are a straightforward win, and the teams that adopt them fastest generally keep winning. What’s missing isn’t caution. It’s a second gate that almost nobody has built yet, mostly because almost nobody has traced a real problem back to its actual cause closely enough to realize the gate was missing.
The teams that end up ahead won’t be the ones moving carefully. They’ll be the ones who catch, in a routine canary run against a rubric nobody glamorized, exactly what would otherwise have shown up six weeks later as a bill nobody could explain and a support queue nobody could calm down. That’s not friction on adoption. It’s the difference between adoption that survives contact with production and adoption that quietly doesn’t.
If any part of this matches something your own team has lived through — a swap that cleared every check and still broke something real — it’s worth running your postmortems against the categories above. Most of these problems already have a name once you go looking for it. Finding the name tends to be the hard part.
The Silent Breaking Change was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.