Skip to content

Add retirement_date field and backfill it across all first-party labs - #1923

Closed
Tangerg wants to merge 2 commits into
anomalyco:devfrom
Tangerg:add-model-retirement-dates
Closed

Add retirement_date field and backfill it across all first-party labs#1923
Tangerg wants to merge 2 commits into
anomalyco:devfrom
Tangerg:add-model-retirement-dates

Conversation

@Tangerg

@Tangerg Tangerg commented Jun 1, 2026

Copy link
Copy Markdown

Summary

Implements the feature proposed in #1921: there was no way to record when a model stops being served by the provider — only that it is deprecated.

Why a separate retirement_date? Isn't status = "deprecated" enough?

No — they describe two different things, and providers treat them as two distinct events:

  • Deprecated = announced, no longer recommended, but still callable.
  • Retired / shutdown = actually removed; requests after this date fail.

Every major lab publishes both a deprecation announcement and a later shutdown date, with a deliberate migration buffer in between. For example, OpenAI's 2026-04-22 notice:

Deprecated (announced) Shutdown date Model
2026-04-22 2026-07-23 computer-use-previewgpt-5.4-mini

That ~3-month gap is the window developers get to migrate. status = "deprecated" alone tells you a model is on its way out but not when it actually disappears — which is exactly the information consumers need to plan migrations, warn users, or hide soon-dead models.

So this PR keeps the two orthogonal:

  • status = "deprecated" → the lifecycle state (announced, still served).
  • retirement_date → the date it is (or was) shut off.

A model can be deprecated today with a future retirement_date (still usable, but scheduled to die), e.g. gpt-3.5-turbo → 2026-10-23. No new status value is introduced; the existing deprecated is reused. OpenAI calls this the "shutdown date" and Anthropic the "retirement date"; retirement_date was chosen as the neutral name.

What's in this PR

  1. Schema (packages/core/src/schema.ts) — adds an optional retirement_date field, same ^\d{4}-\d{2}(-\d{2})?$ format as release_date / last_updated.
  2. Docs — updates the field reference + example TOML in README.md and the field table in AGENTS.md.
  3. Data — backfills 49 canonical first-party models across every lab in the repo that publishes an official retirement/deprecation schedule.

The field flows through to api.json automatically, and all mirror/aggregator providers (Vertex, Bedrock, OpenRouter, Vercel, Azure, …) inherit it via symlinks and extends.

Convention

  • retirement_date is set whenever the provider publishes an official date.
  • status = "deprecated" is set only when the model is already retired or clearly superseded. Still-active models that merely have a future published date get retirement_date without a status change.

Coverage by provider (official sources only)

Provider Models updated Source
OpenAI 6 (gpt-3.5-turbo, gpt-4, gpt-4-turbo, gpt-4o-2024-05-13, o1-preview, o1-mini) https://developers.openai.com/api/docs/deprecations
Anthropic 9 (claude-3*, claude-3-5*, claude-3-7-sonnet, claude-sonnet-4-20250514, claude-opus-4-20250514) https://platform.claude.com/docs/en/about-claude/model-deprecations
Google (Gemini) 11 https://ai.google.dev/gemini-api/docs/deprecations
Mistral 14 legacy models https://docs.mistral.ai/getting-started/models/
Cohere 2 (c4ai-aya-expanse-8b, c4ai-aya-vision-8b → 2026-04-04) https://docs.cohere.com/docs/deprecations
DeepSeek 2 (deepseek-chat, deepseek-reasoner → 2026-07-24) https://api-docs.deepseek.com/updates
Moonshot / Kimi 5 (kimi-k2-* → 2026-05-25) https://platform.kimi.ai/docs/models

Checked, no official retirement schedule for tracked models (left unchanged)

xAI (Grok), Perplexity (Sonar), Alibaba (Qwen / Model Studio), Amazon Bedrock, NVIDIA, Zhipu (GLM), StepFun, MiniMax, Upstage, Sarvam. For these, the provider either publishes no formal schedule, or the only dated retirements concern model IDs not tracked in this repo.

Notes for reviewers

  • Only canonical first-party model files were edited; mirrors inherit automatically.
  • Google publishes shutdown dates explicitly framed as the earliest possible retirement; they're included as the official published value.
  • Partner platforms (Amazon Bedrock, Vertex AI) set their own schedules per Anthropic's docs; the symlinked mirrors currently inherit the canonical dates, consistent with how cost/limits are already mirrored. Happy to special-case if maintainers prefer.
  • Field name retirement_date is open to bikeshedding.

