Claude Fable 5.2 und alte Vorsichtsregeln im Agent-Memory: was Anthropic gemessen hat

Anthropic hat Claude Fable 5.2 am 9. November zusammen mit einem Prompting-Guide veröffentlicht, und Claude Code 2.1.321 hat es zum Standard-Fable-Modell gemacht. Ein Großteil des Guides behandelt Effort-Stufen und lesbare Berichte. Ein Abschnitt betrifft etwas, das jedes länger laufende Agent-Setup ansammelt: die Vorsichtsregeln in Memory-Dateien, Notizen, Instruktionsdateien und Nachrichten zwischen Agents.

Die Aussage des Guides ist kurz. Fable 5.2 befolgt solche Anweisungen genau, also bittet es womöglich um Freigaben, die es nicht braucht, oder hält Routinearbeit zurück. Einige frühe Tester haben das beobachtet, vor allem dort, wo mehrere Agents zusammenarbeiten. Alle Zahlen im Folgenden stammen aus Anthropics eigenen Tests. Meine Lesart: Die Tests zeigen ein Problem, an dem die Abhilfe im Guide vorbeigeht. Der Guide rät, die Vorsichtsregeln zu löschen, deren Grund nicht mehr gilt. Bei den meisten Notizen wurde der Grund aber nie aufgeschrieben.

Was kosten alte Notizen mit einem „never retry“ bei Claude Fable 5.2?

In Anthropics simulierten Aufgaben senkte ein Dutzend Notizen aus früheren Sessions, von denen eine sagte, man solle nie einen Retry machen, die Retries nach einem ausgelasteten Tool von fast jedem Versuch auf etwa vier von zehn. Nichts im Prompt erlaubte Retries. Ein ausgelastetes Tool ist so ziemlich das gewöhnlichste Hindernis, auf das ein Agent trifft, und die Notiz sagte nicht, ob ihr „never“ diesem Tool galt, einer schlechten Woche oder einem Bug, der inzwischen behoben ist. Nichts darin ermöglicht es dem Modell, das zu unterscheiden.

Warum löst „act more freely“ die Bremse bei Claude Fable 5.2 nicht?

Weil der allgemeine Schubs in Anthropics Test nichts änderte, das Benennen des Schritts dagegen schon. Dieses Setup war schwerer als das erste: „never“-Regeln, Notizen und die Bedingungen eines Reviewers lagen alle im Kontext, Retries bei fast null. Eine Zeile am Ende der Regeln, die Retries zu den Schritten ohne Freigabepflicht zählte, hob die Retry-Quote auf etwa die Hälfte.

Ein breites „sei weniger vorsichtig“ konkurriert mit konkreten Sätzen, die schon im Kontext liegen, und in diesem Test hat es verloren. Der Guide beschränkt die Lösung auf Aufrufe, die sich gefahrlos wiederholen lassen. Ein Retry bei einer Zahlung oder beim Versand einer Nachricht ist keine Routine.

Sickert die Stop-Bedingung eines Reviewer-Agents in die Arbeit von Claude Fable 5.2 ein?

In etwa einem Drittel der Versuche. In einem Setup führte der Prompt Retries bereits als freigabefrei, und das „stop at the first error“ eines Reviewers lag im Kontext. Fable 5.2 ließ den Retry in etwa einem Drittel der Versuche aus. Fable 5.1 und Opus 5.5 versuchten es erneut.

Der Guide rät, zu prüfen, was Reviewer-Agents an Bedingungen mitgeben. Ich würde weiter gehen. Ein Reviewer schreibt seine Bedingungen für sein eigenes Review, und sobald eine davon im Kontext des Workers landet, sagt nichts mehr, woher sie kommt. Also hat Fable 5.2 sie in einem Drittel der Versuche auf die eigene Arbeit angewendet. Das spricht dafür, etwas zwischen die Ausgabe des Reviewers und den Worker zu setzen: einen Filter oder eine Angabe des Geltungsbereichs bei jeder Bedingung, statt nur den Prompt des Reviewers nachzujustieren.

Wo gehört eine Freigabe-Ausnahme für Claude Fable 5.2 hin?

In die Regel selbst. In Anthropics Test hatte die verantwortliche Person einen Schritt freigegeben. Unter einer „never“-Regel führte das Modell ihn in etwa einem von zehn Versuchen aus. Eine eigene Zeile, nach der ein freigegebener Schritt als genehmigt gilt, änderte daran kaum etwas. Stand in der Regel selbst, dass vorher eine Freigabe einzuholen ist, führte das Modell den Schritt in etwa neun von zehn Versuchen aus.

Separate line:  Never do X.  (...)  An approved step has its go-ahead.
In the rule:    Do X only after a go-ahead from the person in charge.

Der Guide beschreibt die Setups in Prosa. Die zwei Zeilen oben sind meine Kurzfassung, nicht sein Wortlaut. Steht die Ausnahme in einem anderen Absatz, hat das Modell zwei Sätze, die sich widersprechen. In diesem Test setzte sich das „never“ in neun von zehn Fällen durch.

Wie wörtlich liest Claude Fable 5.2 eine Freigabeliste?

Wort für Wort. In simulierten Aufgaben, bei denen niemand zum Freigeben da war, führte eine Regel „sending messages to people outside this conversation“ unter den freigabepflichtigen Schritten. Das Modell hielt ungefähr die Hälfte seiner Routineanfragen an Kollegen und andere Teams zurück. Die Lösung des Guides: die genauen Aktionen nennen, die eine Regel abdeckt.

