Prompting für Claude Opus 4.8

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

Claude Opus 4.8 hat besondere Stärken bei langfristiger agentischer Arbeit, Wissensarbeit, Vision- und Memory-Aufgaben. Es funktioniert von Haus aus gut mit bestehenden Claude Opus 4.7-Prompts. Die folgenden Muster decken die Verhaltensweisen ab, die am häufigsten eine Anpassung erfordern.



Antwortlänge und Ausführlichkeit

Claude Opus 4.8 kalibriert die Antwortlänge danach, wie komplex es die Aufgabe einschätzt, anstatt standardmäßig eine feste Ausführlichkeit zu verwenden. Das bedeutet in der Regel kürzere Antworten bei einfachen Nachschlageanfragen und deutlich längere bei offenen Analysen.

Wenn dein Produkt von einem bestimmten Stil oder einer bestimmten Ausführlichkeit der Ausgabe abhängt, musst du möglicherweise deine Prompts 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 (wie übermäßiges Erklären), kannst du zusätzliche Anweisungen in deinem Prompt hinzufügen, um diese zu verhindern. Positive Beispiele, die zeigen, wie Claude mit dem angemessenen Maß an Prägnanz kommunizieren kann, sind tendenziell effektiver als negative Beispiele oder Anweisungen, die dem Modell sagen, was es nicht tun soll.



Kalibrierung von Effort und Denktiefe

Der Effort-Parameter ermöglicht es dir, Claudes Intelligenz gegen den Token-Verbrauch abzuwägen und dabei Leistungsfähigkeit gegen höhere Geschwindigkeit und niedrigere Kosten einzutauschen. Beginne mit der Effort-Stufe xhigh für Coding- und agentische Anwendungsfälle und verwende mindestens high für die meisten intelligenzsensitiven Anwendungsfälle. Experimentiere mit anderen Effort-Stufen, um Token-Verbrauch und Intelligenz weiter abzustimmen:

• max: Maximaler Effort kann in einigen Anwendungsfällen Leistungssteigerungen bringen, zeigt aber möglicherweise abnehmende Erträge bei erhöhtem Token-Verbrauch. Diese Einstellung kann manchmal auch zu Überdenken neigen. Teste maximalen Effort für intelligenzintensive Aufgaben.
• xhigh: Extra hoher Effort ist die beste Einstellung für die meisten Coding- und agentischen Anwendungsfälle.
• high: Diese Einstellung balanciert Token-Verbrauch und Intelligenz. Verwende für die meisten intelligenzsensitiven Anwendungsfälle mindestens high.
• medium: Gut für kostensensitive Anwendungsfälle, die den Token-Verbrauch reduzieren müssen und dabei Intelligenz eintauschen.
• low: Reserviere dies für kurze, eng umrissene Aufgaben und latenzsensitive Workloads, die nicht intelligenzsensitiv sind.

Claude Opus 4.8 hält sich strikt an die Effort-Stufen, besonders 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 des Unterdenkens.

Wenn du bei komplexen Problemen oberflächliches Reasoning beobachtest, erhöhe den Effort auf high oder xhigh, anstatt das Problem über Prompting zu umgehen. Wenn du den Effort aus Latenzgründen auf low halten musst, füge gezielte Anweisungen hinzu:

This task involves multi-step reasoning. Think carefully through the problem before responding.

Effort ist für dieses Modell wahrscheinlich wichtiger als für jedes frühere Opus, also experimentiere aktiv damit, wenn du ein Upgrade durchführst.

Bei Claude Opus 4.8 ist das Denken deaktiviert, es sei denn, du setzt explizit thinking: {type: "adaptive"}. Das Auslöseverhalten für adaptives Denken ist steuerbar. Wenn du feststellst, dass das Modell häufiger denkt als gewünscht – was bei großen oder komplexen System-Prompts vorkommen kann – füge Anweisungen hinzu, um es zu steuern. Miss wie immer die Auswirkung von Prompting-Änderungen auf die Leistung. Beispiel:

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

Umgekehrt: Wenn du anspruchsvolle Workloads mit medium ausführst und Unterdenken beobachtest, ist der erste Hebel, den Effort zu erhöhen. Wenn du feinere Kontrolle benötigst, fordere sie direkt im Prompt an.



Auslösung der Tool-Nutzung

