Fable 5 ist wieder da: was drei Wochen Zwangspause über Leitplanken lehren

Damit ist die Trilogie komplett. Am 10. Juni habe ich hier begeistert über Claude Fable 5 und seinen Modellwechsel geschrieben. Drei Tage später musste ich nachlegen, weil die US-Regierung das Modell per Exportkontrolle über Nacht gesperrt hatte. Und seit dem 1. Juli ist Fable 5 wieder da. Zeit für den dritten Teil, denn die Art, wie Anthropic das Modell zurückbringt, ist aus Architektensicht mindestens so interessant wie die Sperrung selbst.

Was in den drei Wochen passiert ist

Die Chronik in Kürze: Am 12. Juni ging bei Anthropic die Anweisung ein, den Zugang zu Fable 5 und Mythos 5 sofort zu sperren, Begründung nationale Sicherheit, Hintergrund eine bekannt gewordene Jailbreak-Methode. Dann drei Wochen Verhandlungen, unter anderem direkt mit dem Weißen Haus. Am 30. Juni hat das US-Handelsministerium die Exportkontrolle aufgehoben, und seit dem 1. Juli läuft Fable 5 wieder, über alle Kanäle von Claude.ai über die API bis Claude Code.

Zurückgekommen ist das Modell aber nicht einfach im alten Zustand. Anthropic hat nachgerüstet, und zwar genau an der Stelle, an der es gerissen war: Es gibt aktualisierte Sicherheits-Klassifikatoren, die schädliche Anfragen im Cybersecurity-Umfeld erkennen und blockieren sollen, einschließlich der Jailbreak-Techniken, die zur Sperrung geführt hatten. Mythos 5, das Schwestermodell ohne diese Klassifikatoren, bleibt weiterhin hinter einer Zugangskontrolle und ist nur für geprüfte Kunden über ein eigenes Programm verfügbar.

Ablehnung als Architekturkonzept

Der Teil, der mich beim Lesen der offiziellen Dokumentation wirklich beeindruckt hat, ist unscheinbar und steht in keiner Schlagzeile: Anthropic hat die Ablehnung zum vollwertigen API-Konzept gemacht.

Wenn Fable 5 eine Anfrage ablehnt, kommt kein Fehler zurück, sondern eine erfolgreiche Antwort mit dem Stop-Grund "refusal", inklusive der Angabe, welcher Klassifikator angeschlagen hat. Für die abgelehnte Anfrage wird nichts berechnet. Für den Wechsel auf ein anderes Modell gibt es drei dokumentierte Wege, vom automatischen serverseitigen Fallback über SDK-Middleware bis zum manuellen Retry, und sogar eine Gutschrift, damit man die Prompt-Cache-Kosten beim Wechsel nicht doppelt zahlt.

Man kann das für Bürokratie halten. Ich halte es für das Gegenteil: Hier hat jemand akzeptiert, dass Ablehnungen im Normalbetrieb vorkommen, und sie deshalb sauber durchdesignt, mit definiertem Antwortformat, definiertem Ausweichpfad und definierten Kostenregeln. Ablehnung ist kein Betriebsunfall mehr, sondern ein erwarteter Zustand mit Vertrag. Genau so sieht es aus, wenn Leitplanken nicht angeflanscht, sondern eingebaut sind.

Die Frist: bis zum 7. Juli in den normalen Plänen

Für alle, die das Modell einfach nutzen wollen, ist der praktische Teil dieser: Mit der Rückkehr gibt es ein neues Zeitfenster für die Abo-Pläne. Bis zum 7. Juli ist Fable 5 in den meisten Bezahl-Plänen enthalten, also Pro, Max, Team und Teilen von Enterprise, allerdings gedeckelt auf einen Anteil der wöchentlichen Nutzungslimits. Danach wandert der Zugang auf vorausbezahlte Nutzungs-Credits zu API-Preisen, konkret 10 Dollar pro Million Eingabe-Tokens und 50 Dollar pro Million Ausgabe-Tokens. Wer sich selbst ein Bild machen will, hat also noch bis zum Ende der Woche Zeit, danach kostet es extra.

