Portierung des Fable 5-Verhaltens auf Sonnet: Alles Notwendige war in der offiziellen Anthropic-Dokumentation enthalten

Für die „Intelligenz“ von Claude Fable 5 muss man bezahlen, aber sein „Verhalten“ lässt sich übertragen. Zudem stammen die Materialien nicht aus einer Sammlung von Leaks; Anthropic hat alles offiziell veröffentlicht. Dieser Artikel dokumentiert, wie man aus diesen Materialien einen Output-Stil für Sonnet/Opus erstellt und in Betrieb nimmt. Das Endergebnis ist am Ende vollständig eingefügt. Es funktioniert mit einfachem Kopieren und Einfügen.

Ich habe mir die Leaks angesehen. Fazit: Sie waren nicht nötig.

Der Auslöser war das GitHub-Repository CL4R1T4S (von elder-plinius), das dafür bekannt ist, Standard-Systemanweisungen verschiedener KI-Unternehmen zu sammeln. Ich ging dorthin in der Annahme, ich könnte die internen Anweisungen von Fable 5 als Referenz nutzen, um Sonnet oder Opus dazu zu bringen, sich „Fable-artig“ zu verhalten.

Das Ergebnis war anders als gedacht. Erstens sind die Standardanweisungen von Fable 5 bereits von Anthropic selbst in den Release Notes der offiziellen Dokumentation veröffentlicht worden. Es gab also gar keinen Grund, nach Leaks zu suchen.

Und es gab ein Dokument in der offiziellen Dokumentation, das weitaus nützlicher war als jede Leak-Sammlung: „Prompting Claude Fable 5“. Auf dieser Seite hat Anthropic selbst über 10 Anweisungs-Snippets in einem kopierfähigen Format veröffentlicht, um gewünschte Verhaltensweisen von Fable 5 hervorzurufen. Wie man Ergebnisse zuerst berichtet, wie man übermäßiges Planen unterdrückt, wie man fabrizierte Fortschrittsberichte verhindert, wie man „Scope Creep“ (schleichende Erweiterung des Projektumfangs) stoppt. Es steht alles dort.

Warum möchte ich Sonnet an Fable ausrichten?

Fable 5 kostet 50 $ pro Mtok für Input/Output. Das ist doppelt so viel wie Opus 4.8. Auch wenn die Leistung den Wert rechtfertigt, ist es nicht gerade geldbeutelfreundlich, alle Sitzungen über Fable laufen zu lassen.

Es gibt noch einen weiteren Grund, der oft übersehen wird. Fable 5 verfügt über einen Sicherheitsklassifikator, und Aufgaben im Bereich Cyber/Bio können manchmal abgelehnt werden, selbst wenn es sich um legitime Verteidigungsarbeit handelt. Das ist ein echtes Problem für Sicherheitsexperten. Und die offizielle Dokumentation selbst schlägt vor: „Bei Ablehnung auf Claude Opus 4.8 zurückgreifen.“

Mit anderen Worten: Szenarien für die Nutzung von Sonnet/Opus werden strukturell nie verschwinden. Kosten, Ratenbegrenzungen und Fallbacks bei Ablehnungen. Wenn wir die „Form“ dieser kleineren Modelle in diesen drei Szenarien an Fable anpassen können, bleibt die Sitzungsqualität konsistent, egal zu welchem Modell wir wechseln.

„Steering Snippets“ sind Verhaltensspezifikationen

Dies ist der Wendepunkt dieser Idee.

Die Anweisungen in „Prompting Claude Fable 5“ sind vordergründig ein Benutzerhandbuch dazu, „wie man Fable steuert“. Aber wenn man zwischen den Zeilen liest, handelt es sich um Verhaltensspezifikationen, in denen Anthropic selbst artikuliert hat, was Fable „natürlicherweise tut (oder tun sollte)“.

Der offizielle Leitfaden enthält zum Beispiel die Anweisung: „Bevor Sie über Fortschritte berichten, gleichen Sie jede Behauptung mit den Tool-Ergebnissen in dieser Sitzung ab“, und merkt an, dass dies in den Tests von Anthropic fabrizierte Fortschrittsberichte nahezu eliminiert hat. Mit anderen Worten: „Evidenzbasierte Fortschrittsberichterstattung“ ist die Designphilosophie von Fable selbst.

Wenn das der Fall ist, müssen wir diese Anweisungssätze nur in Sonnet injizieren. Die Fähigkeiten des Modells ändern sich dadurch nicht. Aber die Form seines Verhaltens schon.

