Claude Opus 4.7 Prompting Guide: How to Get the Most From Anthropic's Top Model (2026)

Claude Opus 4.7 is Anthropic's top-tier model as of early 2026 — the one you reach for when the task is genuinely hard, the stakes are high, or a cheaper model has already failed the eval. It supports a 1M-token context window, extended thinking with a tunable reasoning budget, prompt caching, and strong tool use including computer use. None of that helps if you prompt it like a chatbot. This guide covers the specific patterns that move quality and cost on Opus 4.7 — when to turn thinking on, how to assemble 1M-context prompts, how to cache correctly, and how to wire up agentic workflows.

Key takeaways:

• Use extended thinking selectively — on reasoning-heavy work, off for drafting and classification.
• 1M context is a ceiling, not a default. Retrieval beats packing when the answer lives in a small span.
• Cache everything stable above a breakpoint. At Opus pricing, cache hits matter more than ever.
• Use RCAF as the floor, score against the SurePrompts Quality Rubric as the ceiling.
• For agentic runs, think in layers — the Agentic Prompt Stack is the model.
• Match model tier to task difficulty — Sonnet for daily work, Opus for the hard cases.

Why Claude Opus 4.7 needs its own playbook

Opus 4.7 is not a faster Sonnet or a bigger Haiku. It is a model whose economics, reasoning depth, and context capacity change which prompting patterns make sense.

Three things matter for prompting:

• The context window is large enough to pack entire projects. That tempts people to dump everything in. Dumping everything in hurts quality and cost — Opus still prioritizes signal near the task, and the input bill scales linearly with tokens.
• Extended thinking is a knob, not a default. The reasoning model behavior is opt-in. Leaving it off on reasoning-heavy tasks leaves quality on the table; leaving it on everywhere burns money.
• The per-token cost is high. That makes caching, retrieval, and model routing load-bearing. A prompt that works fine on Haiku at 10x the volume can be the wrong tool on Opus.

The playbook below assumes you already know how to prompt a chat model. If you do not, start with the Claude 4 prompting guide — this one builds on it.

Enable extended thinking — when and how

Extended thinking lets Opus spend tokens reasoning in a scratch-pad before answering. You set a budget, the model uses up to that budget thinking, and the reasoning is visible to you but not billed as output. The question is not "should I always turn it on" — it is "does this specific task reward step-by-step reasoning?"

Turn it on for:

• Multi-file debugging and root-cause analysis
• Architectural tradeoffs where the first plausible answer is usually wrong
• Math, proofs, and formal reasoning
• Legal, policy, or contract analysis with interacting clauses
• Complex planning — project plans, migration strategies, test matrices
• Any eval where chain-of-thought improved scores

Turn it off for:

• Drafting, summarization, paraphrasing
• Simple classification and extraction
• Creative writing — it does not improve prose and often produces over-explained metafiction
• Format conversions
• Tasks where you have already seen Sonnet handle it fine

The budget is the other knob. A small budget is enough for single-step reasoning ("why is this query slow"). Larger budgets let Opus explore branches, self-correct, and consider alternatives — useful on problems where the model might otherwise commit to a bad first path. If you do not know what budget to pick, start low and raise it only when you see the reasoning truncate on a real task.

The canonical anti-pattern is turning on a big thinking budget for a drafting task. Opus will reason about whether the draft is good, revise it in its head, and then produce something slightly worse than what it would have written cold. Thinking is not free — the token bill is real and the quality can regress.

For deeper patterns, see Extended Thinking Prompts for Claude. The thinking model glossary entry covers the category.

Structure prompts for 1M context

A 1M-token context window is not a license to ignore structure — it is a reason to care about it more. The assembly pattern that works:

<system>
  [Role, persistent rules, output format, constraints]
</system>

<reference>
  <doc id="spec" title="Feature spec v3">...</doc>
  <doc id="codebase" title="Relevant files">...</doc>
  <doc id="history" title="Prior decisions">...</doc>
</reference>

<task>
  [The specific thing to do today, with success criteria]
</task>

Three principles make this work at long context:

Stable at the top, task at the end. Opus gives weight to early system instructions and to the span immediately preceding the output. Putting the task last means the model reads it with full context already loaded.

Tag reference material so it reads as data, not instructions. Wrapped docs do not get confused with meta-instructions — a real risk when the reference contains directive language.

Name the docs. When the model needs to cite or reference a section, clear IDs ("see spec section 3") make outputs traceable and auditable.

Avoid middle-of-context dilution. Opus 4.7 handles long contexts well, but subtle details buried in the middle of a 500K-token prompt are still easier to miss than the same details pinned near the task. If a fact is load-bearing, repeat it in the task block or in a short "key facts" section right before the task.

Retrieve before you pack. If the answer lives in a 5K-token span, finding that span and passing only it produces higher-quality answers at a fraction of the cost. Treat 1M as insurance for cases where retrieval is genuinely hard — legacy-code audits, multi-document synthesis, agent sessions with growing context. For the broader maturity framing, see the Context Engineering Maturity Model.

Prompt caching on Opus 4.7

Prompt caching stores a prefix of your prompt server-side and bills it at a reduced rate on subsequent requests. The mechanics are straightforward — you mark a cache breakpoint, and everything above the breakpoint is cached. Everything below is fresh input on every call.

At Opus pricing, caching moves from "nice optimization" to "the difference between this workflow being affordable and not." Three rules:

