It is amazing how quickly the landscape of artificial intelligence can shift under your feet. One day you are building a product around a specific model, and the next day you get an email saying that model has a retirement date. It feels a bit like trying to build a house on a foundation that is actively being replaced while you are still framing the walls. We are sitting here in late February of twenty twenty-six, and the pace has only accelerated since the early days of the LLM boom.
Herman Poppleberry here. And honestly, Corn, I think the term foundation is becoming a bit of a misnomer in this space. It is more like building on a moving walkway that occasionally changes direction without warning. Today’s prompt from Daniel is about exactly this, the arc of deprecation in AI. He is looking at the very different strategies companies like Anthropic and Google are taking when it comes to sunsetting their models and how developers are supposed to keep up without losing their minds. It is a classic struggle between the bleeding edge of research and the boring, necessary stability of production software.
It is a great topic because it highlights a fundamental tension in the industry. On one hand, you have the rapid pace of innovation where a model that is six months old might already be considered legacy. On the other hand, you have the need for stability in production environments. Daniel mentioned that Anthropic seems to be moving particularly fast, almost aggressively, with their sunset dates, while Google is offering these dynamic endpoints like Gemini Flash Latest. It is a philosophical divide that has massive implications for anyone writing code today.
Right, and it is a fascinating contrast. If you look at Anthropic’s documentation, they are very explicit. For example, Claude three point seven Sonnet and Claude three point five Haiku are already on the retirement list for early twenty twenty-six. They give you a hard date, and after that, the API call will simply fail. You get a four hundred error, and your app goes dark if you haven't migrated. Google, conversely, is trying to abstract that away. You point your code to a generic Latest endpoint, and they swap the engine under the hood whenever they release something new. It is the difference between a landlord telling you that you have to move out by the first of the month and a landlord who just swaps your furniture while you are at work.
I want to dig into the why of this. Why would Anthropic choose such a short lifespan for their models? To a developer, it feels like a lot of unnecessary maintenance work. Every few months you have to go back into your codebase, update the model string, re-run your evaluations, and hope that the new model does not break your specific implementation. It feels like we are being punished for being early adopters.
I think there are a few layers to why Anthropic is so aggressive here. The first, and arguably the most important for a company that brands itself on AI safety, is the guardrail issue. As these models evolve, our understanding of their failure modes and safety vulnerabilities evolves too. A model released a year ago might not have the same level of fine-tuning or constitutional AI principles that the latest version has. If Anthropic keeps an old, less safe model alive, they are essentially maintaining a liability. They have a very specific vision of what a safe model looks like, and once they have a version that meets a higher standard, they want the old ones gone as quickly as possible.
That is an interesting point. It is not just about the model’s performance, it is about the model’s behavior and the company's reputation. If the industry discovers a new type of prompt injection or a specific bias issue, it is much easier to fix it in the current flagship than to go back and patch ten different legacy versions. It is like trying to provide security updates for Windows ninety-five in twenty twenty-six. At some point, you just have to say, we are not supporting this anymore for your own good.
Exactly. And then you have the purely technical and economic side. Maintaining an inference stack for a legacy model is incredibly expensive. You have to keep the specific weights loaded, maintain the infrastructure that supports that specific architecture, and ensure that your API gateway can still route to it. In a world where GPU clusters are still the most precious resource on the planet, every H-one-hundred or B-two-hundred that is running an old version of Claude is a chip that is not running the latest, most efficient model. Anthropic is a smaller, more focused company than Google. They cannot afford to spread their compute resources across five generations of models. They need every T-FLOP focused on the next big thing.
So it is a matter of resource optimization. But then why is Google taking the opposite approach? They are basically saying, do not worry about the versioning, we will handle it for you. Is that just a reflection of Google having more compute resources, or is it a different philosophy of what a developer needs? Because Google certainly has the hardware to keep old models running in a corner of a data center somewhere.
I think it is a bit of both. Google is an enterprise company at its core. They have decades of experience dealing with corporate clients who value stability above all else. They understand that if you tell a Fortune five hundred company that they have to refactor their core automation logic every nine months, that company might just decide not to use your service. The Gemini Flash Latest approach is a massive convenience feature. It lowers the barrier to entry and reduces the long-term maintenance burden for the user. It is the "set it and forget it" model of AI integration.
But wait, Herman, does that not introduce a different kind of risk? If I am pointing to a dynamic endpoint and Google swaps out the model, my prompts might behave differently. Even if the new model is technically better on benchmarks, it might have a different personality or a different way of formatting its output that breaks my downstream parser. If I am expecting a JSON object with specific keys and the new model decides to add a friendly preamble or change the key casing, my whole pipeline crashes.
Oh, that is the huge trade-off. It is the classic stability versus performance dilemma. When you use a dynamic endpoint, you are essentially giving up control in exchange for convenience. You might find that your latency suddenly drops, which is great, but you might also find that the model is now more verbose or less concise, which could break a user interface that has a strict character limit. We call this "semantic drift." The API contract hasn't changed—you are still sending text and getting text—but the meaning and the nuance of that text have shifted. For a developer, that is a nightmare to debug because nothing in your code changed, but your users are suddenly complaining that the AI sounds "different."
This is where Daniel’s mention of proxy layers and middleware becomes really relevant. If you are a developer and you do not want to be at the mercy of either a hard sunset date or a sudden, invisible model swap, you almost have to build a buffer. You need a way to decouple your application logic from the specific provider's whims.
Yes, and we have talked about tools like OpenRouter before, but there are also self-hosted options like Lite LLM. The idea is that you create your own internal API. Your application calls an endpoint you control, say, "internal-billing-assistant," and then your middleware decides which actual provider and model to route to. This layer acts as a shock absorber. It can handle the retries, the fallbacks, and most importantly, the version mapping.
I can see the appeal. If Anthropic sunsets a model, you just change the mapping in your proxy to the next version, and your main application code never has to change. It is basically an abstraction layer for the AI era. It allows you to treat models as interchangeable commodities rather than unique, precious snowflakes.
It is, but as Daniel pointed out in his prompt, that also adds complexity. Now you have another piece of infrastructure to maintain. You have to worry about the latency of the proxy itself, the security of that layer, and ensuring that the proxy properly handles the different features of each model, like system prompts or tool calling schemas. And let's be honest, tool calling is where this gets really messy. If Claude three point five Sonnet expects tools to be defined one way and Claude four expects them another way, your proxy has to be smart enough to translate those schemas on the fly. That is not a trivial piece of engineering.
It feels like we are recreating the history of software engineering in fast-forward. We went from hard-coded hardware to operating systems, then to virtual machines and containers, all to abstract away the underlying volatility. Now we are doing it with intelligence. We are trying to containerize "smartness" so we can swap it out without the rest of the system noticing.
That is a great analogy, Corn. And it brings us to that point Daniel made about the GSM networks. In the telecommunications world, we kept two G and three G networks running for decades because there were millions of legacy devices, like smart meters or older car systems, that literally could not be updated. The arc of deprecation was incredibly long because the cost of failure was high and the hardware was fixed. In AI, we don't have that physical constraint, but we do have the "logical" constraint of existing prompts and workflows.
But in AI, everything is software-defined and API-driven. The vendors seem to think that because it is just a line of code for us to change, they can move as fast as they want. But they are ignoring the evaluation cost. This is the part that really bites developers. If I have a complex prompt that I spent three weeks perfecting for Claude three, I can't just copy-paste it into Claude four and assume it works. I have to re-evaluate everything.
That is the hidden tax of AI development. If I switch from Claude three Sonnet to Claude three point five Sonnet, I cannot just assume it works. I have to run a suite of tests. I have to check for regressions. I have to make sure the cost-per-token still fits my business model. If I have to do that every six months, I am spending more time on maintenance than on new features. This is why we are seeing the rise of "Eval-as-a-Service" companies. People are realizing that the only way to survive the arc of deprecation is to have an automated way to verify that the new model isn't hallucinating more than the old one.
I wonder if we will eventually see a middle ground. Maybe something like a long-term support version of a model, similar to how Linux distributions like Ubuntu have LTS releases. You pay a premium, but you get a guarantee that the model will be available and unchanged for three to five years. For a bank or a healthcare provider, that premium would be well worth it for the peace of mind.
I would love to see that, but the pace of hardware improvement makes it tough. If the industry moves from eight-bit quantization to four-bit or some entirely new architecture like state-space models or MAMBA-based architectures, keeping the old transformer-based models running becomes a massive technical debt for the provider. They do not want to be the one still running the vacuum tube equivalent of an AI model when everyone else is on transistors. The energy costs alone would be astronomical. Imagine trying to run a twenty twenty-three era model on twenty twenty-six hardware—it might actually be less efficient than just running a much larger, newer model.
So, for the developer listening to this, what is the best strategy? If you are building today, do you go with the Anthropic approach and just accept the churn, or do you go with the Google approach and hope the dynamic swap doesn't break your app? Or do you just give up and go back to writing regular expressions?
I think the smartest move is to architect for the churn from day one. Do not hard-code model names deep in your application logic. Use environment variables or a configuration service. And honestly, I am becoming a big fan of the proxy layer approach Daniel mentioned. Even if you do not use a third-party tool, building your own internal gateway gives you a level of sovereignty that is vital when the vendors are this volatile. It allows you to be "model agnostic" in a way that protects your business.
It also allows you to do A-B testing. When a new model comes out, you can route ten percent of your traffic to it through your proxy, compare the results, and then decide whether to commit to the migration. It turns a stressful deprecation deadline into a controlled upgrade process. You can actually see if the new model is better for your specific users before you flip the switch for everyone.
Exactly. And let's talk about that safety point again, because I think it is the real reason Anthropic is so aggressive. If you look at the recent developments in jailbreaking models, the older models are much more susceptible. By forcing everyone onto the newer versions, Anthropic is effectively shrinking the attack surface for bad actors who want to use their tech for malicious purposes. It is a forced security update, like when Microsoft finally killed off Windows XP. They aren't doing it to be mean; they are doing it because they don't want to be responsible for the security holes in their old products.
It is a bit paternalistic, though, isn't it? They are saying, we know what is best for your application's safety more than you do. For some developers, that is a feature—they don't want to worry about safety. But for others, it is a bug that disrupts their workflow and forces them to spend money on migration. It is a very different relationship than we have with traditional software vendors.
It is definitely a point of friction. But when you are a company whose entire brand is built on being the responsible AI choice, you cannot afford the headline that says Claude two was used to design a bioweapon because it didn't have the modern safeguards. The reputational risk far outweighs the inconvenience to a few thousand developers. In the twenty twenty-six landscape, "Safety-as-a-Service" is a major selling point, and part of that service is removing the dangerous old tools from the shed.
I also find the phrasing Daniel noted in the documentation funny. The models are not being killed or deleted, they are being "retired" or they "went away." It is very gentle language for what is essentially a breaking change in a production system. It sounds like the model is going to a nice retirement home in the cloud.
Tech companies love their euphemisms. It makes the transition sound like the model is going to a nice farm upstate where it can run around in the fields and answer prompts about poetry all day. In reality, they are just wiping the weights from the active memory of their server clusters and reclaiming those H-one-hundreds for the next training run. It is a cold, hard calculation of compute-per-dollar.
Going back to the dynamic endpoints, I think there is a middle path that Google could take, and maybe they already do this to some extent. What if the Latest endpoint had a grace period? When a new model is released, Gemini Flash Latest points to the new one, but you can still access the previous Latest for another ninety days. That gives you the convenience of the dynamic pointer but with a buffer for testing. It seems like a reasonable compromise between the two extremes.
That would be the ideal. And actually, if you look at how some other API providers handle versioning, like Stripe, they have this incredibly elegant system where your API version is locked to the date you created your account, but you can manually upgrade it whenever you are ready. AI is just moving too fast for that kind of multi-year stability right now. Stripe deals with structured data; AI deals with the messy, unpredictable nature of human language. You can't "version" a personality or a reasoning style as easily as you can version a JSON schema.
It really highlights how different AI is from traditional software. In a normal API, the contract is the schema. As long as the JSON structure stays the same, the code works. In AI, the contract is the behavior, which is much harder to define and much easier to break. We are moving from "Deterministic Programming" to "Probabilistic Orchestration," and our tools haven't quite caught up yet.
That is a profound point, Corn. The input and output types might be identical—both might be strings—but if the semantic meaning of the response changes, the API is broken. This is why we need better tools for automated evaluation. We need a way to say, "this new model is ninety-five percent similar to the old one for my specific use case, so it is safe to switch." We need "Unit Tests for Meaning."
And those tools are being built, but they are still in their infancy. It feels like we are in the wild west phase where the infrastructure is being built while we are already driving the stagecoach across the plains. We are trying to build the railroad tracks while the train is already moving at a hundred miles an hour.
Or, to use Daniel's terminology, we are in the high-frequency phase of the arc of deprecation. Eventually, things will settle. We will reach a point where the gains from one model to the next are incremental rather than revolutionary, and then the sunset dates will start to move further out. But for the next few years, I think we just have to get used to the emails. We have to build "migration" into our weekly sprints.
It is a good reminder to keep your code modular. If your AI logic is tangled up with your UI logic and your database logic, these deprecations are going to be a nightmare. But if you treat the AI as a swappable component—a microservice that just happens to be hosted by Anthropic or Google—it is just another part of the maintenance cycle. It is the "AI-as-a-Service" equivalent of rotating your API keys.
A very frequent maintenance cycle. But hey, that is the price of being at the cutting edge. If you wanted stability, you would be writing COBOL for a bank. Although, to be fair, even the banks are panicking right now. I was talking to a friend who works in fintech, and they are terrified of these nine-month windows. They have compliance processes that take six months just to approve a new software version. By the time they approve Claude three, it is already being retired.
That is a hilarious and terrifying image. The bureaucracy of the old world colliding with the velocity of the new world. Something has to give. Either the institutions have to become more agile, or the AI providers have to start offering those "Legacy Support" tiers we talked about. I suspect we will see a bit of both.
My bet is on the middleware. I think we will see a huge rise in companies that act as the shock absorbers between the fast-moving AI labs and the slow-moving enterprise world. They will take on the burden of the deprecation cycle so their customers do not have to. They will say, "Pay us a subscription, and we will guarantee that your 'Billing Assistant' prompt works for the next three years, regardless of what Anthropic or Google does." They will handle the prompt engineering and the model routing behind the scenes.
That makes a lot of sense. It is a classic business opportunity, solving the friction created by rapid innovation. It is the "Managed Service" model applied to LLMs.
Exactly. And speaking of friction, I think it is important for us to acknowledge that for many developers, this is not just an intellectual exercise. It is real work. When Daniel says he gets those emails, I can hear the sigh in his voice. It is another task on the to-do list that does not actually add a new feature for the end-user. It is "Red Queen" development—running as fast as you can just to stay in the same place.
Right, it is the definition of technical debt. You are paying interest on a choice you made six months ago. But I suppose the counter-argument is that by moving to the new model, you are often getting better performance for a lower cost. So it is not just staying in the same place, it is moving to a more efficient place. If the new model is fifty percent cheaper and twenty percent faster, the migration pays for itself in a few weeks.
If the migration is easy, yes. If it requires a total rewrite of your prompts and a week of manual testing, the cost-savings might take months to break even. It is a complex calculation. And we haven't even talked about the "Prompt Engineering" debt. Some prompts are so finely tuned to the quirks of a specific model that they are essentially non-portable. They are like assembly code written for a specific processor.
I think one of the risks we haven't touched on yet is the loss of specific capabilities. Sometimes an older model has a quirk or a specific way of reasoning that actually works better for a niche task. Maybe it was better at a specific dialect or a very obscure coding language. When that model is sunset, that capability might just vanish, even if the new model is better at everything else. We call this "Model Collapse" in specific domains.
That is the regression risk. We see it all the time in benchmarks. A model gets better at coding but worse at creative writing, or better at math but more prone to hallucinating in legal contexts. If your business depends on that one specific thing it got worse at, you are in trouble. This is why you need your own private benchmark suite. You can't rely on the generic benchmarks the labs publish. You need to know how the model performs on your data.
This is why having a diverse set of models is so important. If Anthropic sunsets a model you love, maybe there is a version of Llama or a Gemini model that fills that gap. But that brings us back to the importance of proxy layers that allow you to switch providers entirely. You don't want to be "vendor-locked" into a deprecation cycle you can't control.
It really all comes back to flexibility. In the AI era, the most valuable architectural trait is the ability to change your mind quickly. If you are rigid, you will break. If you are fluid, you can flow from one model to the next as the landscape shifts.
That is a great takeaway. Do not fall in love with a specific model. Fall in love with the problem you are solving, and treat the models as temporary tools. They are like sandpaper—you use them until they are worn out, and then you grab a new sheet.
Precisely. And honestly, I think we should be grateful that the models are improving this fast. It is a high-class problem to have. I would much rather deal with a deprecation email for a model that is being replaced by something twice as good than be stuck with the same mediocre tech for a decade. We are living through the most rapid period of technological advancement in human history. A little bit of maintenance work is a small price to pay for a front-row seat.
Fair point. It is the pulse of progress. It just happens to be a very fast pulse. It keeps us on our toes.
A resting heart rate of two hundred beats per minute. It is exhausting, but it is never boring.
Exactly. Well, I think we have covered the arc of deprecation pretty thoroughly. From the safety motivations of Anthropic to the enterprise-friendly dynamic endpoints of Google, and the vital role of middleware in keeping it all manageable. It is a brave new world of versioning.
It is a landscape that is still being mapped, but the main lesson is clear: build for change, because it is the only constant in this field. If you are building for stability, you are building on sand. If you are building for agility, you are building on a surfboard.
Well said, Herman. And to our listeners, we would love to hear how you are managing these transitions. Are you using proxy layers? Are you sticking with one provider and just riding the wave? Let us know. If you are enjoying the show, a quick review on your podcast app or a rating on Spotify really helps us reach more people who are navigating these same weird prompts.
It really does. You can find all our past episodes, including our deep dives into model evaluations and the economics of inference, at myweirdprompts dot com. There is a search bar there that makes it easy to dive into our archive and find exactly what you need for your current project.
And if you want to get in touch or send us a prompt of your own, you can use the contact form on the website or email us at show at myweirdprompts dot com. We are available on Spotify, Apple Podcasts, and pretty much everywhere you get your audio fix.
Thanks for joining us for Episode seven hundred and ninety-five. We will be back soon with another deep dive into the world of human-AI collaboration.
Until then, keep your code modular and your prompts flexible. This has been My Weird Prompts.
Goodbye everyone.
Goodbye.
