The Model You Rely On Keeps Changing Underneath You

Read the AI forums this fortnight and the loudest anxiety isn’t about price, or even limits — we covered the metering complaints a couple of weeks ago. This time the recurring worry is subtler and, in its way, more unsettling: the thing I depend on doesn’t hold still. The model behind a familiar name gets quietly updated. The older version you’d settled on gets deprecated. The shiny replacement feels worse to actually work with. You tuned a workflow around a specific tool, and the tool turned out to be a rental you don’t control.

A note on method first, because we hold ourselves to it. We wanted Reddit and X in here as well, but neither was reachable to us in this session, so everything below comes from Hacker News, where each gripe arrives with a username, a timestamp and a permalink you can check yourself. Every quote is linked in full in the Sources list. We quote people sympathetically; the target is the product decision, never the person typing.

The through-line, in one sentence: you don’t own the model you rely on, and this fortnight a lot of people noticed at once.

The name stays the same. The model doesn’t.

The cleanest statement of the problem came, remarkably, from inside a lab. On a thread about model versions, an OpenAI staffer, tedsanders, explained the policy without flinching: “In the API, we keep the models fixed … However, in ChatGPT, we sometimes update models without changing their names.” He was candid about the reasoning, too — “Our goal isn’t to be opaque or sneaky, but just to not exhaust people trying to keep track of little changes” — and that steel-man is fair: nobody wants a version-bump notification every Tuesday.

But sit with what it means for anyone doing serious work in the consumer product. The behaviour you rely on can shift under a name you’d reasonably treated as stable, and you find out by feel, not by changelog. derefr, in the same discussion, put the mechanism precisely: a model “as presented to the user, isn’t just its weights, but also anything else happening on the ‘business layer’.” The label on the tin describes a moving target. When people insist the model “feels different this week,” they’re not always imagining it — and being told it’s a fixed product doesn’t square with being told, elsewhere, that it quietly isn’t.

There’s a deeper asymmetry hiding in the “we don’t want to exhaust you” defence. The people it exhausts to track little changes are, overwhelmingly, casual users — and they benefit from silent improvement. The people it exhausts to be surprised by changes are the power users, the ones running the model for hours a day, tuning prompts and pipelines to its exact quirks. Optimising for the first group by keeping everyone in the dark quietly taxes the second, and the second is the group actually paying for the top tiers. “Notify nobody” is a reasonable default only if you assume nobody was relying on the details.

Deprecation as a push out the door

If silent updates are the soft version, deprecation is the hard one: the model you chose is simply withdrawn. For heavy users that isn’t a convenience upgrade, it’s a forced migration. zzleeper, who runs research workloads at volume, described exactly where that pressure leads: “Newer models made that absolutely impossible, and the fact that the older ones are starting to get deprecated made me switch to e.g. deepseek for some of my runs.” The deprecation didn’t upgrade this user; it exported them.

