Prompting für Claude Sonnet 5

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

Claude Sonnet 5 hat besondere Stärken bei Coding- und agentischen Aufgaben. Es funktioniert ohne weitere Anpassungen gut mit bestehenden Prompts für Claude Sonnet 4.6. Die Muster in diesem Leitfaden behandeln die Verhaltensweisen, die am häufigsten eine Feinabstimmung erfordern.

Antwortlänge und Ausführlichkeit

Claude Sonnet 5 passt die Antwortlänge an die Komplexität der Aufgabe an, anstatt standardmäßig eine feste „verbosity“ (Ausführlichkeit) zu verwenden. Das bedeutet in der Regel kürzere Antworten bei einfachen Nachfragen und längere bei offenen Analysen.

Wenn dein Produkt von einem bestimmten Stil oder einer bestimmten Ausführlichkeit der Ausgabe abhängt, musst du deine Prompts möglicherweise anpassen. Um beispielsweise die Ausführlichkeit zu verringern, könntest du Folgendes hinzufügen:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

Wenn du bestimmte Arten von Ausführlichkeit beobachtest (etwa übermäßiges Erklären), kannst du zusätzliche Anweisungen in deinen Prompt aufnehmen, um sie zu verhindern. Positive Beispiele, die zeigen, wie Claude mit dem angemessenen Maß an Prägnanz kommunizieren kann, sind in der Regel wirksamer als negative Beispiele oder Anweisungen, die dem Modell sagen, was es nicht tun soll.

Effort und Denktiefe kalibrieren

Der Effort-Parameter („effort“, Aufwand) ermöglicht es dir, Claudes Intelligenz gegen den Token-Verbrauch abzuwägen und Leistungsfähigkeit gegen höhere Geschwindigkeit und niedrigere Kosten einzutauschen. Bei Claude Sonnet 5 ist Effort standardmäßig auf high gesetzt, genau wie bei Claude Sonnet 4.6. Für die schwierigsten Coding- und agentischen Aufgaben erhöhe Effort auf xhigh. Experimentiere mit anderen Effort-Stufen, um Token-Verbrauch und Intelligenz weiter abzustimmen:

• max: Absolut maximale Leistungsfähigkeit ohne Einschränkungen beim Token-Verbrauch.
• xhigh: Extra hoher Effort ist die empfohlene Einstellung für die schwierigsten Coding- und agentischen Anwendungsfälle.
• high: Der Standard. Diese Einstellung balanciert Token-Verbrauch und Intelligenz für die meisten Anwendungsfälle aus.
• medium: Gut für kostensensible Anwendungsfälle, die den Token-Verbrauch reduzieren müssen und dafür Intelligenz eintauschen.
• low: Reserviere diese Stufe für kurze, klar abgegrenzte Aufgaben und latenzsensible Workloads, die nicht intelligenzsensibel sind.

Als grobe modellübergreifende Zuordnung bei der Migration: Claude Sonnet 5 auf medium ist in der Intelligenz vergleichbar mit Claude Sonnet 4.6 auf high, und Claude Sonnet 5 auf high ist vergleichbar mit Claude Sonnet 4.6 auf max. Beim Benchmarking solltest du nach beobachteter Denklänge statt nach Effort-Bezeichnung abgleichen.

Claude Sonnet 5 hält Effort-Stufen strikt ein, insbesondere am unteren Ende. Bei low und medium beschränkt das Modell seine Arbeit auf das, was gefragt wurde, anstatt darüber hinauszugehen. Das ist gut für Latenz und Kosten, aber bei mäßig komplexen Aufgaben, die mit low Effort laufen, besteht ein gewisses Risiko, dass zu wenig nachgedacht wird.

Wenn du bei komplexen Problemen oberflächliches Reasoning beobachtest, erhöhe Effort auf high oder xhigh, anstatt mit Prompts darum herumzuarbeiten. Wenn du Effort aus Latenzgründen auf low halten musst, füge gezielte Anleitungen hinzu:

This task involves multistep reasoning. Think carefully through the problem before responding.

