Prompting für Claude Opus 4.8

Dieser Leitfaden behandelt die Prompting-Muster, die spezifisch für Claude Opus 4.8 sind. Für die API-Änderungen beim Wechsel von Claude Opus 4.8 zum neuesten Opus-Modell siehe Migration zu Claude Opus 5 von Claude Opus 4.8. Für Techniken, die für alle aktuellen Claude-Modelle gelten, siehe Best Practices für Prompting.

Claude Opus 4.8 hat besondere Stärken bei langfristiger agentischer Arbeit, Wissensarbeit, Vision- und Memory-Aufgaben. Es funktioniert out of the box gut mit bestehenden Claude Opus 4.7-Prompts. Die folgenden Muster behandeln die Verhaltensweisen, 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 konkrete Beispiele für bestimmte Arten von Ausführlichkeit siehst (wie ü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 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 Token-Verbrauch abzustimmen und Fähigkeiten gegen höhere Geschwindigkeit und niedrigere Kosten einzutauschen. Beginne mit dem Effort-Level xhigh für Coding- und agentische Anwendungsfälle und verwende mindestens high Effort für die meisten intelligenzsensitiven Anwendungsfälle. Experimentiere mit anderen Effort-Levels, um Token-Verbrauch und Intelligenz weiter abzustimmen:

• max: Max Effort kann in einigen Anwendungsfällen Leistungssteigerungen liefern, kann aber abnehmende Erträge bei erhöhtem Token-Verbrauch zeigen. Diese Einstellung kann manchmal auch zu Overthinking neigen. Teste Max Effort für intelligenzintensive Aufgaben.
• xhigh: Extra High Effort ist die beste Einstellung für die meisten Coding- und agentischen Anwendungsfälle.
• high: Diese Einstellung balanciert Token-Verbrauch und Intelligenz. Für die meisten intelligenzsensitiven Anwendungsfälle verwende mindestens high Effort.
• medium: Gut für kostensensitive Anwendungsfälle, die den Token-Verbrauch reduzieren müssen und dafür 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 Effort-Levels, 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 von zu wenig Nachdenken.

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

This task involves multistep 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 upgradest.

Bei Claude Opus 4.8 ist Thinking deaktiviert, es sei denn, du setzt explizit thinking: {type: "adaptive"}. Das Auslöseverhalten für adaptives Thinking ist steuerbar. Wenn du feststellst, dass das Modell häufiger denkt, als du möchtest, was bei großen oder komplexen System-Prompts passieren kann, füge Anleitung hinzu, um es zu steuern. Miss wie immer die Auswirkung jeder Prompting-Änderung auf die Leistung. 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, wenn du anspruchsvolle Workloads mit medium ausführst und zu wenig Nachdenken beobachtest, ist der erste Hebel, den Effort zu erhöhen. Wenn du feinere Kontrolle brauchst, prompte direkt dafür.



Auslösen von Tool-Nutzung

Claude Opus 4.8 hat eine Tendenz, Reasoning gegenüber Tool-Aufrufen zu bevorzugen. Das führt in den meisten Fällen zu besseren Ergebnissen. Allerdings ist die Erhöhung der Effort-Einstellung ein nützlicher Hebel, um das Maß an Tool-Nutzung zu erhöhen, besonders bei Wissensarbeit. 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 auch deinen Prompt anpassen, um das Modell explizit anzuweisen, wann und wie es seine Tools richtig verwenden soll. Wenn du zum Beispiel feststellst, dass das Modell deine Websuche-Tools nicht verwendet, beschreibe klar, warum und wie es das tun sollte.



Nutzerorientierte Fortschrittsupdates

Claude Opus 4.8 liefert regelmäßigere, qualitativ hochwertigere Updates an den Nutzer während langer agentischer Abläufe. 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 nutzerorientierten Updates von Claude Opus 4.8 nicht gut auf deinen Anwendungsfall kalibriert ist, beschreibe explizit im Prompt, wie diese Updates aussehen sollen, und gib Beispiele.



Wörtlichere Befolgung von Anweisungen

Claude Opus 4.8 interpretiert Prompts wörtlich und explizit, besonders bei niedrigeren Effort-Levels. 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 schneidet generell besser ab bei API-Anwendungsfällen mit sorgfältig abgestimmten Prompts, strukturierter Extraktion und Pipelines, bei denen du vorhersagbares 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ätigenden Formulierungen und sparsamer Emoji-Nutzung. Wenn dein Produkt auf eine bestimmte Stimme angewiesen ist, evaluiere Stil-Prompts gegen die neue Baseline neu.

Wenn deine Produktstimme zum Beispiel wärmer oder gesprächiger ist, füge hinzu:

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



Steuerung des Spawnens von Subagenten

Claude Opus 4.8 tendiert dazu, standardmäßig weniger Subagenten zu spawnen. Dieses Verhalten ist jedoch durch Prompting steuerbar; gib Claude Opus 4.8 explizite Anleitung dazu, wann Subagenten erwünscht 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 starke Design-Instinkte mit einem konsistenten Standard-Hausstil: warme Creme-/Off-White-Hintergründe (~#F4F1EA), Serifen-Display-Schriften (Georgia, Fraunces, Playfair), kursive Wortakzente und ein Terrakotta-/Bernstein-Akzent. Das liest sich gut für redaktionelle, Hospitality- und Portfolio-Briefings, wirkt aber unpassend für Dashboards, Dev-Tools, Fintech, Healthcare oder Enterprise-Apps. Der Standard erscheint in Foliensätzen und Web-UIs.

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

1. Gib eine konkrete Alternative an. 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 Nutzern 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.

Darüber hinaus benötigt Claude Opus 4.8 weniger Frontend-Design-Prompting als frühere Modelle, um generische Muster zu vermeiden, die Nutzer als „AI slop"-Ästhetik bezeichnen. Bei früheren Modellen empfahl Anthropic einen längeren Prompt-Ausschnitt im frontend-design Skill. Claude Opus 4.8 generiert jedoch markante, kreative Frontends mit minimalerer Prompting-Anleitung. Dieser Prompt-Ausschnitt funktioniert gut zusammen mit den vorangegangenen 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 tendiert es dazu, in interaktiven Umgebungen mehr Tokens zu verwenden, hauptsächlich weil es nach User-Turns mehr nachdenkt. Das kann langfristige Kohärenz, Befolgung von Anweisungen und 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 menschlichen Interaktionen, die von deinen Nutzern erforderlich sind.

Wenn du die Anzahl der erforderlichen Nutzerinteraktionen begrenzt, ist es natürlich wichtig, die Aufgabe, die Absicht und die relevanten Einschränkungen von Anfang an im ersten Human-Turn zu spezifizieren. Gut spezifizierte, klare und genaue Aufgabenbeschreibungen von Anfang an 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 reduzieren mehrdeutige oder unterspezifizierte Prompts, die schrittweise über mehrere User-Turns vermittelt werden, tendenziell die Token-Effizienz und manchmal die Leistung.



Code-Review-Harnesses

Claude Opus 4.8 ist deutlich besser darin, Bugs zu finden als frühere Modelle, und hat sowohl höheren Recall als auch höhere Precision in internen Evals. Wenn dein Code-Review-Harness jedoch für ein früheres Modell abgestimmt wurde, siehst du anfangs möglicherweise 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 bemängeln", 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 dieselbe Untersuchungstiefe hat, aber weniger Untersuchungen in gemeldete Befunde umwandelt, besonders bei Bugs mit niedrigerem Schweregrad. Die Precision steigt typischerweise, aber der gemessene Recall kann fallen, 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 Herauslösen der Konfidenzfilterung aus dem Finding-Schritt 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 ist und nicht Filterung.

Wenn du möchtest, dass das Modell in einem einzigen Durchgang selbst filtert, sei konkret darüber, wo die Schwelle liegt, anstatt qualitative Begriffe wie „wichtig" zu verwenden: zum Beispiel „melde alle Bugs, die zu fehlerhaftem Verhalten, einem Testfehler oder einem irreführenden Ergebnis führen könnten; lasse nur Kleinigkeiten wie reine Stil- oder Benennungsprä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 aus 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.