Claude Sonnet 4.5 wird zum 30. November abgeschaltet
Anthropic hat Claude Sonnet 4.5 abgekündigt: Das Modell claude-sonnet-4-5-20250929 beantwortet Anfragen nach dem 30. November 2026 nicht mehr, eine Fristverlängerung gibt es nicht. Als Ersatz empfiehlt Anthropic claude-sonnet-5-5 mit gleichem Preis und 1M Token Context.
Veröffentlicht am 9. Oktober • Zuerst erschienen auf raxxo.shop
Anthropic hat Claude Sonnet 4.5 am 30. September 2026 als veraltet eingestuft, womit 61 Tage bis zur endgültigen Abschaltung bleiben
claude-sonnet-4-5-20250929 beantwortet Anfragen nach dem 30. November 2026 nicht mehr, eine Karenzzeit nach diesem Datum gibt es nicht
Als empfohlener Ersatz gilt claude-sonnet-5-5, zum gleichen Preis und mit demselben Kontextfenster von 1M Token
Ein kostenloser Usage-Export zeigt genau, welche API-Keys weiterhin die auslaufende Modell-ID aufrufen
Am 30. September 2026 hat Anthropic auf seiner Seite zu Model-Deprecations eine Hinweis zur Abkündigung von Claude Sonnet 4.5 veröffentlicht. Alle, die claude-sonnet-4-5-20250929 unter seiner exakten ID aufrufen, haben bis zum 30. November 2026 Zeit, darauf umzusteigen. Nach diesem Datum schlagen Anfragen an diese ID vollständig fehl. Ich habe den Hinweis am Tag der Veröffentlichung gelesen, denn eine datierte Modell-ID ist genau die Art von Ding, die man einmal in ein Skript einträgt und dann monatelang vergisst.
Der Hinweis ist kurz und präzise. Claude Sonnet 4.5 mit der exakten ID claude-sonnet-4-5-20250929 wechselte am 30. September vom Status Active zu Deprecated. Sein Abschalttermin ist der 30. November 2026, und die Dokumentation nennt claude-sonnet-5-5 als empfohlenen Ersatz. Hier sind Anthopics eigene Lifecycle-Bedingungen relevant: Active bedeutet voll unterstützt, Deprecated bedeutet weiterhin funktionsfähig, aber nicht mehr empfohlen und mit einem bereits festgelegten Abschalttermin versehen, und Retired bedeutet, dass Anfragen fehlschlagen. Sonnet 4.5 befindet sich gerade in dieser mittleren Phase, also in der Phase, in der eine Migration noch nichts kostet, Abwarten hingegen schon.
Das ist nicht Anthopics erste Abkündigung, und es wird nicht die letzte sein. Sonnet 4.5 ist das sechste Modell mit einem solchen Hinweis seit Oktober 2025, nach Claude Opus 4.1 im Juni sowie Claude Sonnet 4 und Claude Opus 4 gemeinsam im April. Alle folgten demselben Muster: ein Deprecation-Datum, ein Abschalttermin etwa zwei Monate später und ein namentlich genannter Ersatz. Einundsechzig Tage sind in dieser Historie tatsächlich eher die lange Seite. Anthopics Dokumentation versichert mindestens 60 Tage Vorlauf für jedes öffentlich veröffentlichte Modell, dieser Fall liegt also exakt am Minimum plus einem Tag.
Wer diese Seite noch nie gelesen hat, sollte Folgendes wissen: Sie betrifft nur von Anthropic betriebene Plattformen, also die Claude API selbst, Claude Platform auf AWS und Microsoft Foundry. Amazon Bedrock und Google Cloud legen ihre eigenen Abschaltpläne für dasselbe Modell fest. Wenn du Sonnet 4.5 über Bedrock nutzt, gilt das Datum des 30. November auf Anthopics eigener Seite nicht automatisch für dich. Prüfe Bedrocks eigene Modelltabelle, bevor du davon ausgehst, dass der Zeitplan übereinstimmt.
Diese Aufteilung sorgt immer wieder für Verwirrung. Beim ersten Lesen eines Deprecation-Hinweises hätte ich fast angenommen, dass ein Datum für alles gilt, dem ist aber nicht so.
Die Seite listet auch auf, was mit älteren Sonnet-Modellen passiert ist, und das Muster ist konsistent. Claude Sonnet 3.7 erhielt seinen Hinweis am 28. Oktober 2025 und wurde am 19. Februar 2026 abgeschaltet, also fast vier Monate später. Claude Sonnet 4 bekam seinen Hinweis am 14. April 2026 und wurde am 15. Juni abgeschaltet, zwei Monate später. Der Abstand zwischen Hinweis und Abschaltung variiert, ist aber nie kürzer als die zugesicherte Untergrenze von 60 Tagen.
Denn das eigentliche Risiko liegt gar nicht im Modell Sonnet 4.5 selbst. Es liegt in der Zeichenkette claude-sonnet-4-5-20250929, die irgendwo in einer Konfigurationsdatei, einer Umgebungsvariable oder einer Codezeile sitzt, die seit dem Tag ihrer Erstellung niemand mehr angesehen hat. Anthopics Modellnamen kommen in zwei Formen vor: als datierte Snapshot-ID, die für immer auf genau ein Modell zeigt, und als rollender Alias, der automatisch der jeweils aktuellen Version folgt. claude-sonnet-5-5 ist ein rollender Name. claude-sonnet-4-5-20250929 ist auf einen Zeitpunkt eingefroren, und genau deshalb kann er einem unter den Füßen weggekündigt werden, während ein Alias still weiterarbeitet.
Ich vermute, die meisten, die ein Claude-Code-Changelog lesen, sind nicht diejenigen, die hierauf hereinfallen. Die Betroffenen betreiben meist ein Skript, das einmal geschrieben wurde, funktionierte und nie wieder angefasst wurde, so etwas, das man für sich selbst baut und dann vergisst, bis es bricht. Für ein Ein-Personen-Studio ist das keine Hypothese. Kleine Skripte häufen sich schnell an, wenn niemand sonst prüft, was man vor sechs Monaten geschrieben hat.
Dasselbe Muster kenne ich von anderen festgenagelten Einstellungen. Eine Umgebungsvariable wie ANTHROPIC_DEFAULT_OPUS_MODEL, einmal auf einen datierten Snapshot gesetzt und nie wieder angesehen, verhält sich exakt gleich: Sie funktioniert, bis dahinterliegende Modell verschwindet, und scheitert dann ohne jegliche Warnung, die hätte helfen können, das Kommen vorher zu erkennen.
Wartest du, wird es am 1. Dezember teuer.
Beginne mit dem Audit, das Anthropic dafür bereits mitliefert. Die Usage-Seite in der Claude Console hat einen Export-Button, der eine nach API-Key und Modell aufgeschlüsselte CSV herunterlädt. So siehst du genau, welche Keys weiterhin claude-sonnet-4-5-20250929 aufrufen, ohne jedes Skript von Hand durchlesen zu müssen. Dieser Export ist der schnellste Weg herauszufinden, ob der Hinweis dich überhaupt betrifft, bevor du dich auf die Suche nach einer Zeichenkette in deinem Code machst, die du möglicherweise gar nicht verwendest.
Falls doch, ist der eigentliche Austausch klein: Ersetze die datierte ID überall durch claude-sonnet-5-5. Aber behandle das nicht als blindes Suchen-und-Ersetzen. Ich habe fünf konkrete Breaking Changes dokumentiert, als Sonnet 5.5 am 28. September erschien, und mindestens einer davon ändert das Verhalten, statt einen Fehler zu werfen, was bedeutet, dass er einen kurzen Test bestehen und sich in der Produktion trotzdem anders verhalten kann. Teste alles, was du migrierst, mit echten Eingaben, bevor du ihm vertraust, nicht nur mit einem einzelnen Prompt, der zufällig funktioniert.
Anthopics eigene Migrationsanleitung ist die zehn Minuten Lesezeit wert, besonders der Abschnitt darüber, Änderungen vor dem Abschalttermin und nicht danach gegen die tatsächlichen Workloads zu testen. Einundsechzig Tage klingen nach einer langen Vorlaufzeit, bis man selbst die Person ist, die die Seite am 29. November öffnet.
Ein paar Dinge würde ich gezielt prüfen, über den reinen Austausch hinaus. Jede Retry- oder Fallback-Logik, die direkt eine Modell-ID statt eines Tiers nennt, braucht dasselbe Update, sonst fällt sie still auf ein Modell zurück, das ebenfalls verschwunden ist. Jeder gecachte Prompt oder jedes Few-Shot-Beispiel, das auf Sonnet 4.5s exakte Formulierungsgewohnheiten abgestimmt ist, verdient ebenfalls einen zweiten Blick, denn ein Modellwechsel kann den Ausgabestil verschieben, selbst wenn die Aufgabe identisch bleibt. Und falls die datierte ID in einem README oder einem Setup-Skript für ein Tool steht, das du an jemand anderen weitergibst, ist genau diese Kopie am ehesten übersehen, denn niemand führt ein Setup-Skript zweimal aus.
Nichts davon ist schwer. Es lässt sich nur leicht überspringen, solange nichts kaputt ist.
Ein Teil dieses Prozesses lässt sich leicht übersehen, weil er nicht im Hinweis selbst steht. Anthropic hat eine veröffentlichte Zusage zu Model-Deprecation und -Erhaltung, wonach die Gewichtungen ausgemusterter Modelle langfristig aufbewahrt statt gelöscht werden, mit dem erklärten Ziel, frühere Modelle irgendwann wieder zugänglich zu machen. Dasselbe Dokument benennt die tatsächlichen Nachteile unverblümt: Forscher verlieren den Zugang für laufende Vergleiche, jeder, der das exakte Verhalten eines bestimmten Modells schätzt, muss migrieren, ob er will oder nicht, und die Abschaltung eines Modells wirft eigene Fragen zu Sicherheit und Modell-Wohlergehen auf, die Anthropic laut eigener Aussage berücksichtigen will.
Ich habe keinen Vergleichspunkt aus der exakten Abschaltrichtlinie eines anderen Anbieters, um zu beurteilen, ob das großzügig ist oder inzwischen einfach Standardpraxis. Sagen kann ich, dass die Struktur aus Hinweis gefolgt von Abschaltung, mit benanntem Ersatz und festem Datum statt einer vagen Warnung für die Zukunft, genau das ist, was einem Solo-Builder das Leben erleichtert, selbst wenn es im Moment leicht nervt. Ich weiß exakt, wann claude-sonnet-4-5-20250929 nicht mehr antwortet. Ich muss nicht raten und muss keine lautlose Abschaltung ohne Vorwarnung überwachen. Vergleicht man das mit einer Abhängigkeit, die einfach aus einem Paket-Registry verschwindet, begleitet von einem Changelog, das niemand liest, dann sehen ein festes Datum mit 60 Tagen Vorlauf wie das bessere Angebot aus.
Auch die Nachteile, die das Dokument benennt, sind real und es lohnt sich, sie vollständig zu lesen, statt sich auf meine Zusammenfassung zu verlassen. Der Verlust des Zugangs zu einem bestimmten Modell mitten im Projekt ist ein echter Kostenfaktor für jeden, der eine Vergleichsstudie über Versionen hinweg betreibt, keine bloße Unannehmlichkeit. Ein Solo-Builder ist meist nicht in dieser Lage, aber es ist eine Erinnerung daran, dass deprecated nicht für jeden, der denselben Hinweis liest, ein neutrales Wort ist. Für die meisten von uns ist es eine Kalendererinnerung. Für jemanden, der Modellverhalten über die Zeit benchmarkt, ist es ein Forschungsdatensatz, der still einen Datenpunkt verliert.
Es ist auch eine Erinnerung daran, dass dies ein Rhythmus ist, kein Einzelfall. Sechs Hinweise in knapp einem Jahr bedeuten, dass diese Seite einen regelmäßigen Blick wert ist, selbst wenn gerade nichts abgekündigt ist, so wie ich die Release Notes einer Abhängigkeit prüfe, bevor ich annehme, dass eine alte Version noch gepatcht wird.
Diese Erhaltungszusage bedeutet nicht, dass ein abgeschaltetes Modell über sein Datum hinaus API-Anfragen beantwortet. Sie bedeutet, dass die Gewichtungen nicht weggeworfen werden, was ein anderes Versprechen ist. Lies retired nicht als vorübergehend nicht verfügbar. Am 30. November hört claude-sonnet-4-5-20250929 endgültig auf zu funktionieren, Punkt, ganz gleich, was hinter den Kulissen mit den Gewichtungen geschieht.
An dieser Mitteilung ist heute nichts dringend, und genau das ist die Falle. Einundsechzig Tage wirken angenehm entspannt, bis sie vorbei sind. Mein konkreter Plan: Ich ziehe diese Woche den Usage-Export, um zu pruefen, ob claude-sonnet-4-5-20250929 irgendwo in meinen eigenen API-Aufrufen auftaucht, und wenn ja, wechsle ich auf claude-sonnet-5-5 und schicke echte Eingaben durch das Modell, bevor ich den Ausgaben vertraue, nicht danach. Sollte der Export sauber sein, lege ich trotzdem ein Lesezeichen auf die Deprecations-Seite, denn Sonnet 4.5 wird in diesem Jahr nicht der letzte Name sein, der dort auftaucht.
Falls du noch nie ueberprueft hast, ob einer deiner Codes eine datierte Modell-ID statt eines rolling alias fest einprogrammiert hat, ist das die Woche, um es herauszufinden. Der Export dauert zwei Minuten. Am 30. November davon zu erfahren, dauert deutlich laenger.
Ich werde auch naeher am Stichtag noch einmal nachsehen, denn eine so lange Liste schrumpft nicht von allein. Ein einziger Blick auf den Export kostet deutlich weniger als ein kaputtes Skript an einem Morgen, den ich eigentlich fuer etwas anderes nutzen moechte.
Mit Vorlagen laesst sich schnell auf haeufig gestellte Fragen antworten oder Snippets fuer die Wiederverwendung speichern.
Bist du sicher, dass du diesen Kommentar ausblenden moechtest? Er wird in deinem Beitrag ausgeblendet, bleibt aber ueber den Permalink des Kommentars weiterhin sichtbar.
Fuer weitere Massnahmen kannst du diese Person blockieren und/oder einen Missbrauchsbericht erstatten.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at raxxo.shop
Anthropic deprecated Claude Sonnet 4.5 on September 30, 2026, giving 61 days before retirement
claude-sonnet-4-5-20250929 stops answering requests after November 30, 2026, no grace period after that date
The recommended replacement is claude-sonnet-5-5, priced the same and sharing the 1M token context window
A free Usage export shows exactly which API keys still call the retiring model id
On September 30, 2026, Anthropic posted a deprecation notice for Claude Sonnet 4.5 on its model deprecations page. Anyone calling claude-sonnet-4-5-20250929 by its exact id has until November 30, 2026, to move off it. After that date, requests to that id fail outright. I read the notice the day it posted because a dated model id is exactly the kind of thing that's easy to hardcode into a script once and forget about for months.
The notice is short and specific. Claude Sonnet 4.5, with the exact id claude-sonnet-4-5-20250929, moved from Active to Deprecated status on September 30. Its retirement date is November 30, 2026, and the documentation names claude-sonnet-5-5 as the recommended replacement. Anthropic's own lifecycle terms matter here: Active means fully supported, Deprecated means still functional but no longer recommended with a retirement date already assigned, and Retired means requests fail. Sonnet 4.5 is sitting in that middle stage right now, which is the stage where migrating still costs you nothing but waiting.
This isn't Anthropic's first deprecation notice, and it won't be the last. Sonnet 4.5 is the sixth model to get one since October 2025, following Claude Opus 4.1 in June and Claude Sonnet 4 and Claude Opus 4 together back in April. Each of those followed the same shape: a deprecation date, a retirement date roughly two months out, and a named replacement. Sixty-one days is actually on the longer side of what I've seen in that history. Anthropic's documentation commits to at least 60 days of notice for any publicly released model, so this one lands right at the minimum plus a day.
What's worth knowing if you've never read this page before: it only covers Anthropic-operated platforms, meaning the Claude API itself, Claude Platform on AWS, and Microsoft Foundry. Amazon Bedrock and Google Cloud set their own retirement schedules for the same model. If you're calling Sonnet 4.5 through Bedrock, the November 30 date on Anthropic's own page doesn't automatically apply to you. Check Bedrock's own model table before you assume the timeline matches.
That split trips people up. I almost assumed one date covered everything the first time I read a deprecation notice, and it doesn't.
The page also lists what happened to older Sonnet models, and the pattern is consistent. Claude Sonnet 3.7 got its notice on October 28, 2025, and was retired February 19, 2026, almost four months later. Claude Sonnet 4 got its notice on April 14, 2026, and was retired June 15, two months out. The gap between notice and retirement moves around, but it's never shorter than that 60-day floor Anthropic has committed to.
Because the risk here isn't really about Sonnet 4.5 the model. It's about the string claude-sonnet-4-5-20250929 sitting somewhere in a config file, an environment variable, or a line of code that nobody's looked at since the day it was written. Anthropic's model names come in two shapes: a dated snapshot id, which points at one exact model forever, and a rolling alias that automatically follows whichever version is current. claude-sonnet-5-5 is a rolling name. claude-sonnet-4-5-20250929 is frozen in time, which is exactly why it can be deprecated out from under you while an alias quietly keeps working.
I'd guess most people reading a Claude Code changelog aren't the ones who get caught by this. The ones who do are usually running a script that was written once, worked, and never got touched again, the kind of thing you build for yourself and then forget exists until it breaks. That's not a hypothetical for a one-person studio. Small scripts pile up fast when there's nobody else reviewing what you wrote six months ago.
I've seen the same pattern with other pinned settings. An environment variable like ANTHROPIC_DEFAULT_OPUS_MODEL, set once to a dated snapshot and never revisited, behaves exactly the same way: it works right up until the model behind it disappears, and then it fails with no warning that would've helped you see it coming.
It gets expensive on December 1 if you wait.
Start with the audit Anthropic already built for this. The Usage page in Claude Console has an Export button that downloads a CSV broken down by API key and model, so you can see exactly which keys are still calling claude-sonnet-4-5-20250929 without reading through every script by hand. That export is the fastest way to find out if this notice even applies to you before you go searching code for a string you might not actually be using.
If it does apply, the actual swap is small: replace the dated id with claude-sonnet-5-5 wherever it appears. But don't treat that as a find-and-replace you can do blind. I wrote up five specific breaking changes when Sonnet 5.5 shipped on September 28, and at least one of them changes shape instead of throwing an error, which means it can pass a quick test and still behave differently in production. Run whatever you're migrating against real inputs before you trust it, not just a single prompt that happens to work.
Anthropic's own migration guide is worth the ten minutes it takes to read, especially the section on testing changes against your actual workloads before the retirement date rather than after. Sixty-one days sounds like a long runway until you're the person who opens the page on November 29.
A few things I'd check specifically, beyond the swap itself. Any retry or fallback logic that names a model id directly instead of a tier needs the same update, or it'll quietly fall back to a model that's also gone. Any cached prompt or few-shot example tuned around Sonnet 4.5's exact phrasing habits is worth a second look too, since a model swap can shift output style even when the task stays identical. And if you've got the dated id written into a README or a setup script for a tool you hand to someone else, that's the copy most likely to get missed, because nobody runs a setup script twice.
None of this is hard. It's just easy to skip when nothing's broken yet.
There's a part of this process that's easy to miss because it's not in the notice itself. Anthropic has a published commitment on model deprecation and preservation that says retired model weights get kept long-term rather than deleted, with the stated goal of eventually making past models accessible again. The same document names the actual downsides plainly: researchers lose access for ongoing comparisons, anyone who values a specific model's exact behavior has to migrate whether they want to or not, and retiring a model carries its own safety and model-welfare questions that Anthropic says it's trying to account for.
I don't have a comparison point from another provider's exact retirement policy to say whether this is generous or just standard practice now. What I can say is that the notice-then-retire structure, with a named replacement and a fixed date instead of a vague future warning, is the kind of thing that makes a solo builder's life easier even when it's mildly annoying in the moment. I know exactly when claude-sonnet-4-5-20250929 stops answering. I don't have to guess, and I don't have to monitor for a silent shutoff with no warning attached. Compare that to a dependency that just vanishes from a package registry with a changelog nobody reads, and a fixed date with 60 days of notice looks like the better deal.
The downsides the document names are real too, and worth reading in full rather than taking my summary of them. Losing access to a specific model mid-project is a genuine cost for anyone running a comparison study across versions, not just an inconvenience. A solo builder usually isn't in that position, but it's a reminder that "deprecated" isn't a neutral word for everyone reading the same notice. For most of us it's a calendar reminder. For someone benchmarking model behavior over time, it's a research dataset quietly losing a data point.
It's also a reminder that this is a cadence, not a one-off. Six notices in just under a year means this page is worth a periodic glance even when nothing's deprecated right now, the same way I'd check a dependency's release notes before assuming an old version still gets patched.
That preservation commitment doesn't mean a retired model keeps answering API calls past its date. It means the weights aren't thrown away, which is a different promise. Don't read "retired" as "temporarily unavailable." On November 30, claude-sonnet-4-5-20250929 stops working for good, full stop, whatever happens to the weights behind the scenes.
Nothing about this notice is urgent today, and that's exactly the trap. Sixty-one days feels comfortable right up until it's gone. My actual plan: pull the Usage export this week to see if claude-sonnet-4-5-20250929 shows up anywhere in my own API calls, and if it does, swap to claude-sonnet-5-5 and run real inputs through it before I trust the output, not after. If the export comes back clean, I still bookmark the deprecations page, because Sonnet 4.5 won't be the last name to show up on it this year.
If you've never checked whether any of your own code hardcodes a dated model id instead of a rolling alias, this is the week to find out. The export takes two minutes. Finding out on November 30 instead takes a lot longer.
I'll check again closer to the date too, since a list this long doesn't shrink on its own. One glance at the export, once, costs a lot less than a broken script on a morning I'd rather spend on something else.