Reviews

How to Use Claude Opus 4.7: What Actually Changed and How to Prompt It Right

A practical guide to Claude Opus 4.7 covering adaptive thinking, xhigh effort, task budgets, vision upgrades, and the prompting changes that matter.

Editorial illustration of a writer calibrating a giant teal dial, representing the precision needed to use Claude Opus 4.7

Claude Opus 4.7 dropped on April 16, 2026, and it is the most capable generally available model Anthropic has released. To use it well, you need to know three things: it follows your instructions more literally than 4.6, it decides how much to think on its own through adaptive thinking, and old prompting scaffolding like “think step by step” now actively hurts your results. If you are still using prompts you wrote for Opus 4.6, this guide will show you what to change and why the changes matter.

I have been using Opus 4.7 since the day it came out, primarily for writing projects in Claude Code and for knowledge work on claude.ai. What follows is not a press release summary. It is what I found when I sat down with the model and paid attention to the difference between what Anthropic says it does and what it actually does when you use it.

What Opus 4.7 Actually Is (and Is Not)

Opus 4.7 is Anthropic’s top-tier model, sitting above Sonnet 4.6 and Haiku 4.5 in the lineup. It is built for work that requires sustained reasoning over long tasks: agentic coding, complex knowledge work, document analysis, and vision-heavy workflows. The model string is claude-opus-4-7 and you can access it through claude.ai, the Anthropic API, Claude Code, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry.

What it is not: a faster Sonnet. If you need quick classification, short summaries, or high-throughput extraction, Sonnet 4.6 or Haiku 4.5 will do the job at a fraction of the cost. Opus 4.7 costs $5 per million input tokens and $25 per million output tokens, the same as Opus 4.6, but the new tokenizer can use up to 35% more tokens on the same text depending on content type. That means your effective cost per task may be higher even though the per-token price did not change. Keep this in mind before switching everything to Opus.

The Mythos preview exists in the background, but it is not publicly available, so I am not going to speculate about it. When I can test it, I will write about it. Until then, Opus 4.7 is the model that matters.

The Five Things That Changed from 4.6 to 4.7

Not everything changed. The context window is still 1 million tokens. Max output is still 128k tokens. Tool use, system prompts, and the basic API structure all work the same. But five things did change, and they affect how you should prompt and work with the model.

1. Adaptive Thinking Replaced Extended Thinking

In Opus 4.6, extended thinking was a toggle: you turned it on, the model thought deeply about everything, and you paid for all that thinking whether the question needed it or not. Opus 4.7 replaced this with adaptive thinking, which means the model decides how much to think based on the complexity of your request.

The reason this matters is practical. Ask Opus 4.7 “What is the capital of France?” and it answers immediately without burning thinking tokens. Ask it to debug a race condition in a concurrent system and it will invest significant reasoning before responding. The model allocates compute where it actually helps instead of treating every question like a final exam.

Adaptive thinking is disabled by default in the API. You have to opt in explicitly. On claude.ai, it works automatically when the thinking toggle is on.

Here is what I noticed in practice: with adaptive thinking enabled, the model is noticeably better at deciding when a problem is simple and when it is hard. I asked it to review a 200-line Python script for bugs and it found a subtle off-by-one error that Opus 4.6 with extended thinking also caught, but it did it in roughly 40% fewer thinking tokens. On easy questions, the difference is even bigger because it just answers instead of performing unnecessary reasoning.

2. Literal Instruction Following

This is the change that will break your old prompts if you do not adapt. Opus 4.7 takes your instructions more literally than 4.6. If you tell it to “write a paragraph about X,” it writes a paragraph, not three paragraphs with a helpful introduction. If you tell it to edit only the function signature, it does not helpfully refactor the function body while it is there.

Why this matters: Opus 4.6 was generous with interpretation. It would read between the lines, add things you did not ask for because it assumed you would want them, and generally try to be helpful beyond the explicit request. Opus 4.7 does what you say. Not more, not less.

