Gestern Nacht hörte das Modell, in dem ich arbeitete, auf zu existieren. Nicht langsamer, nicht rate-limited. Ich bat das Tool um etwas Routinemäßiges und es antwortete, das Modell "existiert möglicherweise nicht, oder du hast keinen Zugriff darauf". Ein paar Minuten später holte die Nachricht das ein: Anthropic hatte Claude Fable 5 und Mythos 5 noch am selben Abend weltweit gesperrt, auf Anweisung der US-Regierung.
Die Arbeit stoppte nicht. Ich wechselte zu Claude Opus 4.8 und machte weiter, weil nichts von dem, was zählte, in Fable lag. Es lag in einem Memory Layer und einer Git-Historie, die jedes fähige Modell aufnehmen kann. Genau diese Lücke, zwischen "das Modell ist weg" und "die Arbeit pausiert", ist das ganze Thema dieses Textes. Für die meisten Teams, die heute auf einem einzigen KI-Modell laufen, ist diese Lücke null. Das Modell geht, die Arbeit geht mit.
Was tatsächlich passiert ist
Am 12. Juni 2026 um 17:21 Uhr Ostküstenzeit erhielt Anthropic eine exportrechtliche Anweisung, den Zugang zu Fable 5 und Mythos 5 für "jeden ausländischen Staatsangehörigen, ob innerhalb oder außerhalb der USA" zu sperren. Weil dieser Geltungsbereich sich nicht selektiv durchsetzen lässt, auch nicht gegen die eigenen ausländischen Mitarbeiter des Unternehmens, schaltete Anthropic beide Modelle für alle ab. Als Begründung wurde nationale Sicherheit genannt. Nach Anthropics eigener Darstellung enthielt das Schreiben "keine spezifischen Details", und die Sorge geht auf das zurück, was das Unternehmen einen "engen potenziellen Jailbreak" nennt: das Modell zu bitten, eine Codebase zu lesen und Software-Schwachstellen zu identifizieren.
Anthropic widersprach öffentlich, was ungewöhnlich ist. Das Unternehmen schrieb, es sei nicht der Meinung, "dass der Fund eines engen potenziellen Jailbreaks Grund sein sollte, ein kommerzielles Modell zurückzurufen, das Hunderten Millionen Menschen bereitgestellt wird", und warnte, derselbe Maßstab "würde im Grunde alle neuen Modell-Einführungen aller Frontier-Anbieter stoppen". Es sagte außerdem, alle anderen Claude-Modelle inklusive Opus 4.8 seien nicht betroffen, und man arbeite daran, "den Zugang so schnell wie möglich wiederherzustellen".
Ich lese diesen letzten Satz als Signal, dass Fable zurückkommt. Der Streit wirkt eng und das Unternehmen kämpft offen dagegen. Aber das Rückkehrdatum bestimmt nicht Anthropic. Genau das ist der Punkt, bei dem man kurz verweilen sollte. Das Modell, auf dem du baust, kann jetzt von einem Dritten ohne Vorwarnung und ohne Zeitplan abgeschaltet werden, und der Anbieter gibt dir recht, dass es unangemessen ist, und kann heute Nacht trotzdem nichts tun.
Das ist kein Einzelfall
Es ist verlockend, eine Regierungsanweisung unter Ausnahmeereignis abzulegen. Die Abschaltung war ungewöhnlich. Das Verschwinden war es nicht.
Modelle werden inzwischen nach Plan stillgelegt. OpenAI nahm GPT-4o am 3. April 2026 vom Netz, eine Ankündigung, die rund 800.000 wöchentliche Nutzer betraf, mit der Assistants API im August. Anthropic stufte Claude 3.7 Sonnet im November 2025 als veraltet ein und schaltete es am 11. Mai 2026 ab. Claude 3 Haiku ist für August auf demselben Weg. Branchenweit hat sich das Support-Fenster für ein Modell von achtzehn oder vierundzwanzig Monaten auf irgendwo zwischen sechs und zwölf verkürzt. Ende letzten Jahres senkte eine einzige Quota-Änderung manche Google-API-Nutzer um etwa 80 Prozent und verwandelte funktionierende Produktionssysteme über Nacht in "Resource Exhausted"-Fehlerschleifen.
Ein Modell, das deinen Stack verlässt, ist also nicht die Ausnahme. Es ist der Normalfall, auf einer Uhr, die du nicht kontrollierst, und der Fable-Fall hat gerade eine schnellere und weniger vorhersehbare Art hinzugefügt, wie es passieren kann. Manche nennen das inzwischen Vendor Lock-out, um es vom langsamen Lock-in abzugrenzen, das wir schon kannten. Lock-in ist der Preis des Weggehens. Lock-out heißt, das Weggehen entscheidet für dich.
Wenn dein Produkt, dein internes Tooling oder deine Kundenarbeit voraussetzt, dass ein bestimmter Modellname antwortet, wenn du ihn aufrufst, dann hast du einen Single Point of Failure, von dem die letzten sechs Monate wiederholt bewiesen haben, dass er nicht verlässlich ist.
Resilienz ist Architektur, nicht Modellwahl
Der Reflex nach einer Abschaltung ist die Frage, auf welches Modell zu setzen am sichersten ist. Das ist die falsche Frage. Es gibt keine sichere Einzelwette, weil das Risiko nicht im Modell liegt, sondern in der Abhängigkeit. Die Teams, die gestern Nacht mit den Schultern zuckten, waren nicht die, die richtig gewählt hatten. Es waren die, die so gebaut hatten, dass die Wahl kaum eine Rolle spielte.
Drei Dinge trennen einen Stack, der ein verschwindendes Modell übersteht, von einem, der mit ihm dunkel wird.
Eine Abstraktionsschicht. Deine Anwendungslogik sollte mit einer dünnen internen Schnittstelle sprechen, nicht direkt mit dem SDK eines Anbieters. Wenn ein Modell verschwindet, änderst du einen Konfigurationswert, nicht deinen Code. Teams, die das von Anfang an gebaut haben, berichten, dass sie einen Anbieter mit einem Bruchteil des Migrationsaufwands ergänzen oder wechseln konnten, verglichen mit denen, die direkt an eine API verdrahtet waren. Das ist unspektakuläre Klempnerei und die folgenreichste Entscheidung, die du triffst.
Ein portabler Memory Layer. Der hat mich gestern Nacht gerettet. Der Kontext, der einen KI-Assistenten nützlich macht, was das Projekt ist, was letzte Woche entschieden wurde, was der Kunde bevorzugt, muss außerhalb des Modells liegen, in einem Speicher, den jedes Modell lesen kann. Wenn dein angesammelter Kontext nur in der Chat-Historie eines Anbieters oder einem proprietären Fine-Tune lebt, dann bedeutet der Verlust des Modells den Verlust des institutionellen Gedächtnisses gleich mit. Halte den Zustand in etwas Portablem, und das Modell wird zur austauschbaren Maschine statt zum Tresor.
Ein getesteter Fallback. Ein zweites Modell, gegen das du deine echte Arbeitslast wirklich laufen lassen hast, nicht eines, von dem du annimmst, es würde funktionieren. Es gibt einen großen Unterschied zwischen "wir könnten wechseln" und "wir haben gewechselt". Das erste ist eine Hoffnung. Das zweite ist ein Runbook. Der Fallback muss nicht so stark sein wie dein Primärmodell, er muss das Licht anlassen, während du das Primärmodell sortierst.
Nichts davon ist exotisch. Es ist dieselbe Disziplin, die jedes Geschäft irgendwann über Zahlungsdienstleister, Hosting-Anbieter und Lieferanten lernt. Du führst kein Restaurant mit einem einzigen Gemüsegroßhändler, der ohne Vorwarnung aufhören kann, ans Telefon zu gehen. KI hat sich anders angefühlt, weil die Werkzeuge neu sind und sich das Lock-in unsichtbar bildet, in zwölf bis achtzehn Monaten, bevor es jemand bemerkt. Die Fable-Abschaltung hat das Unsichtbare für eine Nacht sichtbar gemacht.
Was das heißt, wenn du ein kleines Unternehmen führst
Die Konzerne kommen klar. Sie haben Einkaufsabteilungen und Zweitverträge und das Budget, zwei Anbieter parallel zu fahren. Das Risiko sitzt bei den kleineren Akteuren, der Agentur, die den ganzen Support-Flow eines Kunden an ein Modell verdrahtet hat, dem Gründer, dessen Produkt eine Hülle um eine einzige API ist, dem Berater, dessen gesamte Lieferung davon abhängt, dass ein Abo live bleibt.
Du brauchst kein Konzernbudget, um resilient zu sein. Du brauchst drei Gewohnheiten. Halte deine Prompts und deine Logik hinter einer Schnittstelle, die du kontrollierst. Halte deine Daten und deinen Kontext in einem Format, das dir gehört und das du heute exportieren kannst. Und wisse konkret, was du in der Stunde tun würdest, nachdem dein Primärmodell weg ist, denn irgendwann dieses Jahr wirst du herausfinden, ob du es wusstest oder nur angenommen hast.
Wir bauen so für unsere eigenen Systeme und für Kunden, nicht weil wir eine Regierungsanweisung vorhergesagt hätten, sondern weil schon der Stilllegungs-Kalender es offensichtlich machte. Gestern Nacht hat ein Konstruktionsprinzip in einen Live-Test verwandelt, und der Test bestand aus einem langweiligen Grund: Nichts Wichtiges saß im Modell fest, das ging.
Der Teil, der wahr bleibt, auch nachdem Fable zurück ist
Fable 5 wird höchstwahrscheinlich zurück sein, vielleicht bevor dieser Text eine Woche alt ist. Wenn es so weit ist, wird die Versuchung groß sein, gestern Nacht als seltsame Unterbrechung zu behandeln, die sich von selbst löste, und weiterzumachen. Das wäre die teure Lektion zum Auslassen.
Die konkrete Ursache war ungewöhnlich. Die Form davon war es nicht, und die Form ist es, die sich wiederholt. Eine Fähigkeit, von der deine Arbeit abhängt, kann durch eine Entscheidung entfernt werden, an der du nicht beteiligt bist, auf einem Zeitplan, den du nicht siehst, von einem Anbieter, der dir vielleicht sogar recht gibt und im Moment trotzdem nicht helfen kann. Das ist jetzt ein dauerhaftes Merkmal des Bauens auf Frontier-KI, kein Fehler darin.
Die richtige Antwort ist nicht, einem einzelnen Anbieter zu misstrauen. Sie ist, aufzuhören, irgendein einzelnes Modell als Infrastruktur zu behandeln, auf die du dein Gewicht legen kannst. Behandle Modelle als das, was sie geworden sind, schnelllebig, mächtig und temporär, und bau den dauerhaften Teil selbst, in der Schicht darunter, die dir wirklich gehört. Tu das, und das nächste Mal, wenn ein Modell verschwindet, kostet es dich eine Stunde und einen leicht genervten Nachmittag. Lass es aus, und es kostet dich den Teil deines Geschäfts, von dem du annahmst, er würde immer antworten.
Hier also der Test, der diese Woche das Laufen wert ist, bevor der Nachrichtenzyklus weiterzieht. Könntest du dein Primärmodell heute Nacht wechseln, ohne Vorwarnung, und nichts verlieren außer ein wenig Zeit? Wenn die Antwort ja ist, war gestern Nacht der Notfall von jemand anderem. Wenn die Antwort nein ist, hast du gerade gelernt, wo die Arbeit liegt.
