Claude Opus 4.7: 5 settings that make 70% of the difference

Opus 4.7 dropped on April 16. Effort mode, cache, instruction following, vision, routing: 5 specific settings, with use cases.

Alexandre04/22/20267 min read

I covered the Opus 4.7 benchmarks last week: 64.3% on SWE-bench Pro, 98.5% on pen-testing, Mythos still out of reach. The numbers are good. Knowing a model is better is useless if you call it exactly like the old one.

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.

Level	When to use it
`low`	Simple subagents, mechanical tasks, formatting
`medium`	Refactoring, tests, factual answers, anything well-defined
`high`	Complex debugging, code migration, non-trivial feature
`xhigh`	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:


{
  "model": "claude-opus-4-7-20260416",
  "max_tokens": 64000,
  "thinking": {
    "type": "adaptive",
    "effort": "xhigh"
  },
  "messages": [...]
}

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.


{
  "model": "claude-opus-4-7-20260416",
  "system": [
    {
      "type": "text",
      "text": "Your long system prompt here...",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [...]
}

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.

Three adjustments in how you write prompts:

Before (4.6)	After (4.7)
"Test the component"	"Test the component: happy path, network error case, missing props case"
"Refactor this file"	"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:


{
  "type": "image",
  "source": {
    "type": "base64",
    "media_type": "image/jpeg",
    "data": "<base64>"
  }
}

What I send as images instead of describing in text since April 16:

Use case	Why as an image
Visual bug on an interface	Describing a broken alignment in words is painful and imprecise. A screenshot, and Claude sees the problem directly.
Architecture diagram	Excalidraw or draw.io export. Ask the question directly on the diagram.
Metrics dashboard	Grafana, Datadog. Pass the capture rather than copying numbers one by one.
Terminal error	Capture with surrounding context, not just the isolated error message.

The only limit: if the source image is blurry or low resolution, the model-side resolution will not compensate. It starts from the source.

Setting 5: Sonnet / Opus routing

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.

Written on April 22, 2026. Sources: Anthropic Blog, Introducing Claude Opus 4.7, Anthropic Docs, Extended Thinking, Anthropic Docs, Prompt Caching, Anthropic Docs, Vision, CNBC, 9to5Mac.

← Back to articles

AI News

Comments

Got a take on this article?

Create a free account in 10 seconds to comment, like, and get the next articles straight to your inbox.

Don't have an account yet?

Claude Opus 4.7: 5 settings that make 70% of the difference

What changed under the hood

Setting 1: effort level

Setting 2: prompt cache

Setting 3: rewrite your prompts for instruction following

Setting 4: high-resolution vision

Setting 5: Sonnet / Opus routing

My setup since April 16

Related articles

AI News November 1, 2026: Anthropic Files Its S-1, Gemini 4 Carbon and Mistral Large 4

AI News October 24, 2026: Anthropic's Claude Duet, Google's Agent Compute Engine, OpenAI on Google Cloud

AI News October 16, 2026: Anthropic books $16.8B in a quarter, Gemini 4 Argon at $2, Character.ai goes bankrupt

Comments

Comments