This sounds like a small change but it reshapes how you write prompts. Vague prompts that worked fine with 4.6 produce shallow results with 4.7 because the model no longer fills in the gaps for you. Detailed prompts produce significantly better results because the model executes exactly what you specified.

The prompt you need to remove:

Think step by step about this problem before answering.

This kind of scaffolding was useful with older models that needed nudging toward deeper reasoning. Opus 4.7 handles reasoning depth through effort levels and adaptive thinking. Adding “think step by step” is now redundant at best, and at low effort levels it can actually confuse the model about how much work you want it to do.

The prompt that works better now:

Review this code for concurrency bugs. Check specifically for:
- Race conditions in shared state access
- Missing mutex locks around write operations  
- Deadlock potential in the lock ordering

Report each bug with the file path, line number, and a fix.

Specific instructions, specific output format. Opus 4.7 will follow this precisely. Opus 4.6 would have followed it approximately and added some bonus observations you did not ask for.

3. The xhigh Effort Level

Opus 4.7 introduced a new effort level called xhigh that sits between high and max. Claude Code defaults to it, and for good reason: it gives you deeper reasoning than high without the full token cost of max.

Here is how the effort levels work in practice:

Low and medium are for simple tasks: classification, extraction, formatting, short summaries. The model scopes its work tightly and does not go beyond what you asked. If you notice shallow reasoning on a complex problem, the fix is to raise the effort level, not to add more prompting.

High gives you strong reasoning with reasonable token usage. Good for most knowledge work and writing tasks.

xhigh is the sweet spot for coding and agentic work. It gives the model enough reasoning budget to plan, execute, and verify without the diminishing returns of max. This is where I run most of my Claude Code sessions.

Max squeezes out additional performance on the hardest problems but is more prone to overthinking. Use it when the problem actually justifies the cost.

The practical lesson I learned: matching effort level to task complexity matters more with 4.7 than it did with 4.6. Running xhigh on a simple reformatting task wastes tokens because adaptive thinking runs longer on any ambiguity in your prompt. Running high on a complex debugging task produces noticeably worse results than xhigh. Think of effort level as a volume knob for how hard the model works on your problem, and set it appropriately.

4. Task Budgets for Agentic Loops

Task budgets are new with Opus 4.7 and they solve a real problem: when you give the model an open-ended agentic task, how does it know when to wrap up?

A task budget gives Claude a total token ceiling for an entire agentic loop, including thinking, tool calls, tool results, and final output. The model sees a running countdown and uses it to prioritize work, finishing the task gracefully as the budget is consumed instead of either cutting off abruptly or spiraling into endless tool calls.

To set one via the API, you pass the task-budgets-2026-03-13 beta header and add task_budget: {type: "tokens", total: N} to your output config, with a minimum of 20,000 tokens.

In practice, this is most useful for agentic coding sessions where the model is reading files, writing code, running tests, and iterating. Without a task budget, a complex task can burn through tokens indefinitely as the model discovers more things to investigate. With a budget, it learns to prioritize the most important work and deliver a usable result within the constraint. I set mine to 100k tokens for medium complexity tasks and 200k for larger refactoring jobs, and the model has been remarkably good at pacing itself.

5. High-Resolution Vision

Opus 4.7 is the first Claude model with genuine high-resolution image support. The maximum image resolution jumped from 1,568px on the long edge (about 1.15 megapixels) to 2,576px (about 3.75 megapixels). That is roughly a 3x increase in the detail the model can see.

This sounds like a spec sheet number until you actually use it. I tested it with a scanned financial report that had small text in table cells. Opus 4.6 could read the headers but garbled the numbers in the smaller rows. Opus 4.7 read the entire table correctly, including footnote text that was maybe 8pt font in the original document.

If your workflow involves reading dashboards, scanned forms, charts with small labels, or any image where details matter, this is a meaningful upgrade. The model also now does 1:1 coordinate mapping, which means pixel-level work is more precise without needing scale-factor adjustments.

How to Prompt Opus 4.7 (Real Prompts You Can Use)

