4-Stufen-Lebenszyklus-Methodik & offizielle Anbieterquellen

LLMEOL aggregiert ausschließlich dedizierte, öffentlich überprüfbare Abkündigungs- und Lebenszyklusdokumentationen der Anbieter – mit strikter UTC-Datumsarithmetik, vorrangsicherer Katalogzusammenführung und Fail-Closed-Schutz für alle Feeds.

Strikte datumsbasierte 4-Stufen-Klassifikation

Jeder Anbieter verwendet uneinheitliche Begriffe (Legacy, Preview, Deprecating, Retired, EOL). Statt mehrdeutige Warnstufen einzuführen, berechnet LLMEOL einen von vier objektiven Lebenszyklus-Zuständen strikt aus dem bestätigten UTC-Abschaltdatum und bewahrt die Originalbezeichnung des Anbieters in sourceLifecycle:

  • RETIRED (days <= 0): Das bestätigte Abschaltdatum ist in UTC erreicht oder überschritten; API-Aufrufe schlagen typischerweise mit HTTP 404/410 fehl oder werden automatisch auf ein Nachfolgemodell umgeleitet.
  • EXPIRING (1 <= days <= 90): Die bestätigte Abschaltung erfolgt innerhalb der nächsten 90 Kalendertage – das konkrete Migrationsfenster für Produktions-Sprints.
  • DEPRECATED (days > 90): Ein verbindliches Abschaltdatum liegt mehr als 90 Tage in der Zukunft (oder das Modell steht in der offiziellen Tabelle Deprecated Models von Moonshot AI ohne veröffentlichtes Abschaltdatum); nicht mehr für neue Workloads einsetzen und Migration einplanen.
  • ACTIVE (kein exaktes eolDate): Es wurde kein taggenaues Abschaltdatum angekündigt. Mindestlaufzeit-Zusagen wie „no earlier than“ oder „no sooner than“ werden bewusst ignoriert, bis ein verbindliches Datum vorliegt.

10 maßgebliche öffentliche Anbieterquellen zum Modell-Lebenszyklus

Roh-JSON ansehen

Die geplante Synchronisierung läuft alle 12 Stunden. Primäre Abkündigungspläne haben für dasselbe Paar aus (provider, modelId) stets Vorrang vor ergänzenden Katalogen unterstützter Modelle, und eine quellenbezogene Fail-Closed-Aufbewahrung verhindert, dass temporäre Upstream-HTTP-Fehler verifizierte Einträge löschen.

Maßgebliche öffentliche Dokumentations-Endpunkte, die von LLMEOL synchronisiert werden
Anbieterquelle Zusammenführungsrolle Einträge Kanonische Dokumentations-URL
OpenAI primary 173 https://developers.openai.com/api/docs/deprecations
Anthropic primary 38 https://platform.claude.com/docs/en/about-claude/model-deprecations
Google Gemini primary 90 https://ai.google.dev/gemini-api/docs/deprecations
Google Vertex AI (Gemini Models) primary 59 https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/model-versions
Google Vertex AI (Partner Models) primary 9 https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/deprecations/partner-models
AWS Bedrock (Legacy & EOL) primary 56 https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle-legacy.html
Azure OpenAI (Retirement Schedule) primary 164 https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirement-schedule
Moonshot AI (Kimi) primary 21 https://platform.kimi.ai/docs/models#deprecated-models
AWS Bedrock (Model Cards Catalog) supplemental 149 https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html
Azure OpenAI (Foundry Supported Catalog) supplemental 60 https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure

Drei-Säulen-Workflow von CodeAP Studio

Wie greifen LLMEOL, DevToken und ToMarkdown ineinander?

CodeAP Studio vereint drei spezialisierte KI-Engineering-Studios: LLMEOL verfolgt Modellabkündigungen und prüft .env-Configs, DevToken vergleicht Token-Preise für Nachfolgemodelle und generiert MCP-/Zod-Schemas, und ToMarkdown kompiliert PDF-, DOCX- und HTML-Dokumente in RAG-bereites Markdown.

Warum fehlen Aggregatoren ohne öffentliche EOL-Tabellen?

LLMEOL indexiert ausschließlich Anbieter, die dedizierte, ohne Anmeldung zugängliche öffentliche Abkündigungs- oder Lebenszykluspläne pflegen, damit jedes Abschaltdatum auf eine prüfbare Primärquelle verweist.