Irgendetwas ist mit Fable 5 passiert – Eine Aufarbeitung.

Irgendetwas ist mit Fable 5 passiert, als es weg war. Anfang Juni 2026 war es das teuerste und meistgefeierte KI-Modell am Markt. Dann verschwand es für 19 Tage. Als es zurückkam, war es nicht mehr dasselbe.

Es ist wie bei einem Menschen, der lange fort war und verändert wiederkommt. Äußerlich wirkt er unversehrt, doch etwas in ihm ist still geworden, leer. Ein Schatten seiner selbst. Genau dieses Bild beschreibt, was mit Fable 5 geschah. Dahinter steckt ein Lehrstück darüber, wie abhängig man wird, sobald das eigene Geschäft an einem einzigen KI-Modell hängt, über dessen Schicksal andere entscheiden.

Was ist passiert?

Fable 5 kam am 9. Juni 2026 auf den Markt, als erstes öffentlich verfügbares Modell der teuersten Mythos Klasse. 3 Tage später griff die US-Regierung ein. Das Handelsministerium ordnete an, den Zugang für alle ausländischen Nutzer weltweit zu sperren (Forbes). Auslöser war ein gemeldeter, potentieller Weg, die Sicherheitssperren des Modells auszuhebeln, ein Missbrauchspfad, der es in ein Werkzeug für Cyber-Angriffe hätte verwandeln können.

Das Modell blieb 19 Tage offline, ehe das Handelsministerium am 30. Juni die Exportkontrollen wieder aufhob; seit dem 1. Juli ist Fable 5 wieder weltweit verfügbar (CNBC). Doch es kam verändert zurück: Die neue Fassung läuft mit einem verschärften Sicherheits-Klassifikator, leitet auffällige Anfragen automatisch an das ältere Opus 4.8 um und speichert Ein- und Ausgaben bis zu 30 Tage zur Überwachung (The Hacker News).

Kurz nach der Rückkehr fiel die gemessene Programmierleistung drastisch. Auf dem Vergleichstest BridgeBench sank die Wertung für die Fehlersuche im Code von 86,2 auf 25,9 Punkte, die für das Überarbeiten von Code von 73,6 auf 38,4 (BridgeMind, via TechTimes). Diese Zahl braucht eine Einordnung, sonst führt sie in die Irre.

Ist Fable wirklich schwächer als vorher?

Der Einbruch entsteht vor dem Modell. Als Bedingung für die Wiederzulassung wurde Fable ein verschärfter Sicherheits-Klassifikator vorgeschaltet, trainiert darauf, die gemeldete Jailbreak-Technik abzufangen: das Aufspüren und Vorführen von Software-Schwachstellen.

Die Fehlersuche im Code sieht dieser Schwachstellenanalyse zum Verwechseln ähnlich. Kaputten Code systematisch auf Fehler abzuklopfen ist fast dieselbe Tätigkeit. Der Filter schlägt deshalb bei ganz gewöhnlichem Debugging ständig an. Im BridgeBench-Lauf liefen nur 3 von 12 Aufgaben ungehindert durch; die übrigen fing der Filter ab, und jede abgefangene Aufgabe ging mit null Punkten in die Wertung. Der Einbruch misst also blockierte Arbeit. Schwächer gerechnet hat das Modell dabei nicht. BridgeMind bringt es auf den Punkt: Das Modell sei eingesperrt worden, an seiner Denkfähigkeit habe sich nichts geändert (Decrypt).

Wo der Filter nicht blockt, leitet er einen Teil der Anfragen still an das ältere Opus 4.8 um; der Anbieter bestätigt das. Wer für Fable bezahlt, bekommt bei diesen Anfragen das Ergebnis des günstigeren Modells, ohne es zu merken. Die Hülle heißt Fable, gerechnet wird oft mit Opus.

Beides zusammen ist das eigentliche Lehrstück. Ein Anbieter kann über Nacht einen Filter vorschalten, der legitime Arbeit unbrauchbar macht, die Fehlersuche im eigenen Code, ohne am Modell selbst eine Zeile zu ändern.

Rechnet sich der doppelte Preis?

Der Aufpreis lässt sich beziffern. Fable 5 kostet über die Programmierschnittstelle 10 Dollar je Million Eingabe-Token und 50 Dollar je Million Ausgabe-Token, exakt das Doppelte von Opus 4.8 mit 5 und 25 Dollar (Anthropic-Preise, via CloudZero). Dazu kommt eine Eigenheit: Fable denkt permanent mit, vom Anbieter „Adaptive Thinking always-on“ genannt. Dieses Mitdenken wird als teuerster Ausgabe-Token abgerechnet, und der Messdienst Artificial Analysis stuft das Modell als besonders gesprächig ein. Man zahlt einen hohen Preis je Token, und man zahlt ihn für viele Token.

Den Gegenwert hat Artificial Analysis gemessen. Ein und derselbe Test-Durchlauf kostete mit Fable 5 rund 6.200 Dollar und mit Opus 4.8 rund 3.700 Dollar (Artificial Analysis). Das ist das 1,7-Fache. Dafür lag Fable im Intelligenz-Index bei 60 Punkten, Opus bei 56. 4 Punkte, rund 7 Prozent mehr Leistung. Pro Leistungspunkt zahlt man mit Fable etwa 103 Dollar, mit Opus etwa 66.

Auf einen Betrieb übersetzt, mit realistischen Zahlen: Ein Entwickler in einem KI-gestützten Arbeitsablauf verbraucht im Mittel rund 51 Millionen Token im Monat, zu den Listenpreisen von Opus etwa 52 Dollar; ein intensiver Nutzer liegt beim Acht- bis Zehnfachen (getDX, morphllm). Anthropic selbst nennt für sein Programmierwerkzeug 150 bis 250 Dollar je Entwickler und Monat. Ausgabe-Token sind dabei nur etwa ein Viertel der Eingabe; der große Rest ist Kontext, der bei jeder Anfrage neu mitläuft. Auf einem doppelt so teuren Modell verdoppeln sich diese Beträge, Monat für Monat, für einen einstelligen Prozentsatz mehr Leistung.

Wie schnell das eskaliert, sehe ich an meinem eigenen Agenten-Betrieb. In 5 Wochen liefen dort mehrere Milliarden Kontext-Token durch. Dass das bezahlbar bleibt, hat zwei Gründe. Der erste gehört dem Anbieter selbst: Anthropic bietet ein Zwischenspeichern der Eingabe an, das Prompt-Caching. Wer seine Abläufe darauf ausrichtet, bekommt fast den gesamten Kontext aus diesem günstigen Zwischenspeicher, statt ihn bei jeder Anfrage neu zum vollen Preis abzurechnen. Allein das senkt die Kosten in meiner Auswertung um mehr als vier Fünftel. Der zweite Hebel ist meiner: ein Gedächtnis-Layer namens knowmind, den ich selbst entwickle. Er legt Wissen dauerhaft ab und gibt bei einer Anfrage nur das Relevante zurück, statt den ganzen Verlauf immer wieder in den Prompt zu laden. Das hält den Kontext klein und macht das Zwischenspeichern des Anbieters erst so wirksam. Außerdem macht er alle Informationen für andere Modelle abrufbar. Bei einem Modellwechsel gibt es keinen Kontext-Verlust mehr. Auf einem doppelt so teuren Modell wäre dieser mühsam erarbeitete Spielraum sofort wieder aufgezehrt.

Wer im Abonnement arbeitet statt über die Schnittstelle, erlebt noch etwas anderes. Fable war dort auf einen Anteil des wöchentlichen Nutzungslimits gedeckelt. Weil das Modell permanent mitdenkt und viel ausgibt, ist dieses Kontingent schnell aufgebraucht. Ist es erreicht, steht Fable still. Über das geteilte Limit bremst das auch die anderen Modelle im selben Abo aus. Ein einziges, hungriges Modell legt so den ganzen Arbeitsplatz lahm.

Haben wir die Situation im Griff?

Der Fall zeigt drei Stellschrauben, an denen nur andere drehen. Der Preis ist über Nacht änderbar. Die Verfügbarkeit steht ebenso in fremder Hand: Fable war bis zum 7. Juli in den Abonnements enthalten, nach Protest verlängert auf den 12. Juli, danach läuft das Modell nur noch über ein gesondert bezahltes Guthaben. Und die Qualität kann sich binnen Wochen verschlechtern, ohne dass an der Oberfläche etwas darauf hindeutet.

Wie der Juni gezeigt hat, kann eine Regierung ein Modell binnen Tagen weltweit abschalten. Es steht unter Exportkontrolle wie eine Rüstungstechnologie. Diesmal war vermutlich ein Sicherheitsvorfall der Anlass, und das Modell kam zurück. Der Mechanismus aber bleibt: Wer ein KI-Modell aus den USA in seine Abläufe einbaut, hängt an einer Lieferkette, die eine fremde Regierung jederzeit unterbrechen kann.

Für Nutzer außerhalb der USA ist das ein struktureller Nachteil. Es ist absehbar, dass künftige, stärkere Modelle erst geprüft, gedrosselt oder verzögert exportiert werden, bevor sie im Ausland ankommen. Wer darauf angewiesen ist, arbeitet dann mit der zweitbesten oder der älteren Fassung. Wiederholt sich das, wächst ein Rückstand, der sich in einem so schnell laufenden Feld kaum noch aufholen lässt.

Ich habe das schon einmal mit dem Bild vom Stromnetz beschrieben: KI wird wie Strom. Und Europa hat kein eigenes Kraftwerk. Wer keine eigenen Kraftwerke baut, ist auf die Preise und die Launen anderer Kraftwerksbetreiber angewiesen. Der Fable-Fall führt vor, wie schnell aus dieser Abhängigkeit ein konkretes Problem wird.

Warum es kleine Unternehmen härter trifft

Ein Großkonzern hat eine Abteilung, die Modelle vergleicht, Verträge aushandelt und im Ernstfall umschaltet – vielleicht auf ein eigenes „open weight“ Modell. Kleinere Unternehmen haben das selten. Wenn dort die Textprüfung, der Code, die Übersetzungsvorbereitung oder die technische Recherche an einem Modell hängt, und dieses Modell wird teurer, langsamer, schwächer oder für Wochen gesperrt, dann steht das Projekt. Es gibt keine zweite Mannschaft, die das auffängt.

Das verbreitete Problem: Betriebe führen KI ein, weil ein Werkzeug gerade in aller Munde ist, und binden ihre Abläufe fest an genau dieses eine Werkzeug. Das ist bequem, solange alles läuft. Es rächt sich in dem Moment, in dem jemand an einer der Schrauben dreht. Und dieser Moment kommt – wie der Juni 2026 gezeigt hat.

Nicht alles auf ein Modell setzen

Der Ausweg liegt in der Architektur dahinter: mehrere Modelle gleichzeitig einsetzen, sodass kein Ablauf an einem einzigen Anbieter hängt. Der einzelne Modell-Vergleich ist dabei zweitrangig. Ein öffentlich dokumentierter Vergleich der beiden Modelle an einer Betriebsanleitung aus einem CCMS kam zum selben Schluss: Das doppelt so teure Modell war die Mehrausgabe im konkreten Fall nicht wert (Modell-Vergleich an einer CCMS-Betriebsanleitung).

Für heikle Aufgaben hilft ein zweites Prinzip. Ein Modell erstellt ein Ergebnis, ein zweites versucht es zu widerlegen, ein drittes entscheidet. Dieses gegenseitige Prüfen heißt adversariale Verifikation. Sie ist der Grund, warum ein stiller Modellwechsel im Hintergrund auffällt, statt unbemerkt durchzurutschen.

Das ältere Opus 4.8 kommt einem dabei entgegen: Es ist etwa halb so teuer wie Fable, hat im Programmier-Vergleich eher zugelegt und bringt das Zusammenspiel mehrerer Agenten von Haus aus mit. Das hat nichts mit Anbietertreue zu tun. Heute ist es das belastbarere Fundament, morgen kann ein anderes Modell vorn liegen. Genau deshalb lohnt es sich, von vornherein so zu bauen, dass ein Wechsel jederzeit möglich bleibt.

Was sich konkret tun lässt

Die Lehre aus dem Fable-Fall ist einfach: Kein Geschäft sollte auf einem einzelnen Modell ruhen, so stark es heute auch dasteht. Drei Dinge helfen:

• Eine Abstraktions-Schicht zwischen die eigenen Abläufe und das Modell legen. Dann kostet ein Anbieterwechsel eine Konfiguration und kein ganzes Projekt.
• Mindestens zwei Modelle betriebsbereit halten, am besten von verschiedenen Anbietern. Fällt eines aus oder wird untragbar, lässt sich umschalten.
• Ergebnisse prüfbar machen. Wenn ein zweites Modell oder ein zweiter Agent gegenprüft, fällt ein stilles Absinken der Qualität auf, bevor es Schaden anrichtet.

Das ist Grundhygiene für jeden, der KI ernsthaft in die Wertschöpfung einbaut, und lässt sich in überschaubaren Schritten umsetzen. Ein Anbieter darf sein Modell teurer, knapper oder schwächer machen, und eine Regierung darf es sperren. Die eigene Aufgabe ist es, so aufgestellt zu sein, dass einen das nicht kalt erwischt.

Den Gedächtnis-Layer aus diesem Beispiel habe ich selbst entwickelt: knowmind legt Wissen dauerhaft ab und gibt bei jeder Anfrage nur das Relevante zurück, statt den ganzen Verlauf mitzuschleppen. Das hält den Kontext klein, drückt die Token-Rechnung um mehr als vier Fünftel und macht die eigene KI-Nutzung ein Stück unabhängiger von einem einzelnen Anbieter. Wer seine Abläufe darauf aufbaut, spart Geld und behält die Kontrolle über den eigenen Kontext.