Am 15. Juni 2026 schlagen API-Calls an zwei Claude-Modelle fehl. Kein Fallback, kein automatischer Redirect, kein Gnadenmonat. Hard Stop.

Anthropic hat am 14. April 2026 die Deprecation von claude-sonnet-4-20250514 und claude-opus-4-20250514 angekündigt — und damit eine 60-Tage-Frist gesetzt. Das klingt lang. Bis kurz vor Deadline, wenn alle gleichzeitig migrieren, klingt es kurz.

Dieser Guide zeigt dir, was du tun musst — in unter 30 Minuten erledigt.

Welche Modelle sind betroffen?

Altes Modell (deprecated)RetirementNachfolger
claude-sonnet-4-2025051415. Juni 2026claude-sonnet-4-6
claude-opus-4-2025051415. Juni 2026claude-opus-4-6

Was “Retirement” bedeutet: Nach dem 15. Juni 2026 liefert die Anthropic API bei Calls mit diesen Modell-IDs einen Fehler zurück. Kein Soft-Deprecation, kein “noch 90 Tage mit Warnung” — die Modelle werden abgeschaltet.

Wichtig: Anthropic gibt nach eigener Policy immer mindestens 60 Tage Vorlauf vor einem Retirement. Das wurde eingehalten. Es gibt keinen Grund, bis zum letzten Tag zu warten.

Warum jetzt migrieren, nicht kurz vor Deadline?

Kurz vor dem 15. Juni werden alle mit demselben Problem beschäftigt sein. Das bedeutet:

  • Support-Queues bei Anthropic und in Community-Foren sind voll
  • Unvorhergesehene Probleme (Verhaltensänderungen des neuen Modells, Prompt-Anpassungen) haben keine Zeit mehr zur Lösung
  • Staging-Tests laufen unter Zeitdruck — Fehler landen in Production

Außerdem: Die Nachfolgemodelle claude-sonnet-4-6 und claude-opus-4-6 sind leistungsfähiger als ihre Vorgänger. Früh migrieren heißt, früher von verbesserter Performance zu profitieren.

Migration in 4 Schritten

Schritt 1: Alle Stellen im Code finden

Suche in deiner gesamten Codebasis nach den betroffenen Strings:

grep -r "claude-sonnet-4-20250514" . --include="*.py" --include="*.js" --include="*.ts" --include="*.env" --include="*.yaml" --include="*.json"

grep -r "claude-opus-4-20250514" . --include="*.py" --include="*.js" --include="*.ts" --include="*.env" --include="*.yaml" --include="*.json"

Typische Fundorte:

  • API-Client-Konfiguration (z.B. anthropic.Anthropic() Initialisierung)
  • Environment-Variablen (.env, .env.production)
  • Konfigurationsdateien (config.yaml, settings.json)
  • Prompt-Templates mit hardgekodeter Modell-ID
  • CI/CD-Pipeline-Configs

Schritt 2: Ersetzen

Altes ModellNeues Modell
claude-sonnet-4-20250514claude-sonnet-4-6
claude-opus-4-20250514claude-opus-4-6

Das ist eine reine String-Ersetzung. Die API-Signatur ändert sich nicht — Parameter, Authentifizierung, Response-Format bleiben identisch.

# Vorher:
client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    messages=[...]
)

# Nachher:
client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[...]
)

Schritt 3: Im Staging testen

Bevor du in Production deployed, teste deine kritischsten Prompts mit dem neuen Modell. Achte auf:

  • Output-Länge und -Format: Neue Modelle können anders formulieren — insbesondere bei stark geskripteten Outputs
  • Reasoning-Tiefe: claude-opus-4-6 ist in komplexen Reasoning-Tasks stärker als sein Vorgänger — prüfe ob sich das auf deine Use Cases auswirkt
  • Kosten: Die neuen Modelle haben möglicherweise leicht abweichende Token-Preise — prüfe deine Anthropic Console

Schritt 4: Anthropic Console prüfen

In der Anthropic Console kannst du:

  • API-Nutzung nach Modell exportieren (CSV) — so siehst du alle Stellen die noch alte Modelle nutzen
  • Aktuelle Preise der neuen Modelle einsehen
  • API-Keys für verschiedene Umgebungen verwalten

Wenn du nach dem Update in der Console keine Calls mehr auf die alten Modelle siehst — bist du fertig.

Was sich mit den neuen Modellen ändert

Die Migration ist nicht nur Pflicht — es gibt auch echte Verbesserungen:

claude-sonnet-4-6 gegenüber dem Vorgänger:

  • Schnellere Antwortzeiten bei langen Kontexten
  • Präzisere Instruction-Following bei komplexen System-Prompts
  • Bessere Code-Generation in neueren Sprach-Versionen (Python 3.13, TypeScript 5.8)

claude-opus-4-6 gegenüber dem Vorgänger:

  • Stärkere Reasoning-Fähigkeiten bei mehrstufigen Problemlösungen
  • Verbesserte Konsistenz bei sehr langen Dokumenten (>100.000 Token)
  • Genauere Quellenangaben bei RAG-Anwendungen

Häufige Stolperfallen

“Ich nutze die API nur über ein Third-Party-Tool”: Prüfe trotzdem, ob das Tool veraltet. Viele No-Code-Plattformen und LangChain-basierte Apps lassen die Modell-ID konfigurierbar. Schau in die Einstellungen.

“Mein Framework wählt das Modell automatisch”: Stimmt manchmal — aber nicht immer. Grep zeigt dir ob irgendwo eine hardgekodete ID steckt.

“Das Verhalten meiner App hat sich leicht verändert”: Neue Modelle formulieren anders. Wenn du sehr spezifische Output-Formate erwartest, passe deine System-Prompts nach. Oft reicht ein minimaler Tweak.

“Ich nutze Prompt Caching — ändert sich da was?”: Prompt Caching funktioniert mit den neuen Modellen genauso. Cache-Prefix-Invalidierung passiert nur wenn du das Modell zur Laufzeit wechselst — plant du das nie gleichzeitig, kein Problem.

Checkliste zur Migration

  • Alle Stellen mit alter Modell-ID via grep gefunden
  • In .env und Konfigurationsdateien ersetzt
  • Im Code ersetzt (alle Sprachen/Dateitypen)
  • In CI/CD-Pipelines ersetzt (wenn relevant)
  • Staging-Test mit kritischen Prompts abgeschlossen
  • Anthropic Console zeigt keine Calls mehr auf alte Modelle
  • Production deployed und 24h beobachtet

Fazit: 30 Minuten Arbeit jetzt, kein Ausfall im Juni

Das ist keine große Migration. Zwei Strings suchen, zwei Strings ersetzen, testen, deployen. Wer das jetzt macht, hat bis Juni Zeit zu beobachten ob sich etwas verändert und ruhig zu reagieren.

Wer es auf den 14. Juni schiebt, arbeitet unter Druck — und Druck erzeugt Fehler.

Heute erledigen. Dann vergessen.

Weiterlesen: