Prompting für Claude Fable 5.2

Dieser Leitfaden behandelt die Prompting-Muster, die speziell für Claude Fable 5.2 gelten. Informationen zu den Fähigkeiten des Modells und zu API-Änderungen findest du unter Was ist neu in Claude Fable 5.2. Techniken, die für alle aktuellen Claude-Modelle gelten, findest du unter Best Practices für Prompting.

Claude Fable 5.2 verhält sich in einigen Punkten anders als frühere Modelle. Beginne mit dem Abschnitt, der zu deiner Beobachtung passt:

• Du bist unsicher, welche Effort-Stufe du verwenden sollst, oder einfache Anfragen dauern zu lange: Effort kalibrieren
• Ein Turn endet, bevor die Arbeit erledigt ist: Die gesamte Aufgabe abschließen
• Du gibst Schritte frei, während der Agent arbeitet, oder dein System-Prompt enthält Freigaberegeln: Freigaben
• Ein Coding-Agent wiederholt bestehenden Code, statt ihn zusammenzuführen, oder meldet benachbarte Probleme, ohne sie zu beheben: Sag, wem der Code gehört
• Lange agentische Turns wirken stumm: Nutzer während langer Turns auf dem Laufenden halten
• Agent-Sitzungen starten mehr Subagenten, als die Aufgabe erfordert: Erwartungen für Subagenten festlegen
• Agenten bitten um Freigaben, die sie nicht brauchen, oder halten Routinearbeit zurück: Verhindern, dass sich Vorsicht aufstaut
• Du übernimmst einen System-Prompt, Skills oder einen Harness, die für Claude Fable 5.1 oder Claude Opus 5.5 geschrieben wurden: Für frühere Modelle geschriebene Anweisungen überprüfen
• Deine Nutzer lesen nach langen Aufgaben Abschlussberichte oder Übergaben: Berichte leicht verständlich machen
• Anfragen liefern stop_reason: "refusal" zurück: Ablehnungen durch Schutzmechanismen

Effort kalibrieren

Beginne mit high, dem Standard in der Claude API. Wenn dein Anwendungsfall es erfordert, erhöhe oder verringere den Effort und teste jede Änderung mit deinen eigenen Evals. Das „effort“ (Aufwand)-Level legt fest, wie viel Claude Fable 5.2 nachdenkt, wie lange ein Turn dauert und wie viele Token es verbraucht. Stimme den Effort zusammen mit deinem Prompt ab, denn das Level verändert auch die Art, wie das Modell nachdenkt, und wie viele Tool-Aufrufe es macht.

Im Allgemeinen folgen die Effort-Stufen bei allen Claude-Modellen derselben Reihenfolge, aber wie viel Nachdenken hinter jeder Stufe steckt, kann sich von Modell zu Modell unterscheiden. Führe deshalb deinen Effort-Vergleich erneut durch, statt eine Einstellung zu übernehmen, die du für Claude Fable 5.1 oder Claude Opus 5.5 abgestimmt hast.

Wähle ein Level nach der Art der Arbeit:

• low eignet sich für schnelles Hin und Her, klar spezifizierte Aufgaben und Workloads mit hohem Volumen, etwa schnelle, intelligente Subagenten. In Anthropics Tests lagen die Ergebnisse des Modells bei low nahe an den Ergebnissen von Claude Fable 5.1 bei höheren Effort-Stufen.
• medium eignet sich für interaktives Programmieren, Chat und alltägliche Wissensarbeit.
• high eignet sich für anspruchsvolles Programmieren, Recherche, agentische Arbeit und lange unbeaufsichtigte Läufe. Turns dauern spürbar länger als bei medium.
• xhigh ist für deine schwierigsten langlaufenden Programmier- und agentischen Aufgaben gedacht, bei denen du einen Gewinn gemessen hast. In Anthropics internen Programmier-Evaluierungen verbesserte es die Ergebnisse leicht und verbrauchte deutlich mehr Token.
• max dient dazu, die Obergrenze des Modells zu messen, oder für die seltene Aufgabe, bei der Zeit und Token keine Rolle spielen. Es eignet sich am besten für offene Probleme wie wissenschaftliche Entdeckungen und Mathematik. Turns sind langsam und verbrauchen deutlich mehr Token als bei xhigh.