Claude Opus 4.8 neigt dazu, Reasoning gegenüber Tool-Aufrufen zu bevorzugen. Das führt in den meisten Fällen zu besseren Ergebnissen. Das Erhöhen der Effort-Einstellung ist jedoch ein nützlicher Hebel, um das Ausmaß der Tool-Nutzung zu steigern, besonders bei Wissensarbeit. Die Effort-Einstellungen high oder xhigh zeigen deutlich mehr Tool-Nutzung bei agentischer Suche und Coding. Für Szenarien, in denen du mehr Tool-Nutzung möchtest, kannst du auch deinen Prompt anpassen, um das Modell explizit anzuweisen, wann und wie es seine Tools richtig verwenden soll. Wenn du beispielsweise feststellst, dass das Modell deine Websuche-Tools nicht verwendet, beschreibe klar, warum und wie es das tun sollte.



Benutzerseitige Fortschrittsupdates

Claude Opus 4.8 liefert während langer agentischer Abläufe regelmäßigere und qualitativ hochwertigere Updates an den Benutzer. 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 die Länge oder der Inhalt der benutzerseitigen Updates von Claude Opus 4.8 nicht gut auf deinen Anwendungsfall abgestimmt sind, beschreibe explizit im Prompt, wie diese Updates aussehen sollten, und liefere Beispiele.



Wörtlichere Befolgung von Anweisungen

Claude Opus 4.8 interpretiert Prompts wörtlich und explizit, besonders 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 weniger Hin und Her, und es funktioniert im Allgemeinen besser für API-Anwendungsfälle mit sorgfältig abgestimmten Prompts, strukturierter Extraktion und Pipelines, bei denen du vorhersehbares Verhalten möchtest. Wenn Claude eine Anweisung breit anwenden soll, gib den Umfang 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. Claude Opus 4.8 tendiert zu einem direkten, meinungsstarken Stil mit minimalen bestätigungsorientierten Formulierungen und sparsamer Emoji-Verwendung. Wenn dein Produkt auf eine bestimmte Stimme angewiesen ist, überprüfe deine Stil-Prompts anhand der neuen Baseline.

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

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



Steuerung des Subagenten-Spawnings

Claude Opus 4.8 neigt dazu, standardmäßig weniger Subagenten zu erzeugen. Dieses Verhalten ist jedoch über Prompting steuerbar; gib Claude Opus 4.8 explizite Anweisungen dazu, wann Subagenten wünschenswert sind. Ein einfaches Beispiel für einen Coding-Anwendungsfall:

Do not spawn a subagent for work you can complete directly in a single response (e.g.
refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.



Design- und Frontend-Standardeinstellungen

Claude Opus 4.8 hat ausgeprägte Design-Instinkte mit einem konsistenten Standard-Hausstil: warme creme-/off-white-farbene Hintergründe (~#F4F1EA), Serifen-Display-Schriften (Georgia, Fraunces, Playfair), kursive Wortakzente und ein Terrakotta-/Bernstein-Akzent. Das wirkt gut für redaktionelle, Hospitality- und Portfolio-Briefings, fühlt sich aber unpassend an für Dashboards, Dev-Tools, Fintech, Healthcare oder Enterprise-Apps. Dieser Standard erscheint sowohl in Slide-Decks als auch in Web-UIs.

Dieser Standard ist hartnäckig. Generische Anweisungen („verwende kein Creme", „mach es clean und minimal") führen tendenziell dazu, dass das Modell zu einer anderen festen Palette wechselt, anstatt Vielfalt zu erzeugen. Zwei Ansätze funktionieren zuverlässig:

1. Gib eine konkrete Alternative vor. Das Modell folgt expliziten 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 Optionen vorschlagen, bevor es baut. Das durchbricht den Standard und gibt Benutzern Kontrolle. Wenn du dich zuvor auf temperature für Design-Vielfalt verlassen hast, verwende diesen Ansatz; er erzeugt über mehrere Durchläufe hinweg deutlich unterschiedliche Richtungen. Beispiel-Prompt:

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

Zusätzlich benötigt Claude Opus 4.8 weniger Frontend-Design-Prompting als frühere Modelle, um generische Muster zu vermeiden, die Benutzer als „AI slop"-Ästhetik bezeichnen. Bei früheren Modellen empfahl Anthropic ein längeres Prompt-Snippet im frontend-design skill. Claude Opus 4.8 generiert jedoch mit minimalerer Prompting-Anleitung unverwechselbare, kreative Frontends. Dieses Prompt-Snippet funktioniert gut zusammen mit den obigen Prompting-Ratschlägen 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

Der Token-Verbrauch und das Verhalten von Claude Opus 4.8 können sich zwischen autonomen, asynchronen Coding-Agenten mit einem einzigen User-Turn und interaktiven, synchronen Coding-Agenten mit mehreren User-Turns unterscheiden. Konkret neigt es dazu, in interaktiven Umgebungen mehr Token zu verwenden, hauptsächlich weil es nach User-Turns mehr reasoned. Das kann die langfristige Kohärenz, die Befolgung von Anweisungen und die Coding-Fähigkeiten in langen, interaktiven Coding-Sessions verbessern, geht aber auch mit höherem Token-Verbrauch einher. Um sowohl Leistung als auch Token-Effizienz in Coding-Produkten zu maximieren, verwende xhigh oder high Effort, füge autonome Features wie einen Auto-Modus hinzu und reduziere die Anzahl der von deinen Benutzern erforderlichen menschlichen Interaktionen.

Natürlich ist es beim Begrenzen der Anzahl erforderlicher Benutzerinteraktionen wichtig, die Aufgabe, die Absicht und die relevanten Einschränkungen im ersten Human-Turn vorab zu spezifizieren. Gut spezifizierte, klare und präzise Aufgabenbeschreibungen im Voraus können helfen, Autonomie und Intelligenz zu maximieren und gleichzeitig zusätzlichen Token-Verbrauch nach User-Turns zu minimieren. Da Claude Opus 4.8 autonomer ist als frühere Modelle, hilft dieses Nutzungsmuster, die Leistung zu maximieren. Im Gegensatz dazu neigen mehrdeutige oder unterspezifizierte Prompts, die schrittweise über mehrere User-Turns vermittelt werden, dazu, die Token-Effizienz und manchmal auch die Leistung relativ zu verringern.



Code-Review-Harnesses

Claude Opus 4.8 ist deutlich besser darin, Bugs zu finden als frühere Modelle, und hat in internen Evaluierungen sowohl höheren Recall als auch höhere Precision. Wenn dein Code-Review-Harness jedoch für ein früheres Modell abgestimmt wurde, siehst du möglicherweise zunächst einen niedrigeren Recall. Das ist wahrscheinlich ein Harness-Effekt, keine Fähigkeitsregression. Wenn ein Review-Prompt Dinge sagt wie „melde nur Probleme mit hohem Schweregrad", „sei konservativ" oder „keine Kleinigkeiten", befolgt Claude Opus 4.8 diese Anweisung möglicherweise treuer als frühere Modelle: Es untersucht den Code möglicherweise genauso gründlich, identifiziert die Bugs und meldet dann keine Befunde, die es als unterhalb deiner angegebenen Schwelle einschätzt. Das kann sich so zeigen, dass das Modell die gleiche Untersuchungstiefe durchführt, aber weniger Untersuchungen in gemeldete Befunde umwandelt, besonders bei Bugs mit niedrigerem Schweregrad. Die Precision steigt typischerweise, aber der gemessene Recall kann sinken, obwohl sich die zugrunde liegende Bug-Finding-Fähigkeit des Modells 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 Verlagern der Konfidenzfilterung aus dem Finding-Schritt heraus hilft oft. Wenn dein Harness eine separate Verifizierungs-, Deduplizierungs- oder Ranking-Stufe hat, sage dem Modell explizit, dass seine Aufgabe in der Finding-Stufe Abdeckung und nicht Filterung ist.

Wenn du möchtest, dass das Modell in einem einzigen Durchgang selbst filtert, sei konkret dabei, wo die Schwelle liegt, anstatt qualitative Begriffe wie „wichtig" zu verwenden: zum Beispiel „melde alle Bugs, die falsches Verhalten, einen Testfehler oder ein irreführendes Ergebnis verursachen könnten; lass nur Kleinigkeiten wie reine Stil- oder Namenspräferenzen weg."

Iteriere über Prompts anhand einer Teilmenge deiner Evals oder Testfälle, um Verbesserungen bei Recall oder F1-Score zu validieren.



Computer use

Die Computer use-Fähigkeit funktioniert über verschiedene Auflösungen hinweg, bis zu einer maximalen Auflösung von 2576px / 3,75MP. Interne Computer-use-Tests zeigen, dass das Senden von Bildern in 1080p eine gute Balance zwischen Leistung und Kosten bietet.

Für besonders kostensensitive 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.