Clearly define the task boundaries, use effort to control cost and depth, and split “discovery” from “filtering” into two steps for more reliable use of Opus 4.8 in agents, coding, and code review.
Suitable tasks: Long-horizon agents, coding, code review, knowledge work, vision, and tasks that require retaining context.
Unsuitable tasks: Short Q&A where latency is highly sensitive and reasoning is unnecessary; a high effort level need not be the default.
Applicable model version: Claude Opus 4.8 (model ID claude-opus-4-8).
Applicable clients, agents, or APIs: Claude API, Claude Code, Cowork, and tool-enabled agents; the exact entry point for effort levels may differ across clients and API/agent configurations.
Recommended reasoning levels and parameters: Start at xhigh for coding/agent tasks; use at least high for most tasks that are intelligence-sensitive; use low/medium for short tasks where cost or latency matters. When thinking is needed, explicitly enable thinking: {type: "adaptive"}, and reserve enough max_tokens for both thinking and visible output.
The following are copyable prompt snippets published on the Anthropic page. They are independent examples for different uses, not components that must be combined into one extremely long system prompt.
Provide concise, focused responses. Skip non-essential context, and keep examples minimal.This task involves multistep reasoning. Think carefully through the problem before responding.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.Use the available tools when they materially improve the answer. For each tool, first identify what question it will answer or what state it will change; do not call a tool merely to appear thorough.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.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.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.In the first-turn message, state the task, intent, constraints, completion criteria, and available tools; do not scatter key constraints across multiple turns.
Use low or medium for simple, low-risk tasks; test coding and agent tasks at xhigh first, and use at least high for quality-sensitive tasks.
If an API task requires multistep reasoning, explicitly include thinking: {type: "adaptive"}; if reasoning is shallow at a low effort level, raise effort rather than relying only on prompt wording to compensate.
For tool-based tasks, specify when to call a tool, what question the tool should answer, and what result to check; long tasks may allow the model to provide progress updates instead of mechanically requiring an update after every N tool calls.
Split code review into two steps, “discovery (optimize for coverage) → verification/deduplication/ranking (filtering),” then evaluate recall/F1 on a subset to avoid mixing “report only high-severity issues” into the discovery phase.
For frontend tasks, provide specific colors, fonts, or ask the model to propose 4 directions; a vague “no beige, keep it simple” is less stable than concrete alternatives.
The official guide positions max, xhigh, high, medium, and low respectively as the highest capability, the preferred choice for coding/agents, a balance of capability and cost, cost-sensitive tasks, and short/low-latency tasks.
The guide says that thinking is disabled by default for Opus 4.8 and requires explicitly setting thinking: {type: "adaptive"}; it also notes that increasing effort affects the intensity of tool use.
The guide explicitly records that Opus 4.8 leans more toward reasoning than tool calls, generates fewer subagents by default, and follows scope more literally; these behaviors can be adjusted through tool rules, subagent boundaries, and clear scope statements that apply to each section.
The code review section provides a complete example of “report every finding, then verify later,” and recommends validating recall/F1 on an evaluation subset; this is a reproducible harness-design recommendation, not a score from a public leaderboard.
The page provides official behavioral guidance, not an independently reproduced experiment; the specific benefits depend on tool definitions, context, max_tokens, the client, and the evaluation harness.
Code-block examples should be selected for their intended use; combining all examples unconditionally may lead to excessive thinking, too many tool calls, or overly long output.
effort, thinking, and the model version affect token consumption and latency; before launch, measure quality, cost, latency, and the number of tool calls on your own task set.
The frontend section describes observed default aesthetic tendencies, not hard constraints; brand design should still provide a specific design system.
The official guide’s core recommendation is to “start at xhigh for coding and agents,” while emphasizing that lower effort levels constrain the work more strictly to what the user explicitly requested. The original also notes that when a complex problem produces shallow reasoning, the first adjustment should be to increase effort.
Claude Opus 4.8