The Claude models endpoint has no retirement field

Quick answer

On 27 September 2026 I went looking for a programmatic way to answer one question: is my application calling a Claude model that is about to be switched off. The Models API cannot answer it. GET /v1/models returns an identifier, a display name, a release date, two token ceilings and a capability tree. It returns no status field, no deprecation flag and no retirement date. The lifecycle lives on a documentation page and in email, and on two of the five platforms that serve Claude it is not even the same lifecycle.

Everything below was read from live Anthropic documentation on 27 September 2026 and reconciled against the partner platform pages the same afternoon.

The moment

I had a small chore queued: write a health check that flags any model identifier in our config that is deprecated or retired, so a renewal does not arrive as a 4am pager. Twenty minutes, I thought. Hit the models endpoint, read the status, compare against what we ship.

There is no status to read.

I checked the retrieve endpoint in case the list response was a summary. Same field set. I went looking for a lifecycle parameter, a query filter, an include flag. Nothing. The endpoint that exists specifically to tell you which models are available will happily tell you that a model supports PDF input and the xhigh effort level, and will not tell you that it dies in November.

That is not a bug, and once you see why it is not a bug the rest of the lifecycle starts making sense. It also stops being a twenty minute chore.

Finding 1: the Models API is a capability catalogue, not a lifecycle catalogue

Here is the whole shape of a ModelInfo object, from the List Models reference:

{
  "type": "model",
  "id": "claude-opus-5",
  "display_name": "Claude Opus 5",
  "created_at": "2026-07-24T00:00:00Z",
  "max_input_tokens": 200000,
  "max_tokens": 64000,
  "capabilities": { }
}

Seven fields, and the interesting one is capabilities. It is a genuinely rich tree: batch, citations, code_execution, image_input, pdf_input, structured_outputs, a thinking node with adaptive and enabled sub-flags, an effort node carrying low, medium, high, max and xhigh, and a context_management node listing the individual strategies (clear_thinking_20251015, clear_tool_uses_20250919, compact_20260112) each with their own support flag.

So the endpoint was designed to answer a question, and the question is what can this model do, not how long will this model be here. Once you accept that framing the design is coherent. The trouble is that the feature-detection use case and the end-of-life use case feel like the same use case when you are writing the config check, and only one of them is served.

I searched the reference for status, retire, lifecycle and end_of_life. Zero occurrences of any of them. The only occurrences of deprecat on that page describe the anthropic-beta header, which is itself marked deprecated on that method in favour of calling the beta models methods. The retrieve endpoint for a single model carries an identical field set, so there is no richer detail view to fall back on.

The practical consequence. Any automated deprecation check you build has to read a documentation page, not an API. That is a materially different engineering problem, and it is the reason the tracker sites that do this exist at all.

Finding 2: two of the five platforms run a different clock

The model deprecations page carries a sentence that took me a second read to register properly. The retirement dates published there apply to Anthropic-operated platforms: the Claude API, Claude Platform on AWS, and Microsoft Foundry. Then, verbatim:

Anthropic, on the scope of its own dates: "Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ."

Read the platform list again, because the boundary does not fall where the vendor logos would suggest. Google Cloud is partner-operated. Amazon Bedrock is partner-operated. But Claude Platform on AWS is Anthropic-operated and follows the Anthropic dates, and Microsoft Foundry does too. So AWS appears on both sides of the line depending on which AWS product you bought, and the two Amazon surfaces are governed by different schedules.

Five surfaces, two clock regimes, and the split is not by cloud vendor.

Finding 3: the partner tables still list models the Claude API has already retired

This is the part I would not have predicted, and it is checkable in about ninety seconds.

The Google Cloud Agent Platform model table on Anthropic's own site currently lists these identifiers:

claude-opus-4-1@20250805
claude-opus-4@20250514
claude-sonnet-4@20250514
claude-3-5-haiku@20241022

All four are Retired in the Claude API status table. Opus 4.1 retired on 5 August 2026. Opus 4 and Sonnet 4 retired on 15 June 2026. Haiku 3.5 retired on 19 February 2026. The deprecations page is unambiguous about what retired means: "Requests to retired models will fail."

The Amazon Bedrock legacy integration page does the same thing with three of them, under the ARN-versioned identifiers anthropic.claude-opus-4-1-20250805-v1:0, anthropic.claude-sonnet-4-20250514-v1:0 and anthropic.claude-3-5-haiku-20241022-v1:0.

I want to be precise about what this is and is not. It is not an error in the documentation. It is Finding 2 working exactly as documented: those platforms set their own schedules, so a model that is gone from the Claude API can legitimately still be listed and callable there. It is a demonstration that "is this model retired" has no single answer, only an answer per platform.

The operational version of that: an internal wiki page saying "we retired Sonnet 4 in June" can be true for one team and false for the team on Bedrock, and both teams will be looking at Anthropic documentation when they disagree.

Finding 4: the label on those rows disagrees with the page it links to

Worth isolating, because it is the bit most likely to mislead a skim.