Das ursprüngliche Fenster bis zum 22. Juni, über das ich im ersten Beitrag geschrieben hatte, ist damit Geschichte, die Sperrung hat es schlicht überrollt. Die Logik dahinter bleibt dieselbe: Anthropic ringt erkennbar mit der Rechenkapazität für dieses Modell und steuert die Nachfrage über solche Fenster.

Die Geschichte, die mich nicht loslässt

Während Fable 5 offline war, habe ich die Zeit auf meiner privaten Entwickler-Instanz genutzt und ein kleines Agenten-Szenario nachgebaut, einfach um ein Gefühl für die aktuellen Werkzeuge zu behalten. Ein Agent, ein Ziel, ein Satz Werkzeuge, nichts Wildes.

Irgendwann saß ich vor der Konfiguration und habe mir einen Moment lang vorgestellt, ich wäre böswillig. Oder auch nur nachlässig. Was hätte mich aufgehalten? Die ehrliche Antwort: nichts. Ich hätte dem Agenten Schreibrechte auf jede Tabelle geben können, die meine Rolle hergibt. Ich hätte ihn Aktionen ausführen lassen können, deren Tragweite er nicht versteht und ich im Zweifel auch nicht. Kein Klassifikator hätte angeschlagen, kein Stop-Grund "refusal" wäre zurückgekommen, keine Instanz hätte gefragt, ob das eine gute Idee ist. Die Plattform vertraut dem Entwickler vollständig, so wie sie es immer getan hat.

Genau da liegt die Asymmetrie, die mich seither beschäftigt. Auf der Modellseite hat sich in drei Wochen ein ganzer Apparat bewegt: Klassifikatoren wurden nachgeschärft, eine Regierung hat geprüft, ein Ministerium hat freigegeben, und die Ablehnung hat ein eigenes Antwortformat samt Abrechnungsregeln bekommen. Auf der Plattformseite, dort, wo dieselben Modelle demnächst mit echten Werkzeugen an echten Unternehmensdaten arbeiten, gibt es von alledem fast nichts von Haus aus. Es gibt Rollen und Zugriffskontrolle, natürlich, und es gibt inzwischen gute Beobachtungswerkzeuge. Aber eine eingebaute Instanz, die eine Agenten-Aktion inhaltlich prüft und im Zweifel verweigert, mit sauberem Signal und definiertem Ausweichpfad? Fehlanzeige. Was es an Leitplanken gibt, baut man selbst, oder man hat keine.

Das ist kein Vorwurf an ServiceNow, die Plattform ist historisch ein Werkzeugkasten für vertrauenswürdige Administratoren, und dieses Modell hat zwei Jahrzehnte gut funktioniert. Aber mit Agenten, die selbständig handeln, verschiebt sich die Rechnung. Die Frage ist nicht mehr nur, wer etwas konfigurieren darf, sondern was ein konfiguriertes System eigenständig tun darf, und wer es im Zweifel stoppt.

Was ich aus der Trilogie mitnehme

Drei Beiträge, drei Wochen, drei Lektionen. Aus dem ersten: Die spannendste Eigenschaft eines Spitzenmodells ist nicht seine Leistung, sondern sein Sicherheitskonzept. Aus dem zweiten: Verlässlichkeit entsteht durch Architektur, nicht durch Vertrauen in eine einzelne Komponente. Und aus diesem dritten: Ablehnung gehört als erstklassiges Konzept in jedes System, das autonom handelt, mit definiertem Format, Ausweichpfad und Kostenregel.

Das Refusal-Design von Fable 5 ist dafür eine erstaunlich gute Blaupause, die sich fast wörtlich auf Agenten-Architekturen übertragen lässt: Jede kritische Aktion braucht eine Prüfinstanz, die Nein sagen kann. Das Nein muss ein sauberes, maschinenlesbares Signal sein statt eines Fehlers. Und für das Nein muss ein definierter Plan B existieren, der den Vorgang geordnet weiterführt. Wer seine ServiceNow-Agenten heute so baut, ist der Plattform ein Stück voraus, und ich vermute, nicht mehr lange.

Fable 5 ist zurück, mit mehr Leitplanken als zuvor. Vielleicht ist das die eigentliche Nachricht dieser drei Wochen: Das leistungsstärkste Modell am Markt wurde nicht trotz seiner Beschränkungen wieder zugelassen, sondern wegen ihnen.