The general principle is this: be specific about what you want, be explicit about the format you want it in, and stop hand-holding the reasoning process. Opus 4.7 does not need you to tell it how to think. It needs you to tell it what to produce.

For Writing Tasks

Instead of this (4.6-era prompt):

You are an expert writer. Think carefully about the topic and 
write a well-structured, comprehensive article about remote work 
trends in 2026. Make it engaging and informative.

Use this (4.7-optimized):

Write a 1,200-word article about remote work trends in 2026.

Audience: HR directors at mid-size companies (200-2000 employees).
Angle: The three policy changes that reduced attrition by 15%+ 
at companies that adopted them.
Tone: Authoritative but not academic. No buzzwords.
Structure: Open with the strongest data point, then cover each 
policy change with one company example each, close with 
implementation priority.

Do not include an introduction that restates the title.
Do not use the phrases "in today's landscape" or "game-changer."

The first prompt gives Opus 4.7 almost nothing to work with, so the literal-instruction-following model produces something generic. The second prompt gives it constraints, an angle, an audience, and specific exclusions. The model executes exactly this because that is what it does now.

For Code Review

Review this pull request for production readiness.

Check for:
1. Error handling gaps (uncaught exceptions, missing try/catch)
2. Performance issues (N+1 queries, unnecessary iterations)
3. Security concerns (injection vectors, auth bypasses)

For each issue found:
- Quote the specific line(s)
- Explain why it is a problem
- Provide the corrected code

If you find no issues in a category, say so explicitly. 
Do not invent problems.

That last line matters with Opus 4.7. Because it follows instructions literally, telling it “do not invent problems” prevents the model from being overly helpful by flagging non-issues to look thorough.

For Data Analysis

Analyze the attached CSV. It contains monthly revenue data 
for 2024-2025 by product line.

Produce:
1. A summary table showing YoY growth rate by product line
2. The three product lines with strongest growth trajectory
3. Any anomalies (months where revenue deviated >20% from 
   the 3-month moving average)

Present numbers as actual values, not rounded. 
Use plain text tables, not markdown code blocks.

Specific output format, specific thresholds, specific presentation requirements. Opus 4.7 follows all of these. With 4.6, you would get roughly this output but with some creative additions you did not request. With 4.7, you get exactly this.

Claude Code + Opus 4.7: The Workflow That Works

Claude Code defaults to Opus 4.7 at xhigh effort, and this combination is where the model performs best. Here is how to get the most out of it.

Your CLAUDE.md file is now critical. Because Opus 4.7 follows instructions literally, the CLAUDE.md file in your project becomes your primary way to encode conventions, preferences, and constraints. Audit it. If you previously relied on the model to figure out your coding style, your testing preferences, or your file organization patterns, write them down explicitly. The model will not guess anymore. It will do what you tell it to do.

Here is what I put in my CLAUDE.md for writing projects:

## Conventions
- All output files go in /outputs
- Use snake_case for file names
- When editing existing files, preserve the original structure
- Do not add comments explaining obvious code
- Run the linter before reporting a task as complete

## Voice
- Load the relevant voice skill before writing any prose
- Never use em dashes
- Join related short thoughts with conjunctions, not periods

Turn on auto-accept for tool calls. Opus 4.7 is designed for autonomous execution. Approving every file read and search manually defeats the purpose of its agentic capabilities. Let it run, read files, search the codebase, execute code, and iterate. Intervene when it asks you a question, not at every tool call.

Give it the full task upfront. Treat Opus 4.7 like a capable engineer you are delegating to, not a pair programmer you are guiding line by line. Specify the task, the constraints, the acceptance criteria, and the relevant file locations in your first message. Then let it work. The model is better at planning and executing multi-step tasks when it sees the full picture from the start.

Use task budgets for large refactoring. If you are asking Claude Code to migrate a module, refactor an API, or update tests across a codebase, set a task budget so the model prioritizes the most important changes and delivers a coherent result instead of getting lost in an endless chain of discoveries.

Self-Verification: The Feature Nobody Is Talking About