Der größte Teil des Fähigkeitsgewinns ist bereits bei high vorhanden. Der Schritt von medium zu high verbesserte die Ergebnisse bei den meisten Programmier- und Wissensarbeits-Evaluierungen, die Anthropic verfolgt. Dieser Schritt verbraucht aber auch mehr Token und mehr Zeit, also wechsle überall dort zu medium, wo deine Evals zeigen, dass die Qualität erhalten bleibt. Oberhalb von high sind die Gewinne ungleichmäßig und hängen von der Aufgabe ab.

Wenn du ein Level wählst, beachte drei Verhaltensweisen:

• Bei niedrigeren Effort-Stufen hört das Modell eher vorzeitig auf. Füge für agentische Arbeit bei low oder medium den Text aus Die gesamte Aufgabe abschließen hinzu.
• Bei high und darüber denkt das Modell vor fast jeder Antwort nach, auch vor der Antwort auf eine Begrüßung. Wenn einfache Anfragen zu lange dauern oder zu viel kosten, verwende für diese Turns eine niedrigere Effort-Stufe. In Anthropics Tests hielt eine Anweisung, direkt ohne Abwägen zu antworten, das Modell bei medium und darüber nicht vom Nachdenken ab.
• Der Effort verändert kaum, wie lang die Antworten des Modells sind. Um Länge und Ton einer Antwort zu ändern, verwende deinen Prompt.

Du kannst Levels auch in einem Workflow kombinieren. Du könntest zum Beispiel mit dem Modell bei medium planen und iterieren und dann den Effort für den langen, unbeaufsichtigten Teil erhöhen. Um Levels innerhalb einer Konversation zu wechseln und den Prompt-Cache zu behalten, verwende eine Effort-Änderung pro Nachricht (Beta, Header mid-conversation-output-config-2026-07-01); dieser Abschnitt listet die Plattformen auf, auf denen sie verfügbar ist. Eine Änderung gilt, bis eine andere sie ersetzt. Wo Effort pro Nachricht nicht verfügbar ist, setze bei der nächsten Anfrage einen neuen effort-Wert auf oberster Ebene, wodurch der Cache neu beginnt.

Die gesamte Aufgabe abschließen

Bei langen, mehrstufigen Aufgaben beendet Claude Fable 5.2 manchmal einen Turn, bevor die Arbeit erledigt ist. Der Turn endet mit einer Liste dessen, was noch aussteht, einem Angebot weiterzumachen oder einem Halt bei einem gewöhnlichen Hindernis wie einem Timeout. Das passiert bei low und medium Effort häufiger.

Wenn du solche Abbrüche in deinem Agenten beobachtest, füge deinem System-Prompt Text wie diesen hinzu:

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.

If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.

If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.

Dieser Text unterscheidet zwei Arten von Hindernissen. Er weist das Modell an, gewöhnliche Hindernisse wie Fehler, Timeouts und fehlschlagende Tools zu diagnostizieren und zu überwinden. Er weist das Modell an, bewusst gesetzte Blockaden, etwa eine als unantastbar markierte Datei, in Ruhe zu lassen und sie zu melden. Betrachte den Text als Ausgangspunkt und behalte diese Unterscheidung bei, wenn du ihn an deine Anwendung anpasst.

Anthropic hat aufgezeichnete Sitzungen aus einem agentischen Programmierprodukt bei medium Effort erneut abgespielt. Mit einer Version dieses Textes endeten etwa halb so viele Sitzungen mit noch machbarer, offener Arbeit. Der Text beseitigte die meisten Enden, die um Erlaubnis bitten oder anbieten weiterzumachen, aber nicht die Enden, die auflisten, was noch aussteht, und dann aufhören. Die Output-Token stiegen um etwa 30 Prozent.

Da das Modell mit diesem Text seltener nachfragt, behalte deinen eigenen Bestätigungsschritt für riskante oder irreversible Aktionen bei.

Freigaben

Wenn du dem Modell sagst, dass es weitermachen soll, sag klar, was du von ihm möchtest, statt ein bloßes „weiter“ zu schicken. Antworte zum Beispiel „Ja, führe die Migration auf der Staging-Datenbank aus“, wo du sonst vielleicht „los“ oder einen Daumen nach oben geschickt hättest.

Wenn dein System-Prompt Freigaberegeln enthält, benenne die genauen Aktionen, die sie abdecken, denn das Modell wendet sie so an, wie sie geschrieben sind. In Anthropics Tests mit simulierten Aufgaben, bei denen niemand zum Freigeben da war, führte eine Regel „Nachrichten an Personen außerhalb dieser Konversation senden“ unter den freigabepflichtigen Schritten auf. Mit dieser Regel hielt das Modell etwa die Hälfte seiner routinemäßigen Anfragen an Kollegen und andere Teams zurück.

Sag, wem der Code gehört

Claude Fable 5.2 reagiert genau darauf, was der Prompt darüber sagt, wem der Code gehört, an dem es arbeitet. In Anthropics Tests mit kleinen Programmieraufgaben neigte das Modell, wenn ein Prompt nichts zur Zuständigkeit sagte oder die Codebasis als die eines anderen darstellte, dazu, die bestehende Struktur zu ergänzen, selbst wenn dabei bestehender Code wiederholt wurde. Es neigte auch dazu, benachbarte Probleme zu melden, statt sie zu beheben. Wenn der Prompt sagt, dass die Codebasis dem Modell selbst gehört, führt das Modell oft wiederholten Code zusammen und nimmt verwandte Korrekturen vor, ohne darum gebeten zu werden.

Wenn du möchtest, dass das Modell die Struktur während der Arbeit verbessert, sag, dass der Code ihm gehört:

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

In Anthropics Tests mit kleinen Coding-Aufgaben fasste das Modell wiederholten Code mit diesem Satz in etwa der Hälfte der Versuche zusammen und ohne ihn in weniger als einem Zehntel der Versuche. Die Rate variierte je nach Aufgabe. Das Ergebnis hatte auch Bestand, wenn der Satz in einem langen „system prompt“ (System-Prompt) stand. Das angeforderte Feature funktionierte in beiden Fällen in fast jedem Versuch.

In denselben Tests verbrauchte das Modell mit dem Satz außerdem etwa das 1,5-Fache an Output-Token und nahm mehrere Änderungen vor, um die niemand gebeten hatte, viele davon neue Tests und Dokumentation. Abgesehen von Fehlerbehebungen änderte es in einem von sechs bis zehn Versuchen das Verhalten eines bestehenden Features, bei höherem Effort häufiger. Seine abschließende Zusammenfassung nannte die größeren Änderungen, ließ kleine aber oft weg, also prüfe den Diff und nicht nur die Zusammenfassung.

Lass den Zuständigkeitssatz weg, wenn der Code dem Nutzer gehört und er ihn so wenig wie möglich geändert haben möchte. Eine Regel an anderer Stelle im Prompt, die den Umfang begrenzt, hebt den Zuständigkeitssatz nicht auf. In Anthropics Tests führte das Modell mit „Keine Refactorings, Umbenennungen oder Aufräumarbeiten im Vorbeigehen“ weiter oben im selben Prompt dennoch in etwa einem Drittel der Versuche wiederholten Code zusammen.

Nutzer während langer Turns auf dem Laufenden halten

Claude Fable 5.2 schreibt während langer Serien von Tool-Aufrufen manchmal wenig Text für den Nutzer. Das Modell macht möglicherweise auch seinen ersten Tool-Aufruf, ohne zu sagen, was es vorhat.

Prüfe zuerst, ob dein Client die Updates des Modells empfängt. Bei Claude Fable 5.2 kommen die Updates, die das Modell zwischen Tool-Aufrufen schreibt, als Fortschrittsupdate-thinking-Blöcke zurück. Diese Updates sagen, was das Modell gefunden hat und was es als Nächstes tut. Ihr Text ist beim Standardwert "omitted" für thinking.display leer. Ein Client, der nur text-Blöcke darstellt, kann daher während eines langen agentischen Turns stumm wirken. Setze display: "updates" (Beta, Header thinking-display-updates-2026-08-18), um eine kurze Zusammenfassung jedes Updates zu erhalten, oder "summarized", um die Updates zusammen mit zusammengefasstem Nachdenken zu erhalten. Stelle dann die nicht leeren thinking-Blöcke zwischen den Tool-Aufrufen dar.

Häufige Updates sind am wichtigsten, wenn ein Nutzer die Arbeit in Echtzeit verfolgt, wie beim interaktiven Programmieren. Wenn deine Nutzer die Arbeit verfolgen und trotzdem zu wenige Updates bekommen, nutze eine oder mehrere dieser Optionen.

Wenn du deinen „harness“ (Ausführungsumgebung) ändern kannst, ist es eine wirksame Option, ihn aufeinanderfolgende Tool-Aufruf-Schritte zählen zu lassen, die dem Nutzer nichts zu lesen geben: kein text-Block und kein thinking-Block mit Text. Zähle mit display auf "updates" oder "summarized", denn bei "omitted" ist jeder thinking-Block leer. Diese Option funktioniert, sofern deine Plattform System-Nachrichten mitten in der Konversation unterstützt. Lass den Harness nach mehreren solchen Schritten in Folge diese Erinnerung nach den neuesten Tool-Ergebnissen als turn-bezogene System-Nachricht (clear_at: "next_user_message", Beta, Header mid-conversation-system-clear-at-2026-08-21) anhängen:

The user hasn't heard from you in a while: say in a few words what you're doing, then continue.

In Anthropics Tests mit mehrstufigen Programmieraufgaben halbierte die Erinnerung die längste stumme Strecke ungefähr, ohne spürbaren Anstieg bei Token oder Zeit.

Belasse jede Erinnerung in späteren Anfragen in messages. Eine zu entfernen oder umzuformulieren bearbeitet einen früheren Turn, wodurch die Thinking-Blöcke danach ungültig werden. Siehe Erinnerungen pro Turn als turn-bezogene System-Nachrichten senden.

Um außerdem eine Einleitungszeile vor dem ersten Tool-Aufruf, kurze Updates und eine abschließende Zusammenfassung zu erhalten, füge deinem System-Prompt diesen Text hinzu:

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.

In Anthropics Tests mit Programmieraufgaben äußerte sich das Modell mit diesem Text jedes Mal vor seinem ersten Tool-Aufruf. Der Text erhöhte auch die Output-Token pro Aufgabe um etwa 20 Prozent. Verwende diesen Text dort, wo ein Mensch direkt beteiligt ist. Um die meisten Updates zu erhalten, kombiniere ihn mit der Erinnerung, die dein Harness anhängt.

Wenn du den Harness nicht ändern kannst oder deine Plattform keine System-Nachrichten mitten in der Konversation hat, füge deinem System-Prompt diesen Satz hinzu:

Every few tool calls, give the user a one-line update on where things stand.

In Anthropics Tests mit Workflow-Automatisierungsaufgaben beseitigte dieser Satz die meisten langen stummen Strecken.

Selbst mit der Erinnerung und dem Einleitungs- und Zusammenfassungstext zusammen musst du mit Serien von mehreren Tool-Aufrufen zwischen Updates rechnen. Claude Fable 5.2 funktioniert gut bei langlaufenden asynchronen Aufgaben, bei denen der Nutzer für das Ergebnis zurückkommt, statt jeden Schritt zu verfolgen. Lücken zwischen Updates spielen dort eine geringere Rolle.

Erwartungen für Subagenten festlegen

Wie viel Arbeit Claude Fable 5.2 an „subagents“ (Subagenten) delegiert, hängt von deinem Harness und deinen Aufgaben ab. In Anthropics Tests mit kurzen Aufgaben und einem minimalen Tool zum Starten von Subagenten startete es selten einen. In einem agentischen Programmierprodukt, dessen Prompts zur Delegation einladen, delegiert es bereitwillig.

Wenn dein System-Prompt, deine Skills oder Agent-Dateien das Modell zur Delegation auffordern, überprüfe zuerst diese Zeilen. Ändere die Beschreibung des Tools, das Subagenten startet, nur dann, wenn Claude Fable 5.2 weiterhin mehr Subagenten startet, als deine Aufgaben erfordern. Wenn das Tool eine schlichte Beschreibung hat und nichts anderes in deinen Prompts zur Delegation auffordert, brauchst du wahrscheinlich keine neue Beschreibung.

Gib in der neuen Beschreibung an, was ein Subagent zu den Kosten einer Sitzung beiträgt, sag, wann sich Delegation lohnt und wann nicht, und erkläre dem Modell, wie es einen gestarteten Subagenten instruieren soll. Die von Anthropic getestete Beschreibung tut diese drei Dinge und stellt die Kosten an den Anfang. Eine solche Beschreibung ist am nützlichsten, wenn dein Harness bereits zur Delegation einlädt und Subagenten einen großen Teil deines Token-Verbrauchs ausmachen.

In Anthropics Tests mit kurzen Aufgaben delegierte das Modell mit der getesteten Beschreibung etwa ein Drittel seltener als mit einer, die hauptsächlich Gründe für Delegation aufzählte. Der Aufgabenerfolg war gleich.

In der getesteten Beschreibung halten die einleitenden Sätze zu den Kosten die Delegation zurück. Sag weniger über Kosten, wenn das Modell zu wenig delegiert. Wenn es weiterhin zu viel delegiert, sag mehr darüber, was ein Subagent in deinem Harness kostet, und teste die Änderung.

Anthropic beobachtete außerdem, dass Claude Fable 5.2 in einem agentischen Programmierprodukt bei höheren Effort-Stufen wie xhigh und max Subagenten nutzte, um seine eigene Arbeit zu überprüfen. Claude Fable 5.1 tat dies bei denselben Aufgaben nicht. Frühe Tester erzielten gute Ergebnisse mit Claude Fable 5.2 als Planer und Orchestrator für andere Modelle. Delegation kann Arbeit beschleunigen, die sich gut parallelisieren lässt. Subagenten können jedoch einen großen Teil der Kosten einer Sitzung ausmachen, also prüfe, auf welchem Modell dein Harness Subagenten standardmäßig ausführt.

Verhindern, dass sich Vorsicht aufstaut

Vorsichtige Anweisungen stauen sich überall dort auf, wo Kontext übernommen wird: in Speicher, Notizen, Anweisungsdateien und Nachrichten zwischen Agenten. Claude Fable 5.2 befolgt diese Anweisungen genau, daher bittet es möglicherweise um Freigaben, die es nicht braucht, oder hält Routinearbeit zurück. Einige frühe Tester haben dieses Verhalten beobachtet, meist dort, wo mehrere Agenten zusammenarbeiten. Frühere Modelle befolgen solche Anweisungen ebenfalls, aber in einem der hier beschriebenen Setups hielt sich nur Claude Fable 5.2 zurück.

Wenn du dieses Verhalten beobachtest, räume auf, was deine Agenten mit sich tragen:

• Entferne Notizen, die du nicht mehr brauchst. In Anthropics Tests mit simulierten Aufgaben besagte eine von einem Dutzend Notizen aus früheren Sitzungen, niemals einen erneuten Versuch zu unternehmen. Mit diesen Notizen im Kontext und ohne etwas im Prompt, das erneute Versuche erlaubte, versuchte das Modell es nach einem ausgelasteten Tool in etwa vier von zehn Versuchen erneut, gegenüber fast allen ohne diese Notizen.
• Benenne die Schritte, die keine Freigabe brauchen. In Anthropics Tests mit simulierten Aufgaben enthielt der Kontext „niemals“-Regeln, Notizen und die Bedingungen eines Reviewers. Eine Zeile am Ende der Regeln, die erneute Versuche unter den Schritten ohne Freigabepflicht aufführte, steigerte die erneuten Versuche von fast keinen auf etwa die Hälfte der Versuche. Im selben Setup änderte eine allgemeine Anweisung, freier zu handeln, nichts. Nenne erneute Versuche nur für Aufrufe, die sich gefahrlos wiederholen lassen.
• Prüfe, was Reviewer-Agenten anhängen. In Anthropics Tests mit simulierten Aufgaben hatte ein Setup eine Zeile im Prompt, die erneute Versuche unter den Schritten ohne Freigabepflicht aufführte, und das „beim ersten Fehler anhalten“ eines Reviewers im Kontext. Claude Fable 5.2 unternahm in etwa einem Drittel der Versuche keinen erneuten Versuch. Claude Fable 5.1 und Claude Opus 5.5 versuchten es erneut.
• Schreib die Ausnahme in die Regel. In Anthropics Tests mit simulierten Aufgaben hatte die verantwortliche Person einen Schritt freigegeben. Unter einer „niemals“-Regel führte das Modell diesen Schritt in etwa einem von zehn Versuchen aus. Eine separate Zeile, die besagte, dass ein freigegebener Schritt seine Zustimmung hat, veränderte diese Rate kaum. Als die Regel selbst besagte, zuerst eine Zustimmung einzuholen, führte das Modell den Schritt in etwa neun von zehn Versuchen aus. Siehe Freigaben.

Behalte außerdem deinen eigenen Bestätigungsschritt für riskante oder irreversible Aktionen bei.

Für frühere Modelle geschriebene Anweisungen überprüfen

Wenn du zu Claude Fable 5.2 migrierst, überprüfe deine Prompts. In Anthropics Tests erhöhten einige für frühere Modelle geschriebene Anweisungen die Kosten, verursachten Nebenwirkungen oder hatten keine Wirkung mehr. Überdenke diese Anweisungen:

• Dauerhafte Anweisungen zur Delegation: Zeilen, die Arbeit an Subagenten weiterreichen, können in System-Prompts, Skills und Agent-Dateien stehen. Lies diese Dateien, bevor du migrierst. Wenn das Modell in deinen Tests mehr Subagenten startet, als deine Aufgaben erfordern, entferne die Zeilen, die du nicht mehr brauchst. Siehe Erwartungen für Subagenten festlegen.
• Ein Token-Budget, das dein Harness in den Prompt schreibt: Manche Harnesses teilen dem Modell im Prompt mit, wie viele Token die Aufgabe verbrauchen darf und wie viele noch übrig sind. Die Größe dieses Budgets verändert, wie viel Claude Fable 5.2 verbraucht. In Anthropics Tests mit Programmieraufgaben bei high und xhigh Effort senkte das Entfernen eines großen Budgets die Kosten bei gleichwertiger Leistung. Teste deine Aufgaben ohne das Budget. Dieses Ergebnis betrifft Text im Prompt, nicht die Task-Budgets der API, eine Beta-Funktion, die in den Tests nicht abgedeckt wurde.
• Harness-Code, der frühere Turns bearbeitet: Claude Fable 5.2 verwendet „preserved thinking“ (beibehaltenes Nachdenken). Wenn dein Harness zwischen Anfragen den System-Prompt, die Tools oder eine frühere Nachricht ändert, werden die Thinking-Blöcke, die auf die geänderte Stelle im Verlauf folgen, ungültig. Standardmäßig lehnt die Messages API die Anfrage dann ab, und die Message Batches API verwirft diese Blöcke. Um den Verlauf ohne diesen Fehler zu kürzen, verwende „context editing“ (Kontextbearbeitung) oder eine „compaction“ (Komprimierung), die nach der Zusammenfassung keine früheren Turns behält. Damit auch die Messages API die Blöcke verwirft, setze thinking.block_binding.prefix_mismatch_behavior auf "drop_block" (Beta, Header thinking-binding-controls-2026-08-01). In Anthropics Tests dachte das Modell, wenn früheres Nachdenken in jedem Turn verworfen wurde, erneut nach und verbrauchte mehr Output-Token. Das ist der schlimmste Fall, und der Anstieg hängt davon ab, wie oft dein Harness frühere Turns bearbeitet. Abgesehen von Komprimierung und Kontextbearbeitung halte den Verlauf rein anhängend. So bleibt die Cache-Trefferquote hoch, und kein Nachdenken wird verworfen. Miss die Output-Token bei deinen eigenen Aufgaben, bevor du dich auf "drop_block" verlässt. Siehe Was die API mit einem ungültigen Block macht und Änderungen vornehmen, ohne das Präfix zu bearbeiten.
• Die Zeilen „betrachte diese Antwort als erledigt“: Prompting für Claude Opus 5.5 bietet zwei Sätze für Chat-System-Prompts. Sie weisen das Modell an, eine frühere Antwort als erledigt zu betrachten und sein Nachdenken auf die neue Nachricht zu konzentrieren. In Anthropics Tests bei high Effort verringerten diese Sätze das Nachdenken von Claude Fable 5.2 bei Folgefragen, aber das Modell wies auch deutlich seltener auf Fehler in seinen früheren Antworten hin. Lass diese Zeilen weg, wenn das Modell seine früheren Antworten weiterhin überprüfen soll. Teste andernfalls, ob das Modell seine eigenen Fehler noch benennt, bevor du die Zeilen übernimmst.
• Anweisungen, weniger nachzudenken: Claude Fable 5.1 befolgt meist eine Zeile wie „antworte direkt ohne Abwägen“. In Anthropics Tests hielt eine solche Zeile Claude Fable 5.2 bei medium und darüber nicht vom Nachdenken ab. Entferne diese Zeilen und senke die Effort-Stufe, wie in Effort kalibrieren beschrieben.
• Stilregeln fürs Schreiben: Claude Fable 5.2 befolgt Stilregeln genau, daher kann eine harte Grenze wie „eine Anweisung pro Satz, mit höchstens 20 Wörtern“ seine Prosa abgehackt wirken lassen. Entferne die Regeln, die du nicht mehr brauchst, bevor du den Text aus Berichte leicht verständlich machen hinzufügst.
• Angesammelte Regeln, Notizen und Erinnerungen: Speicherdateien, Notizen und Anweisungsdateien sammeln mit der Zeit Vorsichtsmaßnahmen an, und das Modell hat einige davon möglicherweise selbst geschrieben. Lösche vor der Migration die Vorsichtsmaßnahmen, deren Grund nicht mehr besteht, und formuliere absolute Regeln so um, dass sie ihren Geltungsbereich und ihren Grund nennen. Wenn ein System bereits feststeckt, erwäge, es mit gekürztem Speicher und gekürzten Notizen neu zu starten, und bewahre eine Kopie der Originale auf. Siehe Verhindern, dass sich Vorsicht aufstaut.