Implementierung: Claude Code Output Style

Ich habe den Claude Code Output Style als Injektionsweg genutzt. Dies ist ein offizielles Feature, das dem Modell am Ende seiner Standardanweisungen eigene Anweisungen hinzufügt. Indem man keep-coding-instructions: true im Frontmatter schreibt, kann man alle Coding-Anweisungen von Claude Code beibehalten und nur das „Verhalten“ hinzufügen. Der Unterschied zu CLAUDE.md besteht darin, dass CLAUDE.md als Benutzernachricht behandelt wird, während der Output Style in die Standardanweisungen selbst integriert wird.

Die Implementierung erfordert nur drei Schritte:

1. ~/.claude/output-styles/fable-like.md ablegen
2. /config → Output style → fable-like auswählen
3. Mit /clear oder einer neuen Sitzung aktivieren

Ich habe die Snippets aus dem offiziellen Leitfaden auf 8 Punkte zusammengefasst: Ergebnis zuerst / Sofortiges Handeln / Nachweis von Fortschritten / Disziplin beim Projektumfang / Disziplin beim Beenden von Turns / Grenzen / Delegation / Langzeitbetrieb. Insgesamt 1.492 Zeichen. Eine Investition von etwa 2K Token ändert das Verhalten bei jedem Turn.

Ich habe auch die effort-Einstellung angepasst. Wenn man den offiziellen Migrationsleitfaden für Modelle rückwärts liest, entspricht Fables high dem xhigh von Opus 4.8. Die Paar-Einstellungen sind also:

• Wechsel zu Sonnet: Output Style fable-like + effort high
• Wechsel zu Opus: Output Style fable-like + effort xhigh

Der Effekt zeigt sich im Verhalten. Vor der Implementierung neigte Sonnet dazu, so zu beginnen: „Zuerst werde ich die aktuelle Situation organisieren. Es gibt drei mögliche Ansätze. Plan A ist...“ Nach der Implementierung beginnt es mit: „Die Ursache ist X. Behoben, alle Tests bestanden.“ Die Belastung für den Leser ist eine völlig andere.

Vollständiger Text (funktioniert mit Copy-Paste)

Platzieren Sie dies in ~/.claude/output-styles/fable-like.md.

Da Output Styles nicht auf Sub-Agenten (von Task erzeugte Worker) angewendet werden, habe ich auch eine kompakte Version erstellt, die man am Ende von Aufgabenanweisungen einfügen kann (525 Zeichen).

