Überwachung von Deprecations & Migrationen
Modelle werden eingestellt, Parameter umbenannt, Verhaltensweisen ändern sich. Diese Seite verfolgt Breaking Changes, damit Upgrades dich nicht überraschen. Wenn du auf der API aufbaust, überfliege sie regelmäßig.
Warum das wichtig ist
Eine fest verankerte Modell-ID wird irgendwann deprecated und dann entfernt. Code, der sie fest einkodiert, bricht. Ein wenig Hygiene verhindert Überraschungen um 2 Uhr nachts.
Überlebensregeln
- Lies Modell-IDs aus der Konfiguration, verstreue niemals Literale über die Codebasis — dann ist eine Migration eine Änderung von einer Zeile.
- Beobachte Ankündigungen zu Deprecation-Daten und empfohlenen Ersatzoptionen.
- Führe deine Evals erneut aus, wenn du Modelle wechselst — das Verhalten kann sich selbst bei einem „neueren, besseren" Modell verschieben.
- Teste vor der Frist, nicht nach der Entfernung.
Häufige Arten von Änderungen
| Änderung | Beispiel | Was zu tun ist |
|---|---|---|
| Modell eingestellt | Eine ältere Modell-ID funktioniert nicht mehr | Wechsle zum empfohlenen Nachfolger; erneut evaluieren |
| Parameter ersetzt | Ein Reasoning-/Budget-Regler wird durch effort ersetzt | Aktualisiere Aufrufe; siehe Thinking & Effort |
| Verschiebung des Defaults | Ein neues Standardmodell/-verhalten | Pinne bewusst; überprüfe, ob deine Prompts noch funktionieren |
| Endpunkt-/SDK-Update | Neue SDK-Hauptversion | Lies den Migrationsleitfaden; aktualisiere bewusst |
Aktuelle Überwachung
Platzhalter — ersetze ihn durch echte, belegte Deprecation-Hinweise, sobald sie angekündigt werden.
- Bestätige deine Modell-IDs anhand der Tabelle Aktuelle Modelle & Preise; wenn du eine ältere ID verwendest, plane eine Migration.
- Hier sind noch keine weiteren Breaking Changes verzeichnet. Verfolge die offizielle Modell-Dokumentation für den maßgeblichen Zeitplan.