15 AI models hit end-of-life in the next 90 days — the full table

ineering resilience requires moving beyond simple ID swaps to a lifecycle-aware architecture.

Core Solution

To mitigate EOL risks, implement a Model Lifecycle Manager that abstracts model selection, enforces pinning, and integrates with CI/CD pipelines. This approach decouples business logic from provider-specific IDs and provides a single point of control for migrations.

Architecture Decisions

1. Configuration-Driven Routing: Model IDs should never be hardcoded in business logic. Use a configuration file or environment variables to map logical roles (e.g., chat_primary, code_assistant) to concrete model IDs.
2. Explicit Pinning: Always pin to specific model versions. Avoid floating aliases unless the use case is strictly experimental and can tolerate behavioral drift.
3. Tokenizer Awareness: Incorporate tokenizer versioning into the configuration to detect and warn about efficiency changes during migrations.
4. CI/CD Integration: Automate checks against provider EOL lists to fail builds if deprecated models are detected in configuration.

Implementation: TypeScript Model Lifecycle Manager

The following implementation provides a robust abstraction layer. It includes a registry, deprecation warnings, and a mechanism to route requests to replacements.

// model-registry.ts

export type Provider = 'openai' | 'deepseek' | 'mistral' | 'anthropic' | 'alibaba' | 'amazon';

export interface ModelDefinition {
  id: string;
  provider: Provider;
  status: 'active' | 'deprecated' | 'eol';
  replacementId?: string;
  tokenizerVersion: string;
  maxContextTokens: number;
  eolDate?: string;
}

export class ModelLifecycleManager {
  private registry: Map<string, ModelDefinition>;

  constructor() {
    this.registry = new Map();
  }

  register(modelKey: string, definition: ModelDefinition): void {
    this.registry.set(modelKey, definition);
  }

  resolve(modelKey: string): ModelDefinition {
    const model = this.registry.get(modelKey);
    if (!model) {
      throw new Error(`Model key '${modelKey}' not found in registry.`);
    }

    if (model.status === 'deprecated' && model.replacementId) {
      console.warn(
        `DEPRECATION WARNING: Model '${model.id}' is deprecated. ` +
        `Routing to replacement '${model.replacementId}'. ` +
        `EOL Date: ${model.eolDate}.`
      );
      return this.resolve(model.replacementId);
    }

    if (model.status === 'eol') {
      throw new Error(
        `Model '${model.id}' has reached end-of-life. ` +
        `No replacement available. Immediate migration required.`
      );
    }

    return model;
  }

  getDeprecationReport(): ModelDefinition[] {
    return Array.from(this.registry.values()).filter(
      m => m.status === 'deprecated' || m.status === 'eol'
    );
  }
}

// Usage Example
const manager = new ModelLifecycleManager();

manager.register('chat_primary', {
  id: 'claude-opus-4-1',
  provider: 'anthropic',
  status: 'deprecated',
  replacementId: 'claude-opus-4-8',
  tokenizerVersion: 'v4.1',
  maxContextTokens: 200000,
  eolDate: '2026-08-05'
});

manager.register('claude-opus-4-8', {
  id: 'claude-opus-4-8',
  provider: 'anthropic',
  status: 'active',
  tokenizerVersion: 'v4.8',
  maxContextTokens: 200000
});

// Resolve with automatic routing and warning
const activeModel = manager.resolve('chat_primary');
console.log(`Resolved to: ${activeModel.id}`);

Rationale

• ModelDefinition Interface: Captures metadata essential for migration, including tokenizerVersion and maxContextTokens. This enables detection of the Anthropic tokenizer shift and context window changes.
• resolve Method: Centralizes logic for handling deprecations. It emits warnings for deprecated models and throws errors for EOL models, preventing silent failures.
• Registry Pattern: Allows the application to load model configurations from external sources (e.g., JSON, YAML, or remote config), facilitating updates without code deployments.

Pitfall Guide

Based on production experience and the current EOL data, avoid these common mistakes:

1. The Alias Mirage

   • Explanation: Using floating aliases like deepseek-chat or mistral-medium-latest assumes stable behavior. Providers can redirect these aliases to entirely new models, as seen with DeepSeek's aliases resolving to deepseek-v4-flash.
   • Fix: Pin all production calls to concrete model IDs. Use aliases only in development environments where drift is acceptable.

2. Ignoring Tokenizer Changes

   • Explanation: Migrations often involve tokenizer updates. The Anthropic claude-opus-4-1 to claude-opus-4-8 shift increases token usage by 30–35%. This can break context limits and inflate costs.
   • Fix: Benchmark token usage for representative prompts before migrating. Update cost models to reflect the new tokenizer efficiency.

3. Assuming Drop-in Compatibility

   • Explanation: Not all replacements are functionally equivalent. OpenAI's sora-2 has no successor, and Mistral's mistral-nemo to ministral-3-8b-latest may involve capability regression due to model size differences.
   • Fix: Identify models with no successors early. For capability shifts, run regression tests on quality metrics, not just API success rates.

4. Context Window Mismatch

   • Explanation: New models may have different context limits. Migrating to a model with a smaller context window can cause input truncation and degraded output quality.
   • Fix: Validate that the replacement model's maxContextTokens meets the requirements of your application. Implement chunking or summarization strategies if limits decrease.

5. Hardcoded Model IDs

   • Explanation: Embedding model IDs directly in business logic (e.g., openai.chat.completions.create({ model: 'gpt-5' })) makes migrations difficult and error-prone.
   • Fix: Use a configuration-driven approach. Map logical roles to model IDs in a central config file, and inject these values via environment variables or a config service.

6. Late Migration Testing

   • Explanation: Waiting until the EOL date to test replacements leaves no time to address issues like cost spikes or quality degradation.
   • Fix: Test replacements at least 30 days before the EOL date. Include replacement models in your CI/CD pipeline for continuous validation.

7. Cost Blindness

   • Explanation: Focusing solely on price-per-token ignores total cost per task. Tokenizer changes, output length variations, and retry rates can significantly impact overall spend.
   • Fix: Calculate cost per task or per successful outcome. Monitor total spend during migration phases to detect anomalies.

Production Bundle

Action Checklist

• Audit Model Usage: Scan the codebase for all model IDs and aliases. Create an inventory of models in use.
• Pin Model IDs: Replace all floating aliases with concrete model IDs in production configurations.
• Implement Lifecycle Manager: Deploy the ModelLifecycleManager or equivalent abstraction to centralize model routing.
• Benchmark Replacements: Test named replacements for cost, token usage, and quality at least 30 days before EOL dates.
• Update Cost Models: Adjust cost projections to account for tokenizer changes and context window differences.
• Configure CI/CD Checks: Add automated checks to fail builds if deprecated or EOL models are detected in configuration.
• Monitor EOL Alerts: Subscribe to provider deprecation notices and integrate alerts into your monitoring dashboard.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
High-Volume Production	Abstracted Registry with Pinned IDs	Ensures stability, predictability, and centralized control over migrations.	Higher initial dev overhead; lower long-term risk and cost variance.
Rapid Prototyping	Floating Aliases Allowed	Maximizes speed and access to latest features; drift is acceptable.	Low dev cost; high risk of unexpected behavior changes.
Cost-Sensitive Workloads	Pinned IDs with Tokenizer Benchmarking	Prevents cost spikes from tokenizer shifts and enables precise budgeting.	Moderate dev cost; ensures cost predictability.
Video/Media Pipelines	Early Migration Scoping	Models like sora-2 have no successors; requires architectural rework.	High migration cost; must be scoped immediately to avoid service gaps.

Configuration Template

Use this YAML template to define model configurations. This structure supports role-based mapping, pinning, and deprecation metadata.

# model-config.yaml
models:
  chat_primary:
    provider: anthropic
    id: claude-opus-4-1
    status: deprecated
    replacement_id: claude-opus-4-8
    tokenizer_version: v4.1
    max_context_tokens: 200000
    eol_date: "2026-08-05"
    pin: true

  code_assistant:
    provider: openai
    id: gpt-5-codex
    status: deprecated
    replacement_id: gpt-5.5
    tokenizer_version: v5
    max_context_tokens: 128000
    eol_date: "2026-07-23"
    pin: true

  video_gen:
    provider: openai
    id: sora-2
    status: eol
    replacement_id: null
    eol_date: "2026-09-24"
    pin: true
    notes: "No drop-in successor. Migration required."

  embedding_model:
    provider: alibaba
    id: qwen3-max
    status: deprecated
    replacement_id: qwen3.7-max
    tokenizer_version: v3
    max_context_tokens: 131072
    eol_date: "2026-09-08"
    pin: true

Quick Start Guide

1. Scan and Inventory: Run a script to extract all model IDs from your codebase and configuration files. Compare against the EOL list to identify at-risk models.
2. Create Configuration: Define your model roles and IDs in a model-config.yaml file. Pin all production models and include deprecation metadata.
3. Deploy Abstraction: Integrate the ModelLifecycleManager into your application. Replace direct SDK calls with calls routed through the manager.
4. Enable CI Checks: Add a pre-commit or CI step that validates the configuration against provider EOL lists. Fail the build if deprecated models are detected.
5. Test Replacements: Schedule testing for all deprecated models. Benchmark cost, token usage, and quality. Update configurations to point to replacements once validated.