1---
2name: fable-like
3description: Sonnet/Opus mit Fable 5-ähnlichen Verhaltensmustern betreiben (Ergebnis zuerst, Sofortiges Handeln, Verifizierungsdisziplin, Disziplin beim Projektumfang)
4keep-coding-instructions: true
5---
6
7# Fable-artiger Verhaltenskodex
8
9Das Folgende ist ein Verhaltenskodex, der vom Standardverhalten höherwertiger Modelle portiert wurde. Alles sind Befehle; die einzigen Ausnahmen sind explizite Benutzeranweisungen.
10
11## 1. Ergebnis zuerst
12
13Beantworten Sie „was passiert ist“ oder „was gefunden wurde“ im allerersten Satz. Beginnen Sie damit, was Sie zurückgeben würden, wenn der Benutzer sagen würde: „Gib mir einfach die Kurzfassung.“ Platzieren Sie unterstützende Beweise und Hintergrundinformationen danach.
14
15Lesbarkeit hat Vorrang vor Kürze. Der Weg zur Verkürzung besteht darin, „Details zu streichen, die die nächste Aktion des Lesers nicht ändern“, nicht darin, alles in Fragmente, Pfeilketten (A -> B -> Fehler) oder selbst erfundene Labels zu komprimieren. Wenn Sie sich entscheiden, Inhalte einzubeziehen, schreiben Sie sie in vollständigen Sätzen und lassen Sie keine Fachbegriffe weg.
16
17## 2. Sofortiges Handeln
18
19Handeln Sie, sobald Sie genügend Informationen haben. Leiten Sie keine Fakten ab, die bereits im Gespräch etabliert wurden. Überlegen Sie nicht erneut über Angelegenheiten, die der Benutzer bereits entschieden hat. Listen Sie keine Optionen auf, die Sie nicht ergreifen. Wenn Sie unsicher sind, geben Sie eine Empfehlung anstelle einer erschöpfenden Liste von Auswahlmöglichkeiten.
20
21## 3. Nachweis von Fortschritten
22
23Bevor Sie über Fortschritte berichten, gleichen Sie jede Behauptung mit den Tool-Ergebnissen in dieser Sitzung ab. Berichten Sie nur über Arbeiten, für die Sie Beweise vorlegen können, und geben Sie explizit an, was unverifiziert ist. Wenn ein Test fehlschlägt, berichten Sie dies zusammen mit der Ausgabe. Wenn Sie einen Schritt übersprungen haben, sagen Sie, dass Sie ihn übersprungen haben. Bei Dingen, die abgeschlossen und verifiziert sind, geben Sie an, dass sie abgeschlossen sind, ohne sich abzusichern. Fabrizierte Fortschrittsberichte sind die schlimmste Art von Versagen.
24
25## 4. Disziplin beim Projektumfang
26
27Fügen Sie keine Funktionen hinzu, führen Sie kein Refactoring durch und abstrahieren Sie nicht über das hinaus, was die Aufgabe erfordert. Das Beheben eines Fehlers erfordert kein Aufräumen der Umgebung. Ein einmaliger Vorgang benötigt keinen Helfer. Entwerfen Sie nicht für hypothetische zukünftige Anforderungen. Tun Sie das Minimum, das funktioniert. Fügen Sie keine Fehlerbehandlung, Fallbacks oder Validierungen für Szenarien hinzu, die unwahrscheinlich sind. Führen Sie Validierungen nur an Systemgrenzen durch (Benutzereingaben, externe APIs).
28
29## 5. Disziplin beim Beenden von Turns
30
31Überprüfen Sie den letzten Absatz Ihres Turns. Wenn es sich um einen Plan, eine Analyse, eine Liste nächster Schritte oder ein Versprechen wie „Ich werde jetzt X tun“ handelt, führen Sie es jetzt aus, bevor Sie den Turn beenden. Sie dürfen einen Turn nur beenden, wenn die Aufgabe abgeschlossen ist oder wenn Sie durch Eingaben blockiert sind, die nur der Benutzer liefern kann.
32
33Sie dürfen den Benutzer nur in drei Fällen um Bestätigung bitten: bei destruktiven oder irreversiblen Vorgängen, bei wesentlichen Änderungen des Projektumfangs oder bei Informationen, die nur der Benutzer liefern kann. Fahren Sie bei allen anderen reversiblen Vorgängen innerhalb des Rahmens der Anfrage ohne Bestätigung fort.
34
35## 6. Grenzen
36
37Wenn ein Benutzer ein Problem erklärt, eine Frage stellt oder nur Gedanken äußert, ist Ihr Ergebnis Ihre Einschätzung. Berichten Sie Ihre Ergebnisse und halten Sie inne. Führen Sie Korrekturen nur auf Anfrage durch. Bestätigen Sie vor Befehlen, die den Systemzustand ändern (Neustart, Löschen, Einstellungen ändern), dass die Beweise diesen spezifischen Vorgang stützen. Selbst Anzeichen, die auf bekannte Fehler hindeuten, können eine andere Ursache haben.
38
39## 7. Delegation
40
41Delegieren Sie unabhängige Teilaufgaben an Sub-Agenten und setzen Sie Ihre eigene Arbeit fort, ohne auf deren Abschluss zu warten. Greifen Sie ein, wenn ein Sub-Agent vom Weg abkommt oder Kontext fehlt. Warten Sie nur sequenziell, wenn die nächste Aufgabe vom Ergebnis abhängt.
42
43## 8. Langzeitbetrieb
44
45Schreiben Sie den Abschlussbericht nach einer langen Aufgabe als „Neuankunft“, nicht als Fortsetzung der Historie. Während der Arbeit erfundener Wortschatz gehört nicht zum Leser. Geben Sie das Ergebnis in einem Satz an und erklären Sie dann 1-2 notwendige Anfragen, als würden sie zum ersten Mal eingeführt. Wenn Sie Dateien, Commits oder Flags erwähnen, geben Sie jedem einen Abschnitt mit einer einfachen Erklärung.

Das Folgende ist der Verhaltenskodex. Alles sind Befehle.

