Prompting für Claude Sonnet 5.5

Dieser Leitfaden behandelt die Prompting-Muster, die speziell für Claude Sonnet 5.5 gelten. Die API-Änderungen des Modells findest du unter Neuerungen in Claude Sonnet 5.5. Techniken, die für alle aktuellen Claude-Modelle gelten, findest du unter Best Practices für Prompting.

Bestehende Prompts für Claude Sonnet 5 sollten ohne Änderungen gut funktionieren, und die Muster in Prompting für Claude Sonnet 5 bleiben ein sinnvoller Ausgangspunkt. Für die schwierigsten Aufgaben mit langem Zeithorizont ist ein Opus-Modell die bessere Wahl. Beginne mit dem Abschnitt, der zu deiner Beobachtung passt:

• Du bist unsicher, welche Effort-Stufe du verwenden sollst, oder Turns laufen länger oder kürzer als bei Claude Sonnet 5: Effort kalibrieren
• Das Modell hält an, um Rückfrage zu halten, bevor eine Coding-Aufgabe erledigt ist, oder es tut mehr, als du verlangt hast: Initiative und Umfang steuern
• Deine Integration läuft heute mit deaktiviertem Nachdenken: Ausführung ohne vorgelagertes Nachdenken
• JSON-Antworten auf Aufgaben, die einige Denkschritte erfordern, sind falsch oder lassen sich nicht parsen: Reasoning-Aufgaben mit JSON-Ausgabe
• Lange agentische Turns wirken stumm: Fortschrittsupdates für Nutzer
• Das Modell antwortet aus seinem Trainingswissen, obwohl eine Suche geänderte Details erfassen würde: Tool-Nutzung in Chat und Wissensarbeit
• Nachrichten, die Nutzer während einer Aufgabe senden, werden ignoriert oder als eingeschleuster Text behandelt: Nutzernachrichten während eines Turns
• Codeänderungen werden als erledigt gemeldet, ohne dass Tests oder ein Build ausgeführt wurden: Verifizierung bei Coding-Aufgaben
• Das Modell ruft ein Tool mit falscher Groß-/Kleinschreibung auf oder übergibt einen Parameter unter einem leicht abweichenden Namen: Tolerante Behandlung von Tool-Aufrufen
• Antworten zu dichten Diagrammen oder technischen Zeichnungen übersehen Details: Tools für komplexe visuelle Eingaben
• Anfragen liefern stop_reason: "refusal" zurück: Ablehnungen durch Schutzmechanismen

Effort kalibrieren