It isn’t only chat. On the image side, lmf4lol, otherwise delighted to have a new model live, hit the same wall from another direction: “Just a shame they deprecated the on-demand flux models :( Where do I get my fix for image gen now?” A capability people had built around, gone — and the enthusiasm and the loss sitting in the same sentence is the whole mood in miniature.

The rituals of people who’ve been burned

Watch what experienced users actually do about this and you learn how little they trust the ground to stay put. matltc has turned self-defence into a routine: “Pinned model to Opus 4.6 slug in ENV.ANTHROPIC_MODEL.” Pinning a version is the coder’s way of saying I refuse to let this change without my permission. And even that is a losing battle against the surrounding churn, because the scaffolding moves too: “the documentation changes so frequently that whatever you built is deprecated by the time you get it humming.” You can pin the model and still be outrun by everything around it.

This is the texture behind a point we’ve made in the abstract — that the ground under these products shifts too often for comfort. Except here it isn’t the buttons moving. It’s the model.

“I still prefer 4.8”

The sharpest version of the complaint is when the replacement is not just different but, to the person paying, worse to work with. This fortnight that sentiment had a specific shape: several long-time users saying the newest flagship is a downgrade in daily feel. verdverm summed up a room: “I’ve only heard meh reaction to sonnet 5 from people in the flesh, they still prefer 4.8.” roncesvalles was more specific about why: “I almost prefer Opus 4.8. Opus 5.0 has the overly scholastic tone of Fable but without the intelligence.”

For scotty79 the verdict was blunt — “Sonnet 5 is obnoxious model that’s terrible to work with” — and for ferris-booler it was enough to move house: “I hit this feeling with Claude one too many times and switched from Anthropic Pro to OpenAI Pro,” with a theory attached — that the flagship’s “fantasy-jargon is a symptom of training failure, not a sneaky intelligence edge.” None of this is a benchmark claim, and that’s the point: these are the qualitative, lived reactions that the leaderboard numbers never capture. A model can post a higher score and still feel like a worse colleague.

Our moan of the day belongs to loopmonster, who captured the specific exhaustion of a “better” model that’s more work to use:

To be scrupulously fair, this is taste as much as capability, and plenty of other users rate the new flagships highly — a subjective downgrade for a verbose writer is not a defect for everyone. But taste is exactly what you optimise a daily tool around, and when an update overrides yours without asking, “we improved it” and “you now like it less” are not contradictions. They’re the same event from two chairs.

When you can’t trust the replacement either

The churn would sting less if the new thing were unambiguously dependable. But the same fortnight served up a reminder of why blind trust is unwise regardless of which model you land on. smackeyacky recounted repairing an old Mitsubishi with an AI at his elbow: it told him “I could just remove said balance shaft chain as an emergency repair. Sorry Gemini, it also drives the oil pump.” Then it suggested clearing contaminated oil by “filling the crankcase with hot, soapy water and running the engine.” His conclusion is the quiet tragedy of the whole beat: “if I trusted it with a topic I’m not familiar with there is a huge potential for damage … I miss normal searching.” A tool that keeps changing and still can’t reliably tell you when it’s wrong asks for a lot of faith it hasn’t earned.

Notice how the churn and the unreliability compound. If the model held still, you could at least learn its failure modes — where it bluffs, which topics to double-check — and build up a working intuition for when to trust it. But every silent update and every forced migration resets that intuition. You’re asked to re-learn the tool’s tells from scratch, on a schedule you don’t set, for a tool that was never fully honest about its confidence in the first place. Stability is what makes an unreliable instrument usable. Take it away and you’re left calibrating against a moving target.

The pattern under the gripes

Line the complaints up and they rhyme. The recurring shapes this fortnight, roughly in order of how often they surfaced:

• Silent swaps — the model behind a stable name updated without a changelog, so behaviour drifts and you diagnose it by feel.
• Forced migration — a version you’d chosen deprecated out from under you, pushing you to a rival or a rewrite.
• Defensive pinning — power users hard-coding version slugs to claw back a scrap of stability, and losing anyway to moving docs.
• Downgrade-by-upgrade — a newer flagship that feels worse to work with, verbose or obstinate where its predecessor was easy.
• Unearned trust — and beneath all of it, a tool confident enough to tell you to pour soapy water in an engine.

To be fair to the companies — and most of these people plainly still like the tools, or they wouldn’t care this much — none of this is bad faith. Updating models in place genuinely does spare most users a firehose of version notes. Retiring old models genuinely does free up scarce capacity for the ones people use. tedsanders’ explanation is reasonable on its own terms, and a policy that suits 900 million casual users will inevitably chafe the power users who’d tuned everything to a specific release.

But the fair complaint survives all of that, and it’s narrow: notice and choice. Tell people when the model behind the name changes. Give the ones who depend on a specific version a supported way to keep it, or a real runway before it’s gone. Don’t let “we didn’t want to exhaust you” become the reason a paying user can’t tell what they’re actually running this week. The people quoted here aren’t asking the models to stop improving. They’re asking to not be surprised by their own tools.

If there’s one thing to take from a fortnight of other people’s receipts, it’s this: treat the specific model as borrowed, not owned. Pin what you can, keep a second provider warm, write down which version actually worked for your task, and don’t build anything load-bearing on the assumption that the tool you learned this month will be the same tool — or any tool — next month. The churn only works on people who assumed permanence. These users stopped assuming, out loud, with timestamps — and that scepticism is the most pro-consumer instinct on the whole thread.