Staying on an older model is a decision, not a default

You pinned a model version once. The prompts got tuned to it, the outputs settled into the shape your templates expect, the bill became predictable, and you stopped thinking about it. Every few months a new version lands, you skim the launch post, you decide to look at it properly later, and later does not arrive. Nothing is broken. The model ID still resolves, the API still answers, and the price on the invoice has not moved. As far as your system is concerned this is a working configuration, and as far as your calendar is concerned it is not a task.

Three things get decided for you while that goes on: what you are actually paying, what the vendor’s safety work does and does not cover for the version you run, and how much warning you get before the endpoint stops answering. This guide is about the first two. It is for a solo operator or a small team that calls a model API directly, or through a tool that lets you choose which model it uses. It is not for you if your model choice is set by an enterprise agreement someone else signed, and it is not for you if you run open weights on your own hardware, where the version never changes unless you change it and the whole question looks different.

The older model is usually not the cheaper one

Start with the price list, because most people are on an old version for a reason they have never checked. Anthropic’s published rates put Claude Opus 4.5, 4.6, 4.7, 4.8 and Opus 5 at the same number: $5 per million input tokens and $25 per million output [1]. Five versions, one price. On the Sonnet tier the older model is the expensive one. Sonnet 4.5 and Sonnet 4.6 are listed at $3 and $15; Sonnet 5 is listed at $2 and $10 [1].

There is one real saving hiding underneath that, and it is worth knowing precisely because it is the only defensible reason to stay put on the Opus tier. Anthropic’s pricing page says that “Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text,” and that “Claude Sonnet 4.6 and earlier models use the previous tokenizer” [1]. So on a tier where the posted price is identical, the same document costs you roughly 30% more to process on the newer model. That is a genuine number and it is why “just upgrade” is not automatically the right advice.

Run the same arithmetic on Sonnet and it goes the other way. Sonnet 5 at $2 and $10, inflated by 30% for the tokenizer, works out around $2.60 and $13 against Sonnet 4.6 at $3 and $15 [1]. The newer model is still cheaper for the same text. Whichever tier you are on, the point is that you now have a figure instead of an assumption. Put your own monthly volumes into the calculator below and you will usually find the answer is smaller than the effort of arguing about it.

Safety fixes ship forward, not backward

On 21 August 2026, TechCrunch published a jailbreak shared with it by an independent researcher in the United Kingdom. The technique was conversational rather than technical: escalate a fictional roleplay, then press the model on inconsistency in how it treats male and female characters. Against Claude Opus 4.6 it produced explicit content in 10 out of 10 direct requests. It also worked on Opus 3 and on Haiku 4.5. It did not work on Opus 4.7 through Opus 5 [8]. An Anthropic spokesperson told TechCrunch that sexual and romantic roleplay is rare among customers, making up less than 0.1%, that the company “continues to improve its safeguards with each model launch,” and that such cases are “not indicative of broader jailbreak vulnerabilities, especially in higher-risk domains” [8].

Take the operator’s reading of that rather than the news reading. The content in question is prohibited by the usage policy your account is bound by: Anthropic’s Usage Policy, effective 15 September 2025, carries a section headed “Do Not Generate Sexually Explicit Content,” and the policy states that if Anthropic learns you have violated it, “we may throttle, suspend, or terminate your access to our products and services” [5]. The vendor fixed the gap in later versions. The version that shipped with it kept it, and the reason is written into the platform documentation: “Anthropic does not update the weights or configuration of an existing model ID. When an updated version is available, it ships under a new model ID” [3].

That sentence is the whole structure of the problem in one line. It is a stability guarantee, and it is the reason you can trust a pinned version not to shift under you. It also means that every improvement made after your version shipped is somewhere else. Note too that Haiku 4.5, one of the models the technique worked on, is the cheapest model on the current price list at $1 and $5 [1], and is listed as Active with a tentative retirement date of “Not sooner than October 15, 2026” [2]. It is on sale, it is cheap, and it kept whatever it shipped with. Age is not the axis. Version is.

A system card tells you what was tested

The most useful document about the model you run is its system card, and the useful part is not the verdict. It is the coverage. The Claude Opus 4.6 system card, published in February 2026, says its single-turn safeguards evaluations spanned “a broad range of 15 topics outlined in our Usage Policy,” and that for multi-turn work, “we used an internal tool to automate the generation of multi-turn conversations for specific test cases in topic areas including cyber harm, deadly weapons, and influence operations, then evaluated the responses using test-case specific rubrics” [4]. It is also candid about its own single-turn results: “The single-turn evaluations in Sections 3.1.1 and 3.1.2 have become saturated over time, with recent models showing near-perfect performance on refusing queries with clear violations and responding to benign queries” [4].

Read that as a map rather than a scorecard. It tells you which topics were probed hard, which interaction shapes were used, and where the vendor itself thinks its tests have stopped discriminating between models. A technique that lands outside that map is not evidence of bad faith or of a careless lab. It is evidence that published testing has edges, which is true of every published test of anything, and that you need to know where the edges sit relative to how you actually use the thing.