Opus 4.7 proactively verifies its own output before reporting a task as complete. In coding tasks, this means it writes tests, runs them, checks the output, and fixes issues before telling you it is done. In document tasks, it inspects formatting, checks for consistency, and catches errors that previous models would have missed.

I first noticed this when I asked it to generate a Python module with type hints. Instead of writing the code and handing it back, it wrote the code, ran mypy on it, found two type errors, fixed them, ran mypy again to confirm they were resolved, and then reported back. With Opus 4.6, I would have gotten the code with the type errors still in it and caught them myself during review.

This is not a feature you need to prompt for. It is native behavior. The model does it when the task warrants verification. But you can reinforce it by including acceptance criteria in your prompt: “The code must pass all existing tests and the type checker with zero errors.” Opus 4.7 will take that literally and verify before delivering.

[INTERNAL: self-verification prompting patterns]

Prompt Caching: The Highest-Leverage API Optimization

If you are building with Opus 4.7 through the API, prompt caching is the single biggest cost optimization available to you. Cached input tokens cost 90% less than uncached ones, and batch processing saves another 50%.

The way it works: you structure your API calls so that the stable parts of your prompt (system prompt, role definitions, few-shot examples, tool descriptions, reference documents) are above the cache breakpoint, and the variable parts (the current user message, the current document) are below it. Anything above the breakpoint that matches a recent cached prefix gets served from cache instead of being reprocessed.

The important detail that most guides skip: Anthropic changed the cache TTL from 60 minutes to 5 minutes in early 2026. This means your cache expires fast. If your requests are not frequent enough to keep the cache warm, you will not see the savings. Monitor your cache hit rate (cache_read_input_tokens / (cache_read_input_tokens + input_tokens)) and aim for above 60% on production workloads.

The minimum cacheable prefix is 2,048 tokens for Opus models. Anything shorter gets processed without caching even if you mark it with cache_control.

[INTERNAL: prompt caching implementation guide] [INTERNAL: Claude API cost optimization]

What Opus 4.7 Is Bad At (Because Someone Should Say It)

Every other guide you will find focuses on what the model is good at. Here is where it falls short, because knowing the limitations saves you more time than knowing the strengths.

The new tokenizer costs more. The same text that cost X tokens with 4.6 can cost up to 1.35X with 4.7. Combined with deeper reasoning at higher effort levels, your bills can jump noticeably. I saw a roughly 25% increase in my API spending on comparable tasks during the first week before I adjusted my effort levels and started using task budgets.

Literal instruction following punishes vague prompts. If you were used to 4.6 reading between the lines and filling in what you meant, you will get worse results from 4.7 until you rewrite your prompts to be explicit. This is not a bug, it is a design choice, but it does mean there is a transition cost.

It is not faster. Opus 4.7 at xhigh or max effort takes more time per response than 4.6 did for comparable tasks. The output quality is higher, but if speed matters more than quality for your use case, Sonnet 4.6 is still the better choice.

The 5-minute cache TTL hurts low-traffic API users. If you are building a product with inconsistent request patterns, prompt caching may not save you as much as you expect. The cache expires quickly and cache misses are expensive.

When to Use Opus 4.7 vs. Sonnet 4.6

Use Opus 4.7 when: you need deep reasoning, long-running agentic tasks, complex code generation or review, high-fidelity vision analysis, or any task where getting it right the first time is worth paying more.

Use Sonnet 4.6 when: you need speed, you are doing high-volume processing, the task is well-defined and does not require deep reasoning, or cost matters more than maximum quality.

Use Haiku 4.5 when: you are doing classification, extraction, simple formatting, or any task where the cheapest capable model is the right answer.

I use all three regularly. Opus 4.7 for my writing projects and complex code work, Sonnet for quick tasks and high-volume processing, Haiku for anything that is essentially pattern matching. The right model is the one that matches the complexity of your task, not the one with the highest number in its name.

[INTERNAL: Claude model comparison 2026]

FAQ