Berichte leicht verständlich machen

Nach langer agentischer Arbeit haben die Personen, die den Abschlussbericht von Claude Fable 5.2 lesen, die dahinterstehenden Tool-Aufrufe oder Dateien meist nicht gesehen. Der Bericht muss für sich allein verständlich sein.

Wenn du Claude Fable 5.2 bittest, Abschlussberichte oder Übergaben zu schreiben, füge deinem System-Prompt diesen Text hinzu und passe ihn an deine Leser und dein Produkt an:

# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.

Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.

In Anthropics Tests mit agentischen Aufgaben machte dieser Text Abschlussberichte weniger dicht, mit weniger Semikolons. Bei Workflow-Automatisierungsaufgaben machte er auch die Sätze kürzer. Du kannst außerdem Anweisungen zur Länge hinzufügen oder das Modell bitten, bestimmte Details aufzunehmen.

Ablehnungen durch Schutzmechanismen

Claude Fable 5.2 führt Sicherheitsklassifikatoren aus, die eine Anfrage ablehnen können. Eine abgelehnte Anfrage liefert stop_reason: "refusal" zurück, und stop_details.category nennt die Ablehnungskategorie:

• cyber: Die Anfrage könnte Cyberschäden ermöglichen, etwa die Entwicklung von Malware oder Exploits.
• bio: Die Anfrage könnte biologische Schäden ermöglichen, etwa gefährliche Labormethoden.
• frontier_llm: Die Anfrage könnte bei der Entwicklung konkurrierender KI-Modelle helfen.
• reasoning_extraction: Die Anfrage fordert das Modell auf, sein internes Nachdenken im Antworttext wiederzugeben.
• general_harms: Die Anfrage fällt unter einen anderen Bereich der Nutzungsrichtlinien.

Harmlose Arbeit in der Cybersicherheit und den Biowissenschaften kann ebenfalls die Klassifikatoren cyber und bio auslösen. Wenn sie die legitime Arbeit deiner Organisation blockieren, sieh dir Anthropics Cyber Verification Program und Life Sciences Verification Program an. Claude Mythos 5.2 bietet dieselben Fähigkeiten wie Claude Fable 5.2, jedoch nur für Organisationen, die über diese Programme verifiziert wurden.

Wenn deine Prompts, Skills oder Tool-Beschreibungen das Modell auffordern, sein Nachdenken in die Antwort zu schreiben, entferne diese Anweisungen. Um zu sehen, wie das Modell nachgedacht hat, setze display: "summarized" und lies die Thinking-Blöcke. Siehe Reasoning in Thinking-Blöcken belassen.

Um eine abgelehnte Anfrage mit einem anderen Modell erneut zu versuchen, siehe Ablehnungen, Fallback und Abrechnung.

Wo du anfangen solltest

Wenn du migrierst, arbeite diese Schritte der Reihe nach ab:

1. Setze effort explizit auf high und führe deine Evals dann auch bei medium und xhigh aus.
2. Lies die System-Prompts, Skills, Agent-Dateien, Speicherdateien, Notizen und Harness-Texte, die du übernimmst. Entferne oder teste die Anweisungen, die unter Für frühere Modelle geschriebene Anweisungen überprüfen aufgeführt sind.
3. Führe deine längsten agentischen Aufgaben aus. Notiere, wo das Modell vorzeitig aufhört, um Freigaben bittet, die es nicht braucht, verstummt, mehr delegiert, als die Aufgabe erfordert, oder bestehenden Code ergänzt, wo du ihn umstrukturiert haben wolltest.
4. Wende die Hinweise für jedes beobachtete Verhalten einzeln an und miss ihre Wirkung und ihre Token-Kosten bei deinen eigenen Aufgaben.