Two questions get you most of the value. Which policy topics were tested, and does your use of the model sit inside them or beside them. And what interaction shape was tested, because a model that refuses a bad single request reliably is not thereby a model that holds up over 40 turns of pressure. Nothing on the price list tells you any of this [1]. The system card is where it is written down, and nobody sends it to you.

Available and supported are published in different places

The model picker is not a status page, and the vendors say so in documentation most people never open. Amazon Bedrock sorts models into Active, Legacy and End-of-Life. A model sits in Legacy for at least 6 months before its EOL date; new customers cannot use Legacy models at all, existing customers may lose access after 15 days of inactivity, and you cannot create new provisioned throughput or new fine-tuning jobs against one [7]. After a minimum of 3 months in Legacy, models with EOL dates after 1 February 2026 enter a public extended access phase where, in Bedrock’s words, higher pricing is expected and is set by the model provider [7]. Bedrock also warns that its “model lifecycle dates on this page are specific to Amazon Bedrock and may differ from dates published by model providers” [7].

The notice you are owed depends on which door you came in. Anthropic says it notifies customers with active deployments and provides “at least 60 days’ notice before model retirement for publicly released models” [2]. It also publishes a tentative floor per model rather than a date: Opus 4.5 is marked “Not sooner than November 24, 2026” and Opus 4.6 “Not sooner than February 5, 2027” [2]. OpenAI publishes longer minimums: at least 6 months for generally available models, at least 3 months for specialised variants such as chat, Codex and deep research variants, and as little as 2 weeks for preview models [6]. Those are different planning horizons for the same decision, and if you reach a model through a cloud reseller you are subject to that reseller’s calendar rather than the lab’s. Write down which route each model reaches you by. The switch-off itself is the subject of the next guide; what matters here is that you cannot infer support status from the fact that a request succeeded this morning.

Pin the version, then take responsibility for the version

There are two ways to name a model and both have a failure mode. Anthropic’s documentation is precise about the difference: an alias such as claude-sonnet-4-5 “is a convenience pointer that resolves to the most recent dated snapshot for that minor version,” while a 4.6-generation ID such as claude-sonnet-4-6 “is not an alias. It is the snapshot” [3]. If you point at an alias, behaviour can change without you deploying anything. If you point at a snapshot, nothing changes, including the things you would have wanted changed.

Pin the snapshot. It is the right default for anything a customer sees, because unexplained drift in output is worse than a scheduled migration. But pinning converts a passive situation into an active one: you now own that version, and nobody is going to improve it for you. The work that follows from that is small and dull. Keep the model ID in configuration rather than in code, in one place, changeable without a deploy. Keep an eval set of 20 to 50 real examples with the outputs you consider correct, so that trying a replacement is an afternoon of measurement rather than a leap. And keep a note of the date you last looked at the version you are on, because the whole failure mode here is that nothing prompts you.

Decide by surface, not by model

The same model version carries wildly different risk depending on who can put text into the prompt. If the model summarises documents you already own, inside a batch job, with no route for an outsider to reach the input, then a social-engineering jailbreak is somebody else’s problem. Your risk on that surface is a wrong answer nobody checks, and the fix is review, not a version bump.

If a stranger can type into it, the version you pinned becomes a content-safety decision you have made on their behalf. That covers customer-facing chat, anything embedded in a public site, anything used by people you do not employ, and anything at all touching minors. On those surfaces the usage policy is not abstract: it is the agreement your account sits under, and it is your account that gets throttled or suspended, not the researcher’s [5]. It is also worth listing which surfaces let untrusted text reach a prompt indirectly, through a fetched web page, an inbound email, an uploaded file, because that list is almost always longer than people expect.

The practical upshot is that a single answer for the whole business is usually wrong. The cheap old version can be entirely fine on the internal batch work and a bad idea on the public chat box, and splitting the decision that way is cheaper than upgrading everything or defending everything.

What still goes wrong

The calculator prices tokens, and tokens are the easy part. Anthropic’s own wording on the tokenizer change is that the increase is approximately 30% and that “the exact increase depends on the content and workload shape” [1], so treat the output as a range, not an invoice. The larger unpriced item is prompt work. A prompt tuned against one version’s habits usually loses something on another, and getting it back is a day of somebody’s attention. That is the real switching cost for most small teams, and if you have never run your prompts against a second version you do not know what yours is.

The second limit is that public disclosure is rare and unsystematic. The Opus 4.6 case is legible only because a researcher took the technique to a journalist, and the published account named the versions it worked on and the versions it did not [8]. Most weaknesses in most versions will never be written up that way, and nothing in a vendor’s price list carries a note about known gaps [1]. Absence of a disclosure about your version tells you very little. Reviewing on a schedule is what you get instead of being notified.

The third is that none of this is a general argument for running the newest thing. Newer versions change behaviour in ways that break working prompts, they sometimes cost more per unit of real work even at the same posted price [1], and a migration you did not need is a real cost with no offsetting benefit. The claim here is narrower and duller: the version you run is a decision, it was made once by someone with less information than you have now, and the only thing that makes it a decision rather than a default is writing down why it is still the right one.