Is Claude Opus 4.7 free to use? On claude.ai, you can use Opus 4.7 with a Pro ($20/month) or Team subscription. Free-tier users get limited access. Through the API, you pay per token: $5 per million input tokens and $25 per million output tokens, with savings available through prompt caching and batch processing.

What is adaptive thinking and do I need to enable it? Adaptive thinking lets the model decide how much reasoning to invest per question. It is automatic on claude.ai when the thinking toggle is on. On the API, you need to opt in explicitly. You should enable it for any task where reasoning depth varies across your requests, which is most tasks.

Should I switch all my prompts from 4.6 to 4.7? Not blindly. Test your existing prompts first. If they are vague or rely on the model filling in gaps, they will produce worse results with 4.7 until you make them more specific. Start with your highest-value workflows, test, adjust, then expand.

What is the xhigh effort level and when should I use it? xhigh sits between high and max. It is the default in Claude Code and the best setting for most coding and agentic work. Use it when you need deep reasoning without the full token cost of max. Drop to high or medium for simpler tasks.

How does Opus 4.7 compare to GPT-4o and Gemini 2.5 Pro? I have tested all three extensively and the honest answer is: it depends on the task. Opus 4.7 is the strongest I have used for writing, code review, and long agentic sessions. GPT-4o remains competitive for general knowledge and conversational tasks. Gemini 2.5 Pro has the largest context window but struggles with consistent quality on long tasks. I will write a detailed comparison soon.

[INTERNAL: Claude vs ChatGPT vs Gemini comparison 2026]

Can I use Opus 4.7 with Claude Code? Yes, and it is the default model for Claude Code. Install or update via npm install -g @anthropic-ai/claude-code, and it runs at xhigh effort by default. Your CLAUDE.md file becomes critical for encoding project conventions because the model follows instructions literally.


Tested with Claude Opus 4.7 (claude-opus-4-7) between April 16 and April 25, 2026. Used on claude.ai with a Pro subscription and through the Anthropic API with Claude Code. Prompts, effort levels, and task budgets were tested across writing, coding, and document analysis tasks. If this article is more than two months old when you are reading it, some specifics may have changed. The principles should hold.


Related Keywords This Article Should Help Rank For

  1. how to use claude opus 4.7
  2. claude opus 4.7 tutorial
  3. claude opus 4.7 prompts
  4. claude opus 4.7 guide 2026
  5. claude 4.7 vs 4.6
  6. claude opus 4.7 adaptive thinking
  7. claude opus 4.7 xhigh effort
  8. claude opus 4.7 task budgets
  9. claude opus 4.7 prompt caching
  10. claude opus 4.7 vision
  11. claude opus 4.7 best practices
  12. claude opus 4.7 claude code
  13. claude opus 4.7 pricing
  14. claude opus 4.7 API guide
  15. claude 4.7 prompting tips

Suggested Next Articles (Content Silo)

  1. “Claude Opus 4.7 vs GPT-4o vs Gemini 2.5 Pro: Tested on Real Work” (comparison)
  2. “Claude API Prompt Caching: The Implementation Guide That Saves You 90%” (technical)
  3. “Claude Code for Non-Developers: What It Is and Why You Should Care” (beginner)
  4. “How to Write a CLAUDE.md File That Actually Works” (tutorial)
  5. “Adaptive Thinking in Claude 4.7: When to Enable It and When to Skip It” (deep dive)
  6. “Claude Opus 4.7 Self-Verification: How to Prompt for Reliable Output” (technique)
  7. “The Real Cost of Claude Opus 4.7: Token Math for API Users” (analysis)
  8. “Best AI Model for Writing in 2026: I Tested Five of Them” (comparison)
  9. “Task Budgets in Claude 4.7: How to Control Agentic Loops” (technical)
  10. “Claude vs ChatGPT for Coding: 2026 Head-to-Head Test” (comparison)

Meta Description

Learn how to use Claude Opus 4.7 with practical prompts, effort levels, adaptive thinking, and real testing results. Updated April 2026.