1. Structure prompts cache-up. Put stable content above the breakpoint: system prompt, role, long reference documents, few-shot examples, tool descriptions. Put variable content below: the current question, the current document, the current user turn. The prompt template becomes an assembly order problem.

2. Do not mutate above the breakpoint. Any byte change above the line — a reordered example, a reworded rule, a fresh timestamp — invalidates the cache. Pin the stable section, review diffs carefully, and keep the "variable" stuff strictly below.

3. Cache big things, not small things. Caching a 500-token system prompt across 10 calls saves very little. Caching a 50K-token reference block across 1000 calls is the kind of move that changes your bill. The break-even depends on the cache read rate and miss penalty — check Anthropic's current numbers and do the math for your workload.

The detailed patterns — cache-aware prompt assembly, multi-breakpoint caching, invalidation strategies — are in the Prompt Caching Guide 2026.

Tool use and agentic patterns

Opus 4.7 is strong at tool use when the tool definitions are good. That is the real prompt — not the user turn, but the tool specs the model reads every time.

A good tool description includes:

• Purpose — one sentence on what the tool does
• Preconditions — when it is valid to call
• Inputs — typed parameters with examples
• Outputs — the shape of what comes back
• When not to use — the discriminator against other tools

The last bullet is the one most people skip. Without it, Opus will pick plausibly-named tools when a better option exists nearby. A search_docs tool and a search_tickets tool need to know about each other or the model will call the wrong one on ambiguous queries.

For structured output, Opus follows JSON schemas and regex constraints faithfully. Use them when the downstream consumer is a parser, not a human. For deterministic tool selection, tool_choice lets you force a specific tool on a given turn — useful in the first step of a pipeline where the model would otherwise wander.

The larger pattern is layered. A production agentic prompt has:

• Persistent system rules — who the agent is, what it can never do
• Session context — the user, their goals, prior turns
• Current task — what to do now
• Tool layer — the tools and when to use each
• Plan-execute-reflect loop — structure that lets the agent recover from bad tool outputs

This is the Agentic Prompt Stack in brief. For coding-agent-specific patterns — work-order prompts, stop conditions, verification — see the Complete Guide to Prompting AI Coding Agents and the Claude Code prompting guide. Computer use is a specialized case; the computer-use glossary entry covers the category.

Score your prompts against the Rubric

Opus is forgiving on phrasing. It is unforgiving on missing context, ambiguous success criteria, and poorly-specified output format. The SurePrompts Quality Rubric is the audit we run before shipping any production prompt — it exposes exactly where a prompt is thin.

For Opus specifically, the dimensions that matter most:

• Context completeness — every fact the model needs is either in the prompt or retrievable by a tool
• Success criteria — the prompt describes what a good answer looks like, not just what to do
• Output format specification — exact schema, exact structure, exact length bounds
• Failure modes named — what to do when the model cannot answer, rather than hoping it refuses gracefully

Opus is more forgiving than smaller models on:

• Phrasing — synonyms and rewording usually do not change behavior
• Example density — one or two good examples often beat five mediocre ones
• Politeness — it does not need please-and-thank-you to cooperate

Run your prompt through the rubric once before production, and again whenever an eval regresses. The dimensions where Opus underperforms are almost always rubric-visible. RCAF gives you the floor; the rubric gives you the ceiling.

Common mistakes prompting Opus 4.7

• Turning on extended thinking for drafting tasks. Thinking budgets cost tokens and do not improve prose. Keep it off for writing, summarization, and classification.
• Treating 1M context as a "paste everything" invitation. Retrieval almost always beats packing. A focused 10K-token prompt outperforms an unfocused 500K one on quality, cost, and latency.
• Caching nothing. At Opus prices, leaving a stable 20K-token system prompt uncached across a high-volume workflow is a five-figure mistake per year, easily.
• Weak tool descriptions. "Searches docs" is not a tool spec. Purpose, preconditions, inputs, outputs, and when-not-to-use are all load-bearing.
• Using Opus for tasks Sonnet handles fine. Model routing is a prompting decision. If your eval does not distinguish Sonnet from Opus on a given task, route to Sonnet.
• No stop condition on agentic runs. Opus will keep iterating past "done" if you do not tell it when to halt. Name the stop condition explicitly in the task block.

Our position

• Opus is for hard cases, not default traffic. Route to Sonnet by default, escalate to Opus when evals or human review show the cheaper model is failing. A lot of teams leave quality on the table by over-routing; a lot more leave money on the table by under-routing. Measure.
• Extended thinking is a scalpel, not a switch. The question is always "does this task reward reasoning?" If the answer is no, thinking is a tax on quality, not an improvement.
• Caching is non-negotiable at Opus volume. If you are shipping Opus in production and not caching your system prompt, you are leaving an enormous amount of money on the table. It is the highest-leverage optimization available.
• 1M context is for rare cases. Use retrieval first; reach for long-context only when retrieval genuinely cannot find the right span. "Because I can" is not a reason to pack 500K tokens.
• Tool specs are prompts too. The difference between a good agentic run and a bad one is often in the tool descriptions, not the user turn. Treat them with the same care.

Related reading

• Claude 4 Prompting Guide — foundational Claude prompting patterns
• Claude Code Prompting Guide — terminal-native agentic coding
• Extended Thinking Prompts for Claude — deeper patterns on when and how
• Prompt Caching Guide 2026 — cache-aware assembly
• Agentic Prompt Stack — the layered model for tool-using agents
• SurePrompts Quality Rubric — audit your prompts before shipping
• Context Engineering Maturity Model — where your org sits and where to go next