Validation

bun run validate passes; retirement_date is present in the generated output for the affected models and their mirrors.

Adds an optional `retirement_date` field to the model schema (same
YYYY-MM / YYYY-MM-DD format as release_date/last_updated) so the
database can record when a model stops being served, not just that it
is deprecated. OpenAI calls this the "shutdown date" and Anthropic the
"retirement date"; the existing `status = "deprecated"` lifecycle value
is reused unchanged.

Backfills 15 first-party OpenAI and Anthropic models from official
sources (OpenAI deprecations page and Anthropic model deprecations
page). Wrapper/mirror providers inherit the dates automatically via
symlinks and `extends`.

Docs updated: README field reference + example, AGENTS.md field table.

Refs anomalyco#1921

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Tangerg
Tangerg force-pushed the add-model-retirement-dates branch from 1dc0b7d to 0f899d7 Compare June 1, 2026 02:40
@Tangerg Tangerg changed the title Add retirement_date field and backfill retired/deprecated models Add retirement_date field and backfill deprecated models Jun 1, 2026
Extends the retirement_date coverage beyond OpenAI/Anthropic to every
other first-party lab in the repo that publishes an official model
deprecation/retirement schedule:

- Google (Gemini): 11 models, from ai.google.dev deprecations page
  (these are Google's "earliest possible" shutdown dates)
- Mistral: 14 legacy models, from docs.mistral.ai models page
- Cohere: aya-expanse-8b / aya-vision-8b (retired 2026-04-04)
- DeepSeek: deepseek-chat / deepseek-reasoner (discontinued 2026-07-24)
- Moonshot/Kimi: 5 kimi-k2 models (discontinued 2026-05-25)

status = "deprecated" is set for models already retired or clearly
superseded; still-active models with only a future earliest-possible
date get retirement_date without a status change. Mirror/aggregator
providers inherit via symlinks and extends.

Providers checked with no official retirement schedule for tracked
models (left unchanged): xAI, Perplexity, Alibaba/Qwen, Amazon Bedrock,
NVIDIA, Zhipu/GLM, StepFun, MiniMax, Upstage, Sarvam.

Refs anomalyco#1921

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Tangerg Tangerg changed the title Add retirement_date field and backfill deprecated models Add retirement_date field and backfill it across all first-party labs Jun 1, 2026
@LaOzhOy1

LaOzhOy1 commented Jun 1, 2026

Copy link
Copy Markdown

Strong +1. Keeping retirement_date orthogonal to status = "deprecated" is the key insight here — "announced but still callable" and "actually shut off" are genuinely different states, and only the latter is a hard deadline. The 3-month OpenAI example in the description makes the case well. Backfilling from official provider pages (rather than guessing) is exactly the right level of rigor for this repo.

@rekram1-node

Copy link
Copy Markdown
Collaborator

This isn't something i have bandwidth to keep up to date rn

@rekram1-node

Copy link
Copy Markdown
Collaborator

so as of now this isn't something im looking to merge

@rekram1-node

Copy link
Copy Markdown
Collaborator

but long term this would be good to have

@Tangerg

Tangerg commented Jun 16, 2026

Copy link
Copy Markdown
Author

@rekram1-node Totally understand the bandwidth concern — keeping retirement dates current is real ongoing work, and that's exactly what I'm offering to take on.

I'm not just proposing this in the abstract: I already consume models.dev downstream to generate the per-model catalog in my own project (lynx), where I map your status == "deprecated", release_date, last_updated, etc. into my runtime metadata. So I'm already tracking model lifecycle data by hand — wiring up retirement_date and keeping it fresh is genuinely low marginal effort for me.

Concretely, I'm happy to:

  • Backfill the field from official provider EOL/retirement pages (sourced, not guessed — as in this PR).
  • Watch the provider deprecation pages and send periodic follow-up PRs as new retirement dates get announced, so it doesn't land on you to chase.

Since it's kept orthogonal to status/deprecated and is purely additive, it shouldn't add maintenance surface for the core repo — happy to be the person who keeps it accurate. Glad to adjust the schema/approach if you'd prefer it shaped differently.

@surxme

surxme commented Jun 16, 2026

Copy link
Copy Markdown

need this too. 😭

@github-actions

Copy link
Copy Markdown
Contributor

Closing this pull request as stale because it has not been updated in 7 days after feedback from @rekram1-node. Feel free to reopen it or submit a new pull request if the work is resumed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants