---
title: Prompting für Claude Sonnet 5.5
url: https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5
description: "Prompting-Muster speziell für Claude Sonnet 5.5: Effort, Initiative und Umfang, Ausführung ohne vorgelagertes Nachdenken, JSON-Ausgabe, Fortschrittsupdates, Tool-Nutzung, Nachrichten während eines Turns, Verifizierung bei Coding-Aufgaben, Tool-Aufrufe, visuelle Eingaben und Ablehnungen."
---

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](https://platform.claude.com/docs/de/models/sonnet-5-5/whats-new-sonnet-5-5). Techniken, die für alle aktuellen Claude-Modelle gelten, findest du unter [Best Practices für Prompting](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/claude-prompting-best-practices).

Bestehende Prompts für Claude Sonnet 5 sollten ohne Änderungen gut funktionieren, und die Muster in [Prompting für Claude Sonnet 5](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#calibrate-effort)
* 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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#steer-initiative-and-scope)
* Deine Integration läuft heute mit deaktiviertem Nachdenken: [Ausführung ohne vorgelagertes Nachdenken](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#running-without-up-front-thinking)
* JSON-Antworten auf Aufgaben, die einige Denkschritte erfordern, sind falsch oder lassen sich nicht parsen: [Reasoning-Aufgaben mit JSON-Ausgabe](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#reasoning-tasks-with-json-output)
* Lange agentische Turns wirken stumm: [Fortschrittsupdates für Nutzer](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#user-facing-progress-updates)
* Das Modell antwortet aus seinem Trainingswissen, obwohl eine Suche geänderte Details erfassen würde: [Tool-Nutzung in Chat und Wissensarbeit](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#tool-use-in-chat-and-knowledge-work)
* Nachrichten, die Nutzer während einer Aufgabe senden, werden ignoriert oder als eingeschleuster Text behandelt: [Nutzernachrichten während eines Turns](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#mid-turn-user-messages-and-task-budgets)
* Codeänderungen werden als erledigt gemeldet, ohne dass Tests oder ein Build ausgeführt wurden: [Verifizierung bei Coding-Aufgaben](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#verification-on-coding-tasks)
* Das Modell ruft ein Tool mit falscher Groß-/Kleinschreibung auf oder übergibt einen Parameter unter einem leicht abweichenden Namen: [Tolerante Behandlung von Tool-Aufrufen](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#tolerant-tool-call-handling)
* Antworten zu dichten Diagrammen oder technischen Zeichnungen übersehen Details: [Tools für komplexe visuelle Eingaben](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#tools-for-complex-visual-inputs)
* Anfragen liefern `stop_reason: "refusal"` zurück: [Ablehnungen durch Schutzmechanismen](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#safeguard-refusals)

<Note>
  Die fünf Breaking Changes der API bei der Migration von Claude Sonnet 5 findest du im [Migrationsleitfaden](https://platform.claude.com/docs/de/models/sonnet-5-5/migration-guide#migrating-from-claude-sonnet-5).
</Note>

## Effort kalibrieren

[Effort](https://platform.claude.com/docs/de/build-with-claude/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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#verification-on-coding-tasks). 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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#steer-initiative-and-scope).

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](https://platform.claude.com/docs/de/build-with-claude/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 `effort`-Werts auf oberster Ebene zwischen Anfragen macht den Prompt-Cache ungültig. Um die Stufe mitten in einer Konversation zu ändern, verwende stattdessen eine [Effort-Änderung pro Nachricht](https://platform.claude.com/docs/de/build-with-claude/effort#change-effort-mid-conversation-beta) (Beta), die den Cache erhält. Eine Änderung gilt für jeden späteren Turn, bis eine andere sie ersetzt. Füge zum Beispiel in einer interaktiven Sitzung auf `low` vor dem schwierigen Problem des Nutzers eine Änderung auf `high` ein und eine Änderung zurück auf `low`, nachdem Claude es beantwortet hat. Effort-Änderungen pro Nachricht erfordern adaptives Nachdenken. Mit `between_tools` liefern sie einen 400-Fehler zurück, wie [Ausführung ohne vorgelagertes Nachdenken](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#running-without-up-front-thinking) 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:

```text wrap
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:

```text wrap
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:

```text wrap
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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#reasoning-tasks-with-json-output).

## 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](https://platform.claude.com/docs/de/build-with-claude/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:

```text wrap
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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#calibrate-effort) 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](https://platform.claude.com/docs/de/build-with-claude/thinking#progress-updates) 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](https://platform.claude.com/docs/de/models/sonnet-5-5/migration-guide#text-between-tool-calls) 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](https://platform.claude.com/docs/de/build-with-claude/mid-conversation-system-messages#turn-scoped-system-messages) (Beta), mit einem Text wie diesem:

```text wrap
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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#mid-turn-user-messages-and-task-budgets) 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](https://platform.claude.com/docs/de/build-with-claude/preserved-thinking) 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:

```text wrap
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](https://platform.claude.com/docs/de/build-with-claude/mid-conversation-system-messages), 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](https://platform.claude.com/docs/de/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5#user-facing-progress-updates), 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](https://platform.claude.com/docs/de/build-with-claude/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:

```text wrap
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`](https://platform.claude.com/docs/de/agents-and-tools/tool-use/handle-tool-calls#handling-errors-with-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](https://platform.claude.com/cookbook/multimodal-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](https://platform.claude.com/docs/de/build-with-claude/refusals-and-fallback#refusal-response):

* `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 `cyber`-Klassifikator die legitime Sicherheitsarbeit deiner Organisation blockiert, kannst du dich für das [Cyber Verification Program](https://support.claude.com/en/articles/14604842) bewerben. Wenn der `bio`-Klassifikator die Life-Sciences-Arbeit deiner Organisation blockiert, kannst du dich für das [Life Sciences Verification Program](https://www.anthropic.com/news/life-sciences-verification-program) bewerben.

Wenn du den [serverseitigen Fallback](https://platform.claude.com/docs/de/build-with-claude/refusals-and-fallback#server-side-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](https://platform.claude.com/docs/de/models/sonnet-5-5/whats-new-sonnet-5-5#refusals-fallback-and-billing).

Wenn deine Prompts das Modell auffordern, sein Reasoning in die Antwort aufzunehmen, entferne diese Anweisungen, denn sie provozieren `reasoning_extraction`-Ablehnungen. Lies das Reasoning bei adaptivem Nachdenken stattdessen aus Blöcken mit [zusammengefasstem Nachdenken](https://platform.claude.com/docs/de/build-with-claude/thinking#summarized-thinking) (`display: "summarized"`). Du kannst weiterhin um eine kurze Erklärung der Antwort oder eine Zusammenfassung der durchgeführten Aktionen bitten; siehe [Reasoning in Thinking-Blöcken belassen](https://platform.claude.com/docs/de/build-with-claude/refusals-and-fallback#keep-reasoning-in-thinking-blocks).