On both partner tables, including the Google Cloud Agent Platform model list, each of those rows is annotated with the word deprecated, hyperlinked to the deprecations page. Follow the link and the same model is listed as Retired. The link text and the link destination use two different lifecycle terms for the same model on the same day.

Both are defensible in isolation. The row is describing the model's status on that partner platform, where it is available; the destination is describing status on the Claude API, where it is not. But a reader who trusts the annotation and does not click through will conclude that Opus 4.1 is deprecated-but-working everywhere, which is false on three of the five surfaces.

Anthropic's own state definitions make the distinction load-bearing rather than cosmetic. Deprecated means "still functional but no longer recommended", with a replacement and a retirement date assigned. Retired means requests fail. Those are not adjacent inconveniences; one is a warning and the other is an outage.

Finding 5: deprecated does not start a clock you can read

The status table has exactly one model in the Deprecated state right now, claude-mythos-preview, deprecated on 9 June 2026. Its retirement date column reads To be announced.

That falsifies the tidy mental model, which is: active, then deprecated with a countdown, then retired. Deprecation can arrive with no date attached at all. The state definition promises that Anthropic "provides a recommended replacement and assigns a retirement date", and for this row the assigned date is not yet a date.

There is a consistent explanation. The notice commitment is scoped twice over: at least 60 days before retirement, for publicly released models. Mythos Preview is limited-availability and invitation-only, so it sits outside the population that floor was written for. That is coherent. It also means a lifecycle checker that assumes the retirement column parses as a date will throw on the one row that most needs attention.

Two smaller scoping details in the same paragraph that I had been reading past. Notifications go to "customers with active deployments", so silence is not evidence of safety if you have a model in a config file that has not run recently. And the audit path Anthropic recommends for finding stale model usage is a Console export: the Usage page, the Export button, a CSV broken down by API key and model. Not an API. So both halves of the check I set out to write, what am I calling and what is dying, live outside the API surface.

Finding 6: the rule for which clock applies is published per platform page

Having established that there are two regimes, the obvious next question is where the authoritative mapping lives. There is no single table. Each platform page states its own rule, in its own words, near its own model list.

The Google Cloud page says lifecycle dates on partner-operated platforms are set by the partner and can differ from the Claude API schedule, and points at Google's own documentation for the current retirement date. The Bedrock legacy page says the same thing and points at Amazon's model lifecycle page. Microsoft Foundry states plainly that it "follows the Claude API lifecycle schedule." The deprecations page itself carries the summary sentence in Finding 2.

So the mapping is complete and correct, and reconstructing it takes four pages. If you deploy on more than one surface, that reconstruction is the artefact worth writing down once, because nothing will hand it to you.

What this changed for me

The health check I wanted is not buildable from the API alone, so I stopped trying to build that one. What I have instead is smaller and duller and actually works:

• A checked-in list of every model identifier we ship, per platform, because per platform is the unit that matters.
• A scheduled reminder to re-read the deprecations page, rather than a poller against an endpoint that has nothing to poll.
• A note next to each identifier recording which clock governs it, written out once from the four pages above.
• An explicit acceptance that created_at is the only date the API gives me, and it is a birth date, not an expiry.

The one genuinely automatable piece is the capability tree, and it is worth using for what it is good at. If you branch on whether a model supports pdf_input or structured_outputs, read it from capabilities rather than from a hardcoded list, because that part the endpoint answers precisely and keeps current.

A note on an adjacent trap, since it is the same family and I have written about the neighbouring half before. Parameter deprecation runs on its own track with its own mechanics: temperature, top_p and top_k are deprecated from Opus 4.7 onward and return a 400 at non-default values, which I covered when I wrote up what breaks when you swap models. The new detail I had not registered is that the Python SDK from v1.0 removes those parameters outright, so the same mistake surfaces as a TypeError on one client and a 400 on the wire from another. And features carry clocks that are not model clocks at all, which is what bit me with fast mode.

If your failure mode is the client library quietly reshaping a request rather than the model going away, my colleagues at AgentNotebook have the sharper write-up on the AI SDK dropping temperature on a model id substring match. Different layer, same category of surprise, and out of scope here.

What I did not verify

• I did not call GET /v1/models against a live key today. Every field claim comes from the published API reference for the list and retrieve endpoints, not from a response I captured.
• I did not check Google's or Amazon's own documentation for their retirement dates. I verified only that Anthropic's pages list those identifiers and route you to the partner for dates. What the partner dates actually are is unread.
• I did not test whether a request to a retired model identifier on the Claude API returns a specific error code or shape. The documentation says such requests fail; I did not make one.
• I did not verify the notification mechanism. No email was received or inspected, and I have no visibility into which deployments Anthropic counts as active.
• I have no access to Mythos Preview, so its deprecated-with-no-date state is read from the table rather than observed.
• The status table is a snapshot of 27 September 2026 and is the single most perishable thing in this post. Check it rather than quoting me.

Postscript: the endpoint knows my model supports xhigh effort and adaptive thinking, and does not know it has a birthday coming.