And that is what most devs do. They swap the model ID, keep the same default parameters, and wonder why their bill goes up while the results look the same as before.
Here is what actually needs to change.
What changed under the hood
The tool error rate was cut by 3x compared to Opus 4.6 (confirmed by Box and Replit). Image resolution goes up to 2,576 px. Long-context coherence is back. It is not just "a better model". It is a model that behaves differently.
The drift that made the model forget first-hour instructions after two hours of session, the one I documented in the article on Opus 4.6 degradation, does not happen anymore. A different behavior means it needs different configuration.
Setting 1: effort level
Opus 4.7 introduced the xhigh tier, with around 20,000 tokens of internal reasoning per request. This is the mode where the model actually thinks before answering, instead of producing the first plausible solution. Leaving it on xhigh permanently is waste. Not activating it on hard problems means skipping the one thing that justifies Opus pricing.
The trap: on a trivial refactoring or unit test generation, you pay 20,000 tokens of reasoning for a result identical to auto. On the flip side, asking for an architecture decision in auto means missing out entirely.
Open-ended problem with no lead, critical architecture decision, long task
max
Opus 4.6 only, unconstrained reasoning budget
In Claude Code, you can switch on the fly with /effort xhigh or /effort high. To set a default level for a project, add it to .claude/settings.json:
{
"preferences": {
"effort": "xhigh"
}
}
On the API (Python/TypeScript SDK or direct calls), the parameter goes in the request body. Note: the old format thinking: {type: "enabled", budget_tokens: N} has been deprecated since Opus 4.6 and returns a 400 error on 4.7+. Use adaptive thinking instead:
Available values: "low", "medium", "high" (API default), "xhigh" (new on Opus 4.7), "max" (Opus 4.6 only). Anthropic recommends starting at xhigh for coding and agentic workflows, and only going to max if evals show a measurable gain.
Latency goes up. That is the price. But when you send a problem that genuinely deserves 20 seconds of thought, the quality of the first response changes. Less back-and-forth, fewer corrections, ultimately fewer tokens consumed. I use this setup every day on Waku and the difference is real on sessions over an hour.
Setting 2: prompt cache
Prompt cache is the most cost-effective and least configured setting I see among devs using the API. On blocks that do not change between calls (system prompt, reference docs, frozen history), you go from $5 to $0.50 per million tokens. A 90% reduction.
This setting only applies to direct API calls (Python/TypeScript SDK, fetch, or platforms like Amazon Bedrock and Vertex AI). In Claude Code and on claude.ai, caching is handled automatically.
In practice: if your system prompt is 4,000 tokens and you make 100 calls in a day, without cache you pay 400,000 input tokens at full price. With cache_control: ephemeral, you pay the first call at full rate and the next 99 at 90% off. The difference shows up on day one.
Two constraints: the cache expires after 5 minutes without access (1-hour option available at extra cost), and you need a minimum of 4,096 tokens for it to activate. Below that, the request goes through but without caching, and no error is returned. You think it is caching. It is not.
I detailed my full token reduction method in this article. Cache was part of it, but back then it was on Opus 4.6 and the impact was already significant. On 4.7, with longer and more stable sessions, the gain is even clearer.
Setting 3: rewrite your prompts for instruction following
Opus 4.6 interpreted. If your prompt was vague, it filled the gaps, it guessed what you wanted. Sometimes right, often approximate. Opus 4.7 executes. If you say "generate tests for this component" without specifying what to cover, it will only test what is explicitly visible in the code. No inference on edge cases, no assumptions.
At first it feels like a regression. But on long sessions and agentic workflows, it is exactly what was missing. A model that follows instructions to the letter on step 5 of a 6-step plan, instead of taking a shortcut because it "thinks it knows" what you want.
"Refactor this file: extract business logic into a service, keep the controller thin, preserve the public interface"
"Fix the bug"
"Fix the bug: the state does not reset after submit, check the useEffect cleanup"
It takes 2 extra minutes per prompt. But those 2 minutes replace the 15 minutes of corrections you used to spend after the fact on 4.6. On Waku, I felt the difference clearly: sessions are cleaner because the model does exactly what you asked, not what it thinks you want.
Setting 4: high-resolution vision
Opus 4.7 native resolution went up to 2,576 pixels, from around 685 on 4.6. CharXiv Reasoning reaches 91% with tools (84.7% before). Sending a screenshot instead of describing a bug in prose takes 2 seconds and gives a more accurate result.
Before 4.7, passing a code screenshot or UI capture to Claude was a gamble. Compression degraded details, the model missed characters, small text in diagrams got lost.
In Claude Code, you drag an image file directly into the terminal, or use @path/to/screenshot.png in your prompt. The model receives the image in high resolution with no extra steps.
On the API, you pass the image as base64 in the content field of a message:
Opus 4.7 costs 5x more than Sonnet on input. On a summarization task, reformulation, or standard unit test generation, Sonnet gives the same result. Paying for Opus here is like hiring a surgeon to put on a band-aid.
Task
Sonnet
Opus 4.7
Latency-critical (real-time, UI)
Yes
No
Well-defined task, low ambiguity
Yes
No
Complex multi-step reasoning
No
Yes
Long session (>50k tokens, coherence required)
No
Yes
Autonomous agent over several hours
No
Yes
Unit tests, formatting, summarization
Yes
No
Subtle bug with no clear lead
No
Yes
My rule: if I can write the full task specification in under 500 tokens and I know what the output should look like, it is Sonnet. If the task requires judgment, nuance, or multiple reasoning turns, it is Opus.
Box measured a 30% cost reduction going from 4.6 to 4.7 at equal quality. Part of it comes from the model itself (fewer calls, fewer errors). The other part comes from routing. I detailed this logic in my article on AI code agent architecture, and my full workflow setup in my Claude Code writeup.
My setup since April 16
Setting
What I do
Gain
Effort
xhigh for architecture and bugs with no lead, high for everything else
Better first-response quality, less back-and-forth
Cache
Enabled on all API system prompts
Visible from day one, about 90% on cached blocks
Instruction following
Prompts rewritten with explicit constraints
2 min more writing, 15 min less in corrections
Vision
Direct screenshots for UI, metrics, diagrams
No more useless prose descriptions
Routing
Sonnet for well-defined tasks, Opus for judgment
Bill cut without quality loss
The long-context drift on Opus 4.6 had broken my trust in sessions over an hour. That problem is fixed. Everything else is configuration.
Found a different setup that works better on your projects? Comments below or on X.
Alex
Key takeaways
The xhigh effort level is the right default for complex coding and agentic work. Leaving it on auto for an architecture problem means skipping the one thing that justifies Opus pricing.
Prompt cache cuts input costs by 90% on repeated blocks (system prompts, docs). Minimum 4,096 tokens for it to activate. The gain is visible from day one.
Opus 4.7 executes instead of interpreting. Explicit prompts with named constraints replace the 15 minutes of corrections that were needed on 4.6.
High-resolution vision (2,576 px) makes screenshots more useful than text descriptions for visual bugs, diagrams, and dashboards.
Sonnet/Opus routing cuts the bill without quality loss: Sonnet for well-defined tasks, Opus for judgment and long sessions.