Bei Claude Sonnet 5 ist adaptives Nachdenken („adaptive thinking“) standardmäßig aktiviert. Anfragen ohne ein thinking-Feld laufen mit adaptivem Nachdenken. Das ist eine Änderung gegenüber Claude Sonnet 4.6, wo dieselben Anfragen ohne Nachdenken liefen. Um das Nachdenken vollständig zu deaktivieren, übergib thinking: {type: "disabled"}. Da max_tokens ein hartes Limit für die gesamte Ausgabe ist (Nachdenken plus Antworttext), solltest du es für Workloads überprüfen, die auf Claude Sonnet 4.6 ohne Nachdenken liefen. Wenn du bei Claude Sonnet 4.6 bisher mit deaktiviertem Nachdenken gearbeitet hast, probiere bei Claude Sonnet 5 aktiviertes Nachdenken mit niedrigeren Effort-Stufen aus.

Das Auslöseverhalten für adaptives Nachdenken ist steuerbar. Wenn du feststellst, dass das Modell häufiger Thinking-Blöcke ausgibt, als du möchtest, was bei großen oder komplexen System-Prompts vorkommen kann, füge Anleitungen hinzu, um es zu steuern. Wie immer solltest du die Auswirkung jeder Prompting-Änderung auf die Leistung messen. Beispiel:

Thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning. When in doubt, respond directly.

Umgekehrt gilt: Wenn du schwierige Workloads auf medium ausführst und zu wenig Nachdenken beobachtest, ist der erste Hebel, Effort zu erhöhen. Wenn du feinere Kontrolle brauchst, fordere sie direkt per Prompt an.

Manuelles erweitertes Nachdenken (thinking: {type: "enabled", budget_tokens: N}) wird auf Claude Sonnet 5 nicht unterstützt und gibt einen 400-Fehler zurück. Es wurde auf Claude Sonnet 4.6 abgekündigt und ist nun entfernt. Verwende stattdessen adaptives Nachdenken mit dem Effort-Parameter.

Auslösen der Tool-Nutzung

Claude Sonnet 5 ist standardmäßig agentischer als Claude Sonnet 4.6 und greift bereitwilliger auf Tools zurück und führt Selbstverifikationsschleifen aus. Bei deaktiviertem Nachdenken greift das Modell seltener auf Tools zurück oder erwägt seltener eine Suche; wenn du bei deaktiviertem Nachdenken auf Tool-Aufrufe angewiesen bist, füge einen expliziten Hinweis im System-Prompt hinzu. Effort ist ebenfalls ein Hebel für die „tool use“ (Tool-Nutzung): Die Effort-Einstellungen high oder xhigh zeigen deutlich mehr Tool-Nutzung bei agentischer Suche und beim Coding. Für Szenarien, in denen du mehr Tool-Nutzung möchtest, kannst du deinen Prompt auch so anpassen, dass er das Modell explizit darüber instruiert, wann und wie es seine Tools richtig einsetzen soll. Wenn du beispielsweise feststellst, dass das Modell deine Websuche-Tools nicht verwendet, beschreibe klar, warum und wie es das tun sollte.

Fortschrittsmeldungen für Nutzer

Claude Sonnet 5 liefert während langer agentischer Abläufe regelmäßige, qualitativ hochwertigere Updates an den Nutzer. Wenn du Scaffolding hinzugefügt hast, um Zwischenstatusmeldungen zu erzwingen („Fasse nach jeweils 3 Tool-Aufrufen den Fortschritt zusammen“), versuche, es zu entfernen. Wenn du feststellst, dass Länge oder Inhalt der nutzerseitigen Updates von Claude Sonnet 5 nicht gut auf deinen Anwendungsfall abgestimmt sind, beschreibe im Prompt explizit, wie diese Updates aussehen sollen, und gib Beispiele an.

Wörtlichere Befolgung von Anweisungen

Claude Sonnet 5 interpretiert Prompts wörtlich und explizit, insbesondere bei niedrigeren Effort-Stufen. Es verallgemeinert eine Anweisung nicht stillschweigend von einem Element auf ein anderes und leitet keine Anfragen ab, die du nicht gestellt hast. Der Vorteil dieser Wörtlichkeit ist Präzision, und sie funktioniert im Allgemeinen besser für API-Anwendungsfälle mit sorgfältig abgestimmten Prompts, strukturierter Extraktion und Pipelines, in denen du vorhersagbares Verhalten möchtest. Wenn Claude eine Anweisung breit anwenden soll, gib den Geltungsbereich explizit an (zum Beispiel: „Wende diese Formatierung auf jeden Abschnitt an, nicht nur auf den ersten“).

Ton und Schreibstil

Wie bei jedem neuen Modell kann sich der Prosastil bei längeren Texten verschieben. Wenn dein Produkt auf eine bestimmte Stimme angewiesen ist, evaluiere Stil-Prompts erneut gegen die neue Baseline.

Wenn die Stimme deines Produkts beispielsweise wärmer oder gesprächiger ist, füge Folgendes hinzu:

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

Wenn du dich bisher für stilistische Vielfalt auf temperature verlassen hast, beachte, dass das Setzen von temperature, top_p oder top_k auf einen Nicht-Standardwert auf Claude Sonnet 5 einen 400-Fehler zurückgibt. Diese Einschränkung ist neu für Modelle der Sonnet-Klasse. Entferne diese Parameter bei der Migration und verwende stattdessen Anweisungen im System-Prompt, um Ton und Vielfalt zu steuern.

Design- und Frontend-Standards

Claude Sonnet 5 kann sich bei offenen Frontend- und Design-Briefings auf einen konsistenten visuellen Standardstil festlegen. Ein Standard-Hausstil kann für manche Briefings gut wirken, sich aber bei Dashboards, Entwickler-Tools, Fintech, Gesundheitswesen oder Enterprise-Apps unpassend anfühlen.

Generische Anweisungen („verwende diese Farbe nicht“, „mach es clean und minimal“) verschieben das Modell eher zu einer anderen festen Palette, anstatt Vielfalt zu erzeugen. Zwei Ansätze funktionieren zuverlässig:

1. Gib eine konkrete Alternative an. Das Modell befolgt explizite Spezifikationen präzise:

Design a desktop landing page for a supplement brand called AEFRM.

The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black, similar to a misted metallic surface.

The page should feel sharp and controlled, with a strong sense of structure and restraint.

Use this tonal system across the full page instead of introducing bright accent colors.

Use the uploaded image on the hero design in black and white.

The layout should be built with clear horizontal sections and a centered max-width container. Use 4px corner radius consistently across cards, buttons, inputs, and media frames. Margins should feel generous, with enough empty space around each section so the page breathes.

Typography should use a square, angular sans-serif with wider letter spacing than usual, especially in headings and navigation, so the text feels more engineered and less compressed. Headline text can be large and uppercase, while supporting copy remains short and sparse. The sub texts should be written with Alumni Sans SC in 4-6px like tiny little texts on corners bottom centre like that.

For the structure, start with a hero section containing a strong product statement, one short supporting paragraph, and a clean product placeholder or packshot frame. Below that, add a benefit grid with three or four blocks, then a formulation or ingredients section, and finally a cta.

Buttons should be flat and precise, with subtle hover changes using transition: all 160ms ease out where brightness and border contrast shift slightly rather than using dramatic motion.

Color palette should stay within this range:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.

2. Lass das Modell vor dem Bauen Optionen vorschlagen. Das durchbricht den Standard und gibt Nutzern Kontrolle. Da temperature auf Claude Sonnet 5 nicht akzeptiert wird, ist dieser Ansatz der empfohlene Weg, um über mehrere Durchläufe hinweg deutlich unterschiedliche Designrichtungen zu erzeugen. Beispiel-Prompt:

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface, plus a one-line rationale). Ask the user to pick one, then implement only that direction.

Um von generischen Mustern wegzusteuern, die Nutzer als „AI slop“-Ästhetik bezeichnen, kannst du eine kurze Direktive in deinen System-Prompt aufnehmen. Der frontend-design-Skill bietet eine ausführlichere Behandlung, aber dieses Snippet funktioniert gut zusammen mit den vorangehenden Ansätzen für Vielfalt:

<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>

Interaktive Coding-Produkte

Token-Verbrauch und Verhalten können sich zwischen autonomen, asynchronen Coding-Agenten mit einem einzigen Nutzer-Turn und interaktiven, synchronen Coding-Agenten mit mehreren Nutzer-Turns unterscheiden. Um sowohl Leistung als auch Token-Effizienz in Coding-Produkten zu maximieren, verwende xhigh oder high Effort, füge autonome Funktionen wie einen Auto-Modus hinzu und reduziere die Anzahl der von deinen Nutzern erforderlichen menschlichen Interaktionen.

Wenn du die Anzahl der erforderlichen Nutzerinteraktionen begrenzt, ist es wichtig, Aufgabe, Absicht und relevante Einschränkungen vorab im ersten menschlichen Turn anzugeben. Gut spezifizierte, klare und genaue Aufgabenbeschreibungen vorab bereitzustellen, kann helfen, Autonomie und Intelligenz zu maximieren und gleichzeitig zusätzlichen Token-Verbrauch nach Nutzer-Turns zu minimieren. Im Gegensatz dazu verringern mehrdeutige oder unterspezifizierte Prompts, die schrittweise über mehrere Nutzer-Turns vermittelt werden, tendenziell die Token-Effizienz und manchmal auch die Leistung.

Code-Review-Harnesses

Wenn dein Code-Review-Harness für ein früheres Modell abgestimmt wurde, siehst du auf Claude Sonnet 5 möglicherweise zunächst einen niedrigeren Recall. Das ist wahrscheinlich ein Harness-Effekt, keine Regression der Fähigkeiten. Wenn ein Review-Prompt Dinge wie „melde nur Probleme mit hohem Schweregrad“, „sei konservativ“ oder „keine Kleinigkeiten bemängeln“ enthält, befolgt Claude Sonnet 5 diese Anweisung möglicherweise treuer als frühere Modelle: Es untersucht den Code womöglich genauso gründlich, identifiziert die Bugs und meldet dann keine Befunde, die es als unterhalb deiner angegebenen Schwelle einschätzt. Das kann sich darin zeigen, dass das Modell dieselbe Untersuchungstiefe leistet, aber weniger Untersuchungen in gemeldete Befunde umwandelt, insbesondere bei Bugs mit geringerem Schweregrad. Die Precision steigt typischerweise, aber der gemessene Recall kann sinken, obwohl sich die zugrunde liegende Fähigkeit des Modells, Bugs zu finden, verbessert hat.

Einige empfohlene Prompt-Formulierungen:

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

Dieser Prompt kann verwendet werden, ohne dass es tatsächlich einen zweiten Schritt gibt, aber das Auslagern der Konfidenzfilterung aus dem Befundschritt hilft oft. Wenn dein Harness eine separate Verifikations-, Deduplizierungs- oder Ranking-Stufe hat, sage dem Modell explizit, dass seine Aufgabe in der Befundstufe Abdeckung und nicht Filterung ist.

Wenn du möchtest, dass das Modell in einem einzigen Durchgang selbst filtert, sei konkret, wo die Schwelle liegt, anstatt qualitative Begriffe wie „wichtig“ zu verwenden: zum Beispiel „melde alle Bugs, die zu fehlerhaftem Verhalten, einem fehlschlagenden Test oder einem irreführenden Ergebnis führen könnten; lass nur Kleinigkeiten wie reine Stil- oder Benennungspräferenzen weg."

Iteriere Prompts gegen eine Teilmenge deiner Evals oder Testfälle, um Verbesserungen bei Recall oder F1-Score zu validieren.

Computer Use

Claude Sonnet 5 unterstützt das Toolset computer_toolset_20260801 (in der Claude API und Google Cloud) sowie die frühere Tool-Version computer_20251124. In der Claude API und Google Cloud unterstützt Claude Sonnet 5 außerdem das „browser use tool" (Browser-Nutzungs-Tool) (browser_toolset_20260801) für Aufgaben innerhalb von Webseiten. Die Fähigkeit zur „computer use" (Computernutzung) funktioniert über verschiedene Auflösungen hinweg, bis zu einer maximalen Auflösung von 2576 px / 3,75 MP. Interne Tests zur Computernutzung zeigen, dass das Senden von Bildern in 1080p ein gutes Gleichgewicht zwischen Leistung und Kosten bietet.

Für besonders kostensensible Workloads sind 720p oder 1366×768 kostengünstigere Optionen mit starker Leistung. Führe eigene Tests durch, um die idealen Einstellungen für deinen Anwendungsfall zu finden; das Experimentieren mit Effort-Einstellungen kann ebenfalls helfen, das Verhalten des Modells abzustimmen.