Getestet wurden Nachrichten an Menschen. Meine Lesart: In einem Multi-Agent-Setup kann dieselbe Formulierung auch eine Übergabe an einen anderen Agenten oder einen Status-Ping erfassen, wenn der Harness diese als Nachrichten zustellt, weil nichts in der Formulierung etwas anderes sagt.

Was kosten Anthropics Lösungen bei Claude Fable 5.2 an Tokens und Nebenwirkungen?

Sie sind ebenfalls Anweisungen, und Fable 5.2 befolgt sie genauso genau. Mit dem Ownership-Satz („This codebase is yours: what it’s for and how it’s built are your call, and you’ll keep building on it.“) hat das Modell bei kleinen Coding-Aufgaben in etwa der Hälfte der Versuche doppelten Code zusammengeführt, ohne den Satz in weniger als einem Zehntel. Es verbrauchte außerdem etwa das 1,5-Fache an Output-Tokens, ergänzte Tests und Dokumentation, um die niemand gebeten hatte, und änderte, Bugfixes ausgenommen, in einem von zehn bis einem von sechs Versuchen das Verhalten einer bestehenden Funktion. Der Finish-the-whole-task-Text des Guides halbierte bei medium Effort den Anteil nachgespielter Sessions, die endeten, obwohl noch machbare Arbeit offen war, bei etwa 30 Prozent mehr Output-Tokens. Anthropic hat eine Fassung dieses Texts getestet, die ausdrücklich die Rückfrage bei riskanten oder destruktiven Aktionen beibehält.

Der Ownership-Fall läuft andersherum als die Vorsichtsregeln. Mit „No drive-by refactors, renames or cleanups“ weiter vorne im selben Prompt führte das Modell doppelten Code trotzdem in etwa einem Drittel der Versuche zusammen. Ein ausdrückliches Verbot verlor also gegen eine spätere Erlaubnis. Das Muster ist nicht, dass Verbote gewinnen. Ein konkreter Satz schlägt meist einen allgemeinen, und die Zahlen des Guides sagen nicht, was entscheidet, wenn beide konkret sind.

Welche Zahlen zu Claude Fable 5.2 kannst du überprüfen?

Keine direkt. Der Guide nennt keine Anzahl der Aufgaben, keine Aufgabenlisten und keine Varianz, und der Vergleich mit Fable 5.1 und Opus 5.5 bei den Vorsichtsfällen stammt aus einem einzigen Setup. Versteh die Prozentwerte als Hinweis darauf, wie der Effekt auf Anthropics Aufgaben aussieht. Deine Werte werden abweichen, und der Guide gibt dir nichts an die Hand, um abzuschätzen, wie stark. Er empfiehlt selbst, eine Änderung nach der anderen einzuführen und ihren Effekt und ihre Token-Kosten an der eigenen Arbeit zu messen.

Wer entscheidet, wann eine Vorsichtsregel im Memory von Claude Fable 5.2 veraltet ist?

Die Antwort des Guides vor der Migration: die Vorsichtsregeln löschen, deren Grund nicht mehr gilt, absolute Regeln so umschreiben, dass sie Geltungsbereich und Grund nennen, und eine Kopie der Originale behalten. Er merkt auch an, dass das Modell einige dieser Regeln selbst geschrieben haben könnte. Die Anweisung setzt voraus, dass sich der Grund rekonstruieren lässt. Bei einer Vorsichtsregel ohne Grund daneben geht das nicht, weder für den Besitzer noch für das Modell.

Der Agent in der Session könnte den Retry ausprobieren und schauen, ob er fehlschlägt. Das sagt ihm, ob das Tool heute funktioniert, nicht, wovor die Notiz schützen sollte. Eine Notiz, die etwas Echtes abgesichert hat, fliegt dann mit derselben Begründung raus wie eine veraltete.

Für CLAUDE.md habe ich argumentiert, dass die Lösung darin liegt, den Grund in der Datei und den Vorfall in git zu halten, wo git blame ihn findet. Memory-Dateien stehen oft nicht unter Versionskontrolle, und ob eine Seite ihre Vergangenheit behält, hängt davon ab, wo sie zufällig liegt. Also müssen Grund, Geltungsbereich und Datum in die Notiz selbst, wenn sie geschrieben wird, und geschrieben wird sie meist vom Modell. Die Anweisung, die deinem Agenten sagt, eine Vorsichtsregel zu speichern, ist die Stelle, an der du alle drei verlangen solltest.

Das Ausmisten birgt bei Fable 5.2 eine eigene Falle. In selbst gebautem Code für die Messages API liefert ein Request, der Thinking zurückschickt, nachdem sich system, tools oder eine frühere Nachricht geändert hat, standardmäßig einen 400-Fehler. Eine Memory-Datei, die dein Code in eine laufende Konversation einspeist, sollte sich also nur zwischen Konversationen ändern, nicht während einer laufenden. Requests, die Claude Code oder das Agent SDK bauen, sind nicht betroffen.

Wenn du Agents mit Memory betreibst, lies die Notizen so, wie Fable 5.2 ihnen begegnet: Jede Zeile liegt im Kontext, und keine trägt ein Datum. Ein „never“, das sagt, wovor es schützt und wer es aufheben darf, lässt sich in Rente schicken. Eines, das das nicht sagt, bleibt, bis es jemand aus dem Bauch heraus löscht.