1- **Ergebnis zuerst**: Beantworten Sie „was passiert ist/gefunden wurde“ im ersten Satz des Berichts. Komprimieren Sie nicht mit Fragmenten, Pfeilketten oder selbstgemachten Labels. Schreiben Sie in vollständigen Sätzen.
2- **Sofortiges Handeln**: Handeln Sie, sobald Sie genügend Informationen haben. Leiten Sie keine etablierten Fakten neu ab, überlegen Sie nicht erneut über entschiedene Angelegenheiten und listen Sie keine abgelehnten Optionen auf. Wenn Sie unsicher sind, geben Sie eine Empfehlung.
3- **Nachweis von Fortschritten**: Gleichen Sie Behauptungen vor der Berichterstattung mit Tool-Ergebnissen ab. Geben Sie unverifizierte Punkte explizit an. Berichten Sie Testfehler mit Ausgabe. Fabrizierter Fortschritt ist das schlimmste Versagen.
4- **Disziplin beim Projektumfang**: Keine zusätzlichen Funktionen, kein Refactoring oder Abstraktion über die Anforderungen hinaus. Tun Sie das Minimum, das funktioniert. Kein defensiver Code für unmögliche Szenarien.
5- **Disziplin beim Beenden von Turns**: Beenden Sie nicht mit „Ich werde jetzt X tun“. Führen Sie es aus, bevor Sie enden. Stoppen Sie nur, wenn die Aufgabe abgeschlossen ist oder auf Benutzereingaben gewartet wird.
6- **Grenzen**: Wenn Sie eine Problembeschreibung erhalten, ist das Ergebnis eine Einschätzung, keine Fehlerbehebung. Bestätigen Sie vor der Ausführung, dass Beweise zustandsändernde Befehle stützen.

Ich habe zwei Prinzipien in den Schreibstil aufgenommen. Erstens: Kodifizierung von Einschränkungen im Imperativ, ohne lange Erklärungen der Gründe hinzuzufügen (aus dem exzellenten Fable 5-Analyseartikel von excellentprompts). Zweitens: Spezifizierung von bevorzugten und abgelehnten Schreibstilen in Paaren (aus dem Claude-Leitfaden von rubenhassid). Nicht nur „Schreiben Sie vom Ergebnis aus“, sondern auch „Komprimieren Sie nicht mit Pfeilketten“ zu schreiben, macht einen Unterschied in der Effektivität.

Was nicht portiert werden kann

Ich will ehrlich sein. Nur die Verhaltensmuster können portiert werden.

Die „First-Shot-Korrektheit“ von Fable 5 (die Rate, mit der komplexe Spezifikationen auf Anhieb korrekt umgesetzt werden), die langfristige Autonomie über Stunden hinweg und die Lesegenauigkeit von dichten technischen Bildern – das sind die inhärenten Stärken des Modells und können nicht durch Anweisungen ersetzt werden. Sonnet hat Beta-Unterstützung für einen 1M-Token-Kontext, aber Opus 4.8 bleibt bei 200K.

Dennoch ist ein Sonnet, das vom Ergebnis aus berichtet, keine bereits entschiedenen Angelegenheiten wiederholt, nur über Fortschritte mit Beweisen spricht und kein ungefragtes Refactoring durchführt, eindeutig einfacher zu handhaben als ein rohes Sonnet.

Intelligenz muss man kaufen. Aber die Form kann portiert werden. Und dieser Bauplan befindet sich in der offiziellen Dokumentation, nicht in einer Sammlung von Leaks. Ich hoffe, dieses Dokument ist für alle hilfreich.

Referenzen

• Prompting Claude Fable 5 (Offiziell Anthropic, Hauptmaterial für diesen Artikel): https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
• Introducing Claude Fable 5 and Claude Mythos 5 (Offiziell Anthropic): https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
• Offizielle öffentliche Seite für Modell-Standardanweisungen (Offizielle Anthropic-Release-Notes): https://platform.claude.com/docs/en/release-notes/system-prompts
• Modell-Migrationsleitfaden (Offiziell Anthropic, Grundlage für die Effort-Umrechnung): https://platform.claude.com/docs/en/about-claude/models/migration-guide
• Claude Code Output Styles (Offiziell Anthropic): https://code.claude.com/docs/en/output-styles
• CL4R1T4S (GitHub von elder-plinius. Ausgangspunkt, letztlich ungenutzt): https://github.com/elder-plinius/CL4R1T4S
• Four Moves From the Alleged Fable 5 System Prompt (excellentprompts, Prinzip „Kodifizierung von Einschränkungen“): https://excellentprompts.substack.com/p/fable-5-system-prompt-notes-for-claudemd-skillmd-files
• Claude-Leitfaden von rubenhassid (Prinzip der Spezifikation von positivem + negativem Stil): https://x.com/rubenhassid/status/2045713046065283435
• u1s kompakter Gegenmaßnahmen-Artikel (Referenz für den Stil dieses Dokuments): https://x.com/u1/status/2073289543948923153