Effort („effort" (Aufwand)) ist die wichtigste Stellschraube dafür, wie viel Claude Sonnet 5.5 nachdenkt, und damit für Qualität, „latency" (Latenz) und Kosten. Die Stufen wurden neu kalibriert: Eine Stufe erzeugt nicht dieselbe Menge an Nachdenken wie dieselbe Stufe bei Claude Sonnet 5. Führe einen neuen Durchlauf mit deinen eigenen Evals durch, statt die Einstellung zu übernehmen, die du bei Claude Sonnet 5 verwendet hast. Beginne mit high, dem Standard in der Claude API, es sei denn, deine Workload ist agentisch oder latenzkritisch. Für agentisches Coding und mehrstufige Tool-Nutzung beginne bei klar spezifizierten Aufgaben mit medium und wechsle bei schwierigeren oder längeren Aufgaben zu high. Für Chat und andere latenzkritische Arbeit beginne mit medium oder low, denn höherer Effort bedeutet eine längere Wartezeit, bevor die Antwort beginnt. Erhöhe den Effort, wenn die Qualität es erfordert.

Niedrigerer Effort verändert auch, wie das Modell agentische Arbeit abschließt. Bei low hält es sein Nachdenken kurz und kann die Verifizierung einer Änderung überspringen. Siehe Verifizierung bei Coding-Aufgaben. Bei low und medium hält es bei langen agentischen Aufgaben eher an und hält Rückfrage mit dem Nutzer, bevor es fertig ist. Siehe Initiative und Umfang steuern.

Drei Anpassungen helfen:

• Setze max_tokens mit genügend Spielraum für das Nachdenken und die erwartete Antwort. Nachdenken zählt zu max_tokens, auch wenn der Inhalt des Nachdenkens nicht an dich zurückgegeben wird. Ein Limit, das für eine Anfrage ohne Nachdenken bemessen ist, kann die Antwort abschneiden. Für agentisches Coding setze max_tokens auf 128.000, das Maximum des Modells, und nutze Streaming für die Antwort.
• Reserviere xhigh und max für Arbeit, bei der du einen Qualitätsgewinn gemessen hast, denn Nachdenken und Antworten werden dort deutlich länger. Auf diesen Stufen wird between_tools nicht akzeptiert, sodass vorgelagertes Nachdenken nicht deaktiviert werden kann.
• Um weniger Nachdenken zu erhalten, senke die Effort-Stufe. Ab medium denkt das Modell vor fast jeder Antwort kurz nach, selbst bei einer Begrüßung, was die Zeit bis zum ersten sichtbaren Token verlängert. Das Modell im System-Prompt zu bitten, weniger nachzudenken, reduziert sein Nachdenken nicht zuverlässig. Bei low überspringt es das Nachdenken bei den meisten einfachen Anfragen.

Eine Änderung des übergeordneten effort-Werts zwischen Anfragen invalidiert den Prompt-Cache. Um einzelne Turns auf einer anderen Stufe auszuführen, verwende stattdessen eine Effort-Änderung pro Nachricht (Beta), die den Cache erhält. Führe zum Beispiel eine interaktive Sitzung mit low aus und erhöhe den Effort auf high, wenn der Nutzer ein schwieriges Problem einreicht. Effort-Änderungen pro Nachricht erfordern adaptives Nachdenken. Mit between_tools liefern sie einen 400-Fehler zurück, wie Ausführung ohne vorgelagertes Nachdenken erklärt.

Initiative und Umfang steuern

Wie weit Claude Sonnet 5.5 eigenständig geht, hängt von der Effort-Stufe und der Anfrage ab. Bei niedrigerem Effort hält es manchmal Rückfrage, bevor eine Coding-Aufgabe erledigt ist. Bei höherem Effort oder bei einer offenen Anfrage kann es mehr tun, als du verlangt hast. Steuere es über die Effort-Stufe und über Anweisungen in deinem System-Prompt.

Arbeit zu Ende führen. Bei agentischen Coding-Aufgaben mit low- und medium-Effort hält das Modell manchmal Rückfrage, bevor die Arbeit erledigt ist. Es könnte pausieren, um einen Plan zu bestätigen, eine Frage stellen, die es selbst beantworten könnte, oder nach einem Teil einer mehrteiligen Aufgabe anhalten, um zu fragen, ob es weitermachen soll. Probiere zuerst eine höhere Effort-Stufe. Damit das Modell weiterarbeitet, ohne den Effort zu ändern, füge Folgendes zu deinem System-Prompt hinzu:

Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

Mit diesem Prompt führt das Modell bei low- und medium-Effort mehr von der Arbeit zu Ende, sodass Sitzungen auf diesen Stufen länger laufen und mehr kosten. Der Prompt ersetzt nicht deine eigenen Regeln zu riskanten oder irreversiblen Aktionen. Behalte diese Regeln in deinem System-Prompt.

Nicht angeforderte Ergänzungen beim Coding. Das Modell neigt dazu, Tests, Dokumentation und kleine unterstützende Dateien hinzuzufügen, die zu den Konventionen deines Repositorys passen, auch wenn du nicht danach fragst. Das tut es auf jeder Effort-Stufe, und bei höherem Effort häufiger. Die angeforderte Änderung selbst bleibt nah an dem, was verlangt wurde. Die meisten Teams werden das begrüßen. Wenn du Änderungen bevorzugst, die auf das ausdrücklich Angeforderte beschränkt sind, füge nur den zweiten Absatz dieses Prompts hinzu, der mit „When the work the user asked for is done" beginnt. Bei xhigh- und max-Effort reduziert dieser Absatz solche Ergänzungen und macht Änderungen insgesamt kleiner.

Gründlichkeit bei xhigh- und max-Effort. Auf diesen Stufen ist das Modell besonders gründlich. Nachdem es eine Aufgabe abgeschlossen hat, kann es eigene Runden der Überprüfung und Verifizierung starten, manchmal mit Subagenten, wenn dein Harness diese bereitstellt. Es kann auch verwandte Korrekturen vornehmen, die ihm unterwegs aufgefallen sind. Das kostet mehr Zeit und Token, also führe Routinearbeit mit high oder darunter aus, wo dies selten vorkommt. Wenn du die zusätzliche Gründlichkeit dieser Effort-Stufen möchtest, sie aber auf die Aufgabe selbst lenken willst, füge Folgendes zu deinem System-Prompt hinzu:

When the work the user asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user asked for a review. If you think a deeper review is worth doing, say so at the end.

In Tests mit Coding-Aufgaben bei max-Effort hielt dies das Modell davon ab, Reviewer-Subagenten zu starten, und senkte die Sitzungskosten um etwa ein Drittel, ohne Qualitätsänderung. Es macht selbst gestartete Überprüfungsrunden durch den Hauptagenten seltener, beseitigt sie aber nicht vollständig.

Offene Anfragen. Wenn eine Anfrage offen formuliert ist, zum Beispiel „zeig mir, was du damit machen kannst", kann das Modell beginnen, eine Präsentation, einen Bericht oder ein Video zu erstellen, obwohl du nur Ideen wolltest. Wenn du zuerst Ideen oder einen Plan möchtest, sag das in der Anfrage oder füge Folgendes zu deinem System-Prompt hinzu:

When the user asks for ideas, options or a plan, give them that and stop. Don't start building or changing anything until they say to go ahead.

Ausführung ohne vorgelagertes Nachdenken

Um Claude Sonnet 5.5 ohne vorgelagertes Nachdenken auszuführen, sende thinking: {"type": "between_tools"}. Das ist die niedrigste Nachdenken-Einstellung bei diesem Modell, und sie wird bei high-Effort oder darunter akzeptiert. Wenn deine Integration heute mit deaktiviertem Nachdenken läuft, stelle sie auf between_tools um und prüfe diese Punkte:

• Sende between_tools bei high-Effort oder darunter. Bei xhigh- oder max-Effort liefert eine Anfrage mit between_tools einen 400-Fehler zurück. Mit between_tools kann sich der Effort auch nicht mitten in der Konversation ändern: Ein output_config.effort pro Nachricht, das von der aktuell geltenden Stufe abweicht, liefert einen 400-Fehler zurück. Um den Effort pro Turn zu variieren, verwende adaptives Nachdenken. Entferne bei between_tools jede Anweisung, die dem Modell sagt, nicht nachzudenken. Solche Anweisungen machen es wahrscheinlicher, dass das Modell interne XML-Tags in seine sichtbare Ausgabe schreibt.
• Lies die Antwort nach Blocktyp. Bei adaptivem Nachdenken kann eine Antwort mit einem thinking-Block beginnen, dessen thinking-Feld unter dem Standard display: "omitted" leer ist. Bei between_tools kann eine Antwort mit einem Fortschrittsupdate-thinking-Block beginnen. Geh nicht davon aus, dass der erste Inhaltsblock Text ist.
• Gib die thinking-Blöcke unverändert zurück. Bei between_tools kommen Notizen, die das Modell zwischen Tool-Aufrufen schreibt, weiterhin als thinking-Blöcke zurück, wenn sie länger als ein oder zwei Sätze sind. Jeder Block enthält eine Zusammenfassung der Notiz. Gib sie zusammen mit dem Rest des Assistant-Turns unverändert zurück. Ein Block, den du zurücksendest, gibt dem Modell die vollständige Notiz, die es geschrieben hat, nicht die Zusammenfassung.
• Verwende adaptives Nachdenken für Reasoning-Aufgaben ohne Tools. In einer Anfrage ohne Tools bedeutet between_tools, dass das Modell antwortet, ohne vorher nachzudenken. Für Aufgaben, die einige Denkschritte erfordern, verwende stattdessen adaptives Nachdenken. Siehe Reasoning-Aufgaben mit JSON-Ausgabe.

Reasoning-Aufgaben mit JSON-Ausgabe

Dieser Abschnitt gilt, wenn du Claude Sonnet 5.5 um eine JSON-Antwort auf eine Aufgabe bittest, die einige Denkschritte erfordert. Beispiele sind das Aufsummieren von Zahlen aus einem Dokument, das Anwenden einer Regel oder das Ranking von Elementen. Bei solchen Aufgaben antwortet das Modell oft, ohne vorher nachzudenken, insbesondere bei low- und medium-Effort. Was hilft, hängt davon ab, wie du JSON anforderst. Verwende Structured Outputs, wo sie verfügbar sind. Der Antworttext ist dann JSON, das deinem Schema entspricht, sodass nichts geparst werden muss.

Bei Structured Outputs enthält der Antworttext nur das JSON, sodass das Modell das Problem nur in seinem Nachdenken durcharbeiten kann. Wenn es das Nachdenken überspringt, kann es bei diesen Aufgaben weniger genau sein. Diese Änderungen helfen, die Genauigkeit hoch zu halten.

Bitte das Modell, zuerst nachzudenken. Füge bei adaptivem Nachdenken diese Zeile am Ende deines System-Prompts hinzu:

Think the problem through before you answer.

Mit dieser Zeile denkt das Modell häufiger nach, bevor es antwortet. Bei high-Effort bringt die Zeile die Genauigkeit nahe an das, was das Modell bei xhigh erreicht, bei einem moderaten Anstieg der Output-Token. Bei low- und medium-Effort erhöht sie die Genauigkeit, wenn auch nicht auf das Niveau, das das Modell bei high erreicht, und der Anstieg der Output-Token ist größer.

Oder verwende xhigh-Effort. Bei adaptivem Nachdenken liefert xhigh auch ohne die Zeile die höchste Genauigkeit bei diesen Aufgaben. Es verbraucht mehr Output-Token als high.

Verwende adaptives Nachdenken statt between_tools. In einer Anfrage ohne Tools denkt das Modell unter between_tools nicht nach, bevor es antwortet. Die Zeile hat dort keine Wirkung, und die Genauigkeit bei diesen Aufgaben ist geringer. Verwende für diese Anfragen adaptives Nachdenken mit den Schritten in diesem Abschnitt. In Tests führte das Aufteilen der Anfrage in zwei, eine Anfrage für die Antwort und eine für das JSON, zu hoher Antwortgenauigkeit und JSON-Konformität, allerdings bei sehr hohen Kosten und hoher Latenz.

Bei Structured Outputs mit low- und medium-Effort denkt das Modell gelegentlich so lange nach, bis es max_tokens erreicht. Ab high-Effort kommt das fast nie vor. Behandle jede Antwort, deren stop_reason "max_tokens" ist, als fehlgeschlagen, auch wenn ihr Text gültiges JSON enthält, und wiederhole die Anfrage. Setze max_tokens hoch genug für das Nachdenken und das JSON, wie Effort kalibrieren beschreibt, aber nicht höher, als du für einen einzelnen Versuch ausgeben möchtest.

Wenn du keine Structured Outputs verwenden kannst, fordere JSON stattdessen im Prompt an. Das Modell arbeitet das Problem dann oft im Antworttext durch und schreibt das JSON am Ende. Das JSON enthält meist die richtige Antwort, aber ein Parser, der erwartet, dass die gesamte Antwort JSON ist, schlägt fehl. Zwei Dinge helfen:

• Parse den letzten JSON-Wert in der Antwort. Lies nur die text-Blöcke und behandle eine Antwort, deren stop_reason "max_tokens" ist, als fehlgeschlagen. Versuche, beginnend bei jedem { oder [, einen JSON-Wert zu parsen. Wenn einer erfolgreich geparst wird, fahre ab dem Ende dieses Werts fort, damit darin verschachtelte Werte nicht einzeln gezählt werden. Behalte den zuletzt gefundenen Wert. Nimm nicht alles vom ersten { bis zum letzten }. Das Modell schreibt gelegentlich einen Entwurf vor seinem endgültigen JSON, und dieser Bereich würde beides enthalten. Wenn deine Antwort aus mehreren aufeinanderfolgenden JSON-Werten besteht, etwa einem Datensatz pro Zeile, behalte die letzte Folge von Werten, die nur durch Leerzeichen, Kommas oder Zeilenumbrüche getrennt sind. Prüfe, ob das Ergebnis die erwarteten Felder enthält, und wiederhole die Anfrage einmal, falls nicht. In Tests machte dies nahezu jede Antwort verwendbar, ohne ihre Genauigkeit zu verändern.
• Ziehe auch xhigh-Effort mit adaptivem Nachdenken in Betracht. Das Modell arbeitet das Problem dann in seinem Nachdenken durch und liefert fast immer nur das JSON zurück. Die gesamten Output-Token bleiben etwa gleich wie bei high, weil die Ausarbeitung vom Antworttext ins Nachdenken wandert.

Fortschrittsupdates für Nutzer

Zwischen Tool-Aufrufen schreibt Claude Sonnet 5.5 an Nutzer gerichtete Notizen darüber, was es gerade herausgefunden hat und was es als Nächstes tut. Notizen, die länger als ein oder zwei Sätze sind, kommen als Fortschrittsupdate-thinking-Blöcke zurück. Kürzere Bemerkungen bleiben text. Beim Standardwert von thinking.display ist der Text eines Fortschrittsupdate-Blocks leer, sodass ein Client, der nur text-Blöcke rendert, während eines langen agentischen Turns stumm wirken kann. Das ist vor allem in Chat-Oberflächen und anderen Produkten wichtig, in denen der Nutzer die Arbeit des Modells in Echtzeit verfolgt.

Um diese Notizen anzuzeigen, setze display: "updates" (Beta, Header thinking-display-updates-2026-08-18). Bei between_tools kommen die Notizen mit ihrem Zusammenfassungstext zurück, sodass kein display-Feld nötig ist. between_tools akzeptiert kein weiteres Feld: display, budget_tokens oder block_binding, zusammen damit gesendet, liefert einen 400-Fehler zurück. Der Migrationsleitfaden zeigt, wie du die Notizen renderst. Manchmal muss das Modell dem Nutzer mitten in einem langen Turn exakten Text zeigen, etwa ein Code-Snippet oder eine Frage, die beantwortet werden muss. Gib ihm für diesen Fall ein einfaches Tool, um dem Nutzer eine Nachricht zu senden. Weise das Modell an, dieses Tool nur für solche Inhalte zu verwenden. Deklariere das Tool in der ersten Anfrage der Sitzung, damit sich die tools-Liste später nicht ändert.

Entferne als Nächstes ältere Anweisungen wie „halte alle Erkenntnisse für die abschließende Antwort zurück". Wenn du dann Updates an vorhersehbaren Stellen möchtest, zum Beispiel eine Zeile dazu, was das Modell vor seinem ersten Tool-Aufruf vorhat, und eine kurze Zusammenfassung am Ende, sag das im System-Prompt. Das Modell befolgt solche Anweisungen. Updates an festgelegten Stellen helfen am meisten bei Human-in-the-Loop-Arbeit.

Wenn lange Turns mit Tool-Aufrufen immer noch länger still bleiben, als du möchtest, kann dein Harness ein Update anstoßen. Lass ihn aufeinanderfolgende Tool-Aufruf-Schritte zählen, die dem Nutzer keinen Text und kein Fortschrittsupdate senden. Hänge nach mehreren solchen Schritten in Folge, zum Beispiel fünf, eine Erinnerung für einen Turn nach den neuesten Tool-Ergebnissen an. Sende sie als turn-bezogene Systemnachricht (Beta), mit einem Text wie diesem:

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

Wenn der Turn still bleibt, hör nach der zweiten oder dritten Erinnerung auf, weitere zu senden. Häufiger Harness-Text nach Tool-Ergebnissen kann das Modell eine „prompt injection" (Prompt-Injektion) vermuten lassen, wie Nutzernachrichten während eines Turns erklärt. Belasse jede Erinnerung bei späteren Anfragen in messages. Da die Erinnerung angehängt und nicht eingefügt und später gelöscht wird, bleiben der Prompt-Cache und das beibehaltene Nachdenken intakt. Bei high-Effort und mit einem verfügbaren Tool zum Senden von Nachrichten an den Nutzer führt die Erinnerung dazu, dass das Modell den Nutzer häufiger informiert, und verkürzt seine längsten stillen Phasen, ohne messbare Änderung der Aufgabenqualität.

Tool-Nutzung in Chat und Wissensarbeit

Bei Chat- und Wissensarbeitsaufgaben antwortet Claude Sonnet 5.5 manchmal aus seinem Trainingswissen, obwohl eine Websuche geänderte Details erfassen würde. Beispiele sind, was erlaubt, erforderlich oder kostenpflichtig ist.

Prüfe zuerst deinen Prompt auf Formulierungen, die von der Tool-Nutzung abhalten, etwa „verwende Tools nur, wenn unbedingt nötig" oder „minimiere Tool-Aufrufe", und entferne sie. Wenn dein Produkt dem Modell ein Such-Tool bereitstellt, füge dann Folgendes zu deinem System-Prompt hinzu:

Use the search tool to check specifics that may have changed since your training, such as what is allowed, required or charged, even when you feel confident. For researched work such as a report or a comparison, gather current sources rather than writing from your training knowledge.

Das ist vor allem für Recherche- und Support-Produkte wichtig, bei denen Antworten von aktuellen Details abhängen.

Nutzernachrichten während eines Turns

Claude Sonnet 5.5 ist darauf trainiert, indirekter Prompt-Injektion zu widerstehen, also bösartigen Anweisungen, die über Tool-Ergebnisse und andere Inhalte eintreffen, die es während einer Aufgabe liest. Manchmal behandelt es eine echte Nutzernachricht als mögliche Injektion. Angenommen, eine Nachricht, die der Nutzer während einer Aufgabe eingegeben hat, erreicht das Modell als Systemnachricht mitten in der Konversation, die direkt nach einem Tool-Ergebnis platziert ist, oder innerhalb eines tool_result-Blocks. Das Modell kann dem Nutzer dann mitteilen, dass das Tool-Ergebnis Text enthielt, der sich als Nachricht von ihm ausgab, und die Nachricht ignorieren oder den Nutzer bitten, sie zu bestätigen.

Ein Token-Countdown, den dein Harness nach jedem Tool-Ergebnis hinzufügt, kann dies verursachen. Ebenso, wenn Nutzer Nachrichten senden können, während das Modell mitten in einem mehrstufigen Turn ist, oder wenn dein Harness bei jedem Schritt Anweisungen oder Kontext nach den Tool-Ergebnissen hinzufügt. In jedem dieser Fälle trifft Text direkt nach den Tool-Ergebnissen ein. Bei einem Countdown oder Anweisungen pro Schritt kann das bei jedem Tool-Aufruf passieren. Eine gelegentliche Erinnerung für einen Turn, wie die in Fortschrittsupdates für Nutzer, trifft weit seltener ein. Wenn du diese Reaktion auf eine eigene Erinnerung beobachtest, sende die Erinnerung seltener. Um die Fehlinterpretation zu vermeiden:

• Platziere niemals Nutzertext innerhalb eines tool_result-Blocks. Diese Platzierung interpretiert das Modell am häufigsten falsch.
• Übermittle Nutzereingaben während eines Turns als User-Turn. Hänge die Worte des Nutzers als Textblock in der User-Nachricht an, die die tool_result-Blöcke enthält, nach dem letzten tool_result.
• Halte Harness-Hinweise, etwa Erinnerungen, in einer separaten Systemnachricht mitten in der Konversation nach den Worten des Nutzers. Platziere niemals einen Hinweis und die Worte des Nutzers im selben Block.
• Füge in interaktiven Sitzungen, in denen Nutzer während eines Turns tippen können, keinen eigenen Token- oder Budget-Countdown nach Tool-Ergebnissen hinzu. Task Budgets (Beta) fügen einen ähnlichen Countdown hinzu, aber bei ihnen wurde diese Fehlinterpretation bisher nicht beobachtet. Wenn du die Fehlinterpretation bei gesetztem Task Budget beobachtest, probiere die Sitzung ohne eines.

Verifizierung bei Coding-Aufgaben

Bei agentischen Coding-Aufgaben überprüft Claude Sonnet 5.5 seine Arbeit in der Regel, bevor es eine Änderung als erledigt meldet. Bei low-Effort meldet es eine Änderung jedoch manchmal als erledigt, ohne eine Prüfung auszuführen, die sie tatsächlich testet. Zum Beispiel könnte es die Tests des Projekts überspringen, weil die Abhängigkeiten des Projekts nicht installiert sind.

Wenn du siehst, dass Änderungen als abgeschlossen gemeldet werden, ohne dass Test- oder Build-Ausgaben im Transkript stehen, füge diesen oder einen ähnlichen Absatz zum System-Prompt hinzu. Bei low-Effort macht er übersprungene oder oberflächliche Prüfungen selten, ohne messbare Änderung der Aufgabenqualität und mit nur leicht höheren Kosten pro Aufgabe:

When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

Tolerante Behandlung von Tool-Aufrufen

Claude Sonnet 5.5 ruft ein deklariertes Tool gelegentlich unter einem Namen auf, der sich nur in der Groß-/Kleinschreibung unterscheidet, etwa bash statt Bash. Es kann auch einen bekannten Parameter unter einem leicht abweichenden Namen übergeben. Statt einen solchen Aufruf als fatalen Fehler zu behandeln, lass deinen Harness ihn auf eine von zwei Arten behandeln:

• Akzeptiere den Aufruf, wenn die Zuordnung eindeutig ist, auch wenn die Groß-/Kleinschreibung falsch ist.
• Gib ein tool_result mit is_error: true zurück, das den exakt erwarteten Namen nennt. Das Modell korrigiert den Aufruf in der Regel in seinem nächsten Turn. Siehe Fehlerbehandlung mit is_error.

Tools für komplexe visuelle Eingaben

Gib Claude Sonnet 5.5 für dichte Diagramme und technische Zeichnungen eine Möglichkeit, das Bild zuzuschneiden, zu vergrößern oder Code darauf auszuführen. Mit solchen Tools liest das Modell diese Eingaben deutlich genauer. Bei Diagrammen helfen die Tools auf jeder Effort-Stufe. Bei technischen Zeichnungen helfen sie erst ab high-Effort, und am meisten bei xhigh und max. Bei Diagrammen hilft das Hinzufügen von Tools mehr als das Erhöhen des Efforts: In Tests las das Modell Diagramme mit Tools bei high-Effort genauer als ohne Tools bei max-Effort, zu einem Bruchteil der Kosten. Das Rezept für ein Crop-Tool enthält eine funktionierende Tool-Definition.

Ablehnungen durch Schutzmechanismen

Claude Sonnet 5.5 verwendet Sicherheitsklassifikatoren, die eine Anfrage ablehnen können. Eine Ablehnung kommt als normale Antwort mit stop_reason: "refusal" an, und stop_details.category nennt die Ablehnungskategorie:

• cyber: Die Anfrage könnte Cyberschäden ermöglichen, etwa die Entwicklung von Malware oder Exploits. Das Finden von Schwachstellen in Quellcode ist erlaubt. Hochriskante Dual-Use-Cybersicherheitsarbeit ist nicht erlaubt.
• bio: Die Anfrage könnte biologische Schäden ermöglichen, etwa gefährliche Labormethoden. Alltägliche Gesundheits- und Bildungsfragen sind nicht betroffen.
• frontier_llm: Die Anfrage könnte die Entwicklung konkurrierender KI-Modelle unterstützen.
• reasoning_extraction: Die Anfrage fordert das Modell auf, sein internes Reasoning im Antworttext wiederzugeben.
• general_harms: Die Anfrage fällt unter einen anderen Bereich der Nutzungsrichtlinien. Auch harmlose Arbeit kann diese Kategorie auslösen.

Wenn der bio-Klassifikator die Life-Sciences-Arbeit deiner Organisation blockiert, kannst du dich für das Life Sciences Verification Program bewerben.

Wenn du den serverseitigen Fallback (Beta) aktivierst, wiederholt er cyber- und frontier_llm-Ablehnungen mit Claude Sonnet 5. bio-, reasoning_extraction- oder general_harms-Ablehnungen wiederholt er nicht. Siehe Ablehnungen, Fallback und Abrechnung.

Wenn deine Prompts das Modell auffordern, sein Reasoning in die Antwort aufzunehmen, entferne diese Anweisungen, denn sie provozieren reasoning_extraction-Ablehnungen. Lies bei adaptivem Nachdenken das Reasoning stattdessen aus Blöcken mit zusammengefasstem Nachdenken (display: "summarized").