Stop Blaming Claude Opus 4.7. Your Prompts Were Always Broken — 4.6 Was Just Carrying You.

The model improved 14% on multi-step workflows and cut tool errors by two-thirds. So why does every Reddit thread this week call it a downgrade?

There is a story being repeated across X, Reddit r/ClaudeAI, Hacker News, and three Discord servers I lurk in. The story goes like this: Anthropic shipped Opus 4.7 on April 16. Developers updated their model strings. Outputs got shorter. Tool calls got terser. Some API requests started returning 400 errors with no obvious cause. Therefore, 4.7 is a regression and Anthropic is hiding the truth.

I have been migrating production prompts off 4.6 for the last two weeks. I have rewritten forty-three system prompts across two real codebases and one client agent. I have read Anthropic’s own evaluation notes, dug through the new tokenizer behavior, and run side-by-side comparisons on tasks I actually care about.

The story is wrong.

Opus 4.7 did not get worse. It stopped covering for prompts that were never good to begin with. And the people loudest about the “downgrade” are — almost without exception — running prompts written between November 2024 and February 2026, when 4.6 was so generous about inferring intent that you could ship a one-line instruction and get a thousand-word answer that mostly nailed it.

That generosity is gone. What replaced it is a model that does exactly what you typed. Not what you meant. Not what 4.6 would have inferred from context. What you actually typed.

If your prompts were tight, you have not noticed the change. If your prompts were vague, you are blaming the model.

The migration cost is not a model regression. It is a debt you accumulated by writing fuzzy prompts against a model that was generous enough to fix them silently.

If you want the fully annotated 600-line prompt migration kit I used across the forty-three rewrites — including the four-block templates, the XML scaffolds, and the effort-level decision tree — that ships separately at [wowhow.cloud/browse/###]. The article gives you the thesis and the fixes. The kit gives you the artillery.

What The Reddit Threads Are Missing

Let me start with the data, because the discourse is operating on vibes and the data is pretty clean.

Benchmark                          │  Opus 4.6  │  Opus 4.7  │  Delta
───────────────────────────────────┼────────────┼────────────┼──────────────────────
SWE-bench Verified                 │  80.8%     │  87.6%     │  +6.8 points
Multi-step workflow accuracy       │  baseline  │  +14%      │  Major lift
Tool errors per task               │  baseline  │  −66%      │  Cut by two-thirds
Implicit-need tests (Notion eval)  │  failed    │  passed    │  First Claude to pass

Sarah Sachs, AI Lead at Notion, called this out in Anthropic’s official evaluation. Opus 4.7 is the first Claude model to pass Notion’s implicit-need tests — the eval where the model has to infer a user’s deeper intent across a long workflow without being explicitly told what to do. That is the opposite of getting worse.

So why does it feel worse to so many developers?

Because the same property that lets the model pass implicit-need tests at the workflow level — careful, deliberate reading of intent — makes it allergic to fuzzy single-prompt instructions where the user wanted the model to fill in gaps. 4.6 would fill the gaps. 4.7 reads what you wrote and executes it. If you asked for a “summary,” you get a summary. Not a summary plus a follow-up email plus three suggested next actions plus a TL;DR. 4.6 used to give you all of that as a bonus. 4.7 stopped.

Here is the truth nobody wants to admit: most of us were prompting 4.6 like search engines and getting away with it. We were typing bullet-list scaffolds and watching the model output finished work. The illusion of skill was the model’s generosity.

The Five Things That Actually Changed

Reading through Anthropic’s release notes plus the system prompt repo at github.com/asgeirtj/system_prompts_leaks (Opus 4.7 entry dated April 22), there are exactly five behavioral changes that account for ninety percent of the complaints. None of them are regressions.

1. Adaptive thinking replaces manual budgets

In 4.6 you set budget_tokens: 32000 and the model thought for that many tokens whether the task needed it or not. In 4.7 you set thinking: { "type": "adaptive" } and the model decides per-request. Simple math problem? Five hundred thinking tokens. Multi-step refactor? Twenty thousand.

This is better in production — you stop paying for thinking tokens you do not need. But it breaks every prompt that was implicitly relying on the model to “think hard about everything.” If you want consistent deep reasoning, you set effort: "high" or "xhigh" (new in 4.7, default for Claude Code) and the model bumps the floor.

2. Sampling parameters removed

temperature, top_p, and top_k no longer work on 4.7. API returns 400. Many tools and SDK wrappers still pass these by default — if you didn't update your client, half your requests are silently failing.

This one is a one-line fix. But if you were leaning on temperature: 0.2 for deterministic outputs, you now lean on prompt structure instead. The model is more deterministic out of the box; it just refuses to let you tune the dial.

3. New tokenizer — same text, more tokens

This is the big one for cost-conscious teams. The same input text now maps to between 1.0× and 1.35× more tokens than 4.6. Some developers measured 1.16× to 1.51× in production. Pricing did not change — input is still $5 per million, output is $25 per million — but your effective cost per request rises.

Anthropic’s response was to raise rate limits across all subscriber tiers. Boris Cherny’s announcement post pulled over fifteen thousand likes — the highest engagement on any Anthropic engineering post to date, which tells you exactly how starved developers were for headroom.

The practical move: increase max_tokens by twenty to thirty-five percent across your call sites, and budget for ten to twenty percent higher monthly bills until you optimize prompt length. That is the floor. The ceiling — if you actually do the migration work in this article — is lower total cost than 4.6, because 4.7 stops generating bonus content you didn't ask for.

4. Vision resolution jumped 3.3×

From 1568px / 1.15 megapixels in 4.6 to 2576px / 3.75 megapixels in 4.7. If you have been running OCR or screenshot-based agents, this is a quiet superpower. Code on whiteboards, dense charts, mobile screenshots — all readable now in ways they were not before.

5. Prefilled assistant turns deprecated

You can no longer prefill the assistant’s last response to force a format. The capability that every prompt-engineering tutorial from 2024 told you to use is gone. The replacement: explicit format instructions in the system prompt, which the model now follows precisely enough that prefill is unnecessary.

If your system prompt depended on prefill, it is now broken in a way that fails silently — model just ignores the prefill content and freelances. You have to migrate the constraint into prose.

The Real Migration: How To Rewrite A Prompt For 4.7

Let me show you the actual surgery, because abstract advice is useless.

Here is a real prompt I had running in production on 4.6. It worked fine — most of the time:

You are a code reviewer. Review the PR diff below and flag issues.
Focus on bugs, security, and style.

On 4.6, this would produce a structured review with severity tags, file references, line numbers, and a summary verdict. The model inferred that “code reviewer” implied that scaffolding.

On 4.7, the same prompt produces three sentences of generic feedback. Because you didn’t ask for severity tags. You didn’t ask for line numbers. You didn’t ask for a summary verdict. You said “flag issues” and the model flagged them.

Here is the same prompt rewritten in what I now call the Four-Block Pattern — instructions, context, task, output format:

<role>
Senior code reviewer with a bias toward catching bugs over style nits. 
You disagree when the code is fine. You don't pad reviews to look thorough.
</role>

<context>
Codebase: TypeScript Next.js 16 app, strict mode on.
Team conventions: prefer composition over inheritance, no `any` types,
all async functions wrapped in try/catch, no console.log in production paths.
</context>

<task>
Review the PR diff. Categorize each finding into:
* BLOCKER (will break production)
* HIGH (likely bug, edge case, or security issue)
* LOW (style, naming, suggestion)
Skip findings you don't have high confidence in. Empty severity buckets are 
acceptable and preferred over speculation.
</task>

<output_format>
For each finding:
* Severity tag
* File and line reference
* One-sentence problem statement
* One-sentence proposed fix
End with a verdict line: APPROVE / REQUEST_CHANGES / BLOCK
</output_format>

The new version is six times longer than the old one. It is also six times more reliable, costs less per call (no bonus content, sharper outputs), and produces work you can actually merge into a CI pipeline.

This is the v9 pattern repeated forty-three times across my migration. Every time I made the prompt longer and more explicit, the output got tighter and the cost went down.

Opus 4.7 does not reward verbosity. It rewards specificity. The two are not the same.

The Effort Level Lever

This is the single most underused feature of 4.7 and it is hiding in plain sight.

effort accepts five values: low, medium, high, max, and the new xhigh (which is Claude Code's default and is not exposed in the chat interface). The model literally calibrates how much reasoning it does based on this setting. Low-effort runs scope tightly to what you asked. High-effort runs apply more inference and "fill in reasonable gaps" — closer to 4.6's old behavior.

Here is the decision matrix I now use:

Task type                    │  Effort  │  Why
─────────────────────────────┼──────────┼─────────────────────────────────────────
Quick targeted bug fix       │  low     │  Minimal scope creep, fastest response
Code review on a PR          │  medium  │  Balanced thoroughness without overreach
Multi-file refactor          │  high    │  Needs cross-file reasoning
Architecture proposal        │  xhigh   │  Deep tradeoff analysis required
Agentic loops with tool use  │  xhigh   │  Tool selection benefits from reasoning

If you set effort: "low" and complain about shallow output, you have configured the model to be shallow. If you set effort: "xhigh" for every request, you are paying premium prices for tasks that didn't need it.

The mistake I see most often in the Reddit threads: people set effort to low to save costs after the new tokenizer ate their budget, then complained the model got dumber. It did not get dumber. You told it to do less work.

What This Means For The Anthropic Critique

There is a legitimate critique of Anthropic in all of this, and it is not “the model is worse.”

The critique is that they shipped a behavioral change with a 1.0–1.35× tokenizer cost bump in the same release without giving developers a six-week heads-up to migrate prompts. The pattern recognition crowd on Hacker News is right that this is a tax on lazy prompts disguised as a model upgrade. Anthropic absorbed the optics by raising rate limits — which is generous — but the migration burden falls on individual developers whose prompts were tuned to 4.6’s compensations.

If you are running 4.7 at production scale and your costs are up twenty-five percent on identical workflows, the answer is not to roll back to 4.6 (which is on a deprecation timeline anyway). The answer is to spend two days rewriting your fifteen most-called prompts with the four-block pattern, ship them, and watch your costs come down below where they were on 4.6.

That is what the migration kit at [wowhow.cloud/browse/###] is for. It contains the four-block templates, the XML scaffolds, the effort-level decision tree, and a side-by-side of forty-three real prompt rewrites from my own migration. The article you’re reading right now is the philosophy. The kit is the artillery.

The Five Migrations You Should Do This Week

If you are running anything in production on 4.6 or 4.7 right now, here is the order of operations.

1. Audit your most-called prompt — whatever endpoint hits the API ten thousand times a day. Pull the system prompt. Read it like you’ve never seen it. Every place you typed something that requires inference (“good code”, “professional tone”, “comprehensive review”) is debt. Replace each one with explicit constraints.

2. Update your SDK to remove sampling parameters — strip temperature, top_p, top_k from every call site. They no-op or 400 on 4.7. Replace deterministic-output requirements with explicit format constraints in the prompt.

3. Set effort levels deliberately per endpoint — your “fast classifier” endpoint runs low. Your "reasoning-heavy planner" runs xhigh. Stop using a single global setting. The dial exists. Use it.

4. Migrate prefill-dependent prompts — search your codebase for any place you set the assistant’s last message before generation. Move that constraint into the system prompt as a format requirement. Test that the output still matches.

5. Bump max_tokens by 25% across the board — the new tokenizer eats more headroom. Most developers I've talked to set max_tokens: 4096 and never thought about it again. Bump to 5120. Watch for truncated outputs in your logs.

You can do all five in an afternoon if your codebase is small. If you are running fifteen-plus distinct prompt templates, give it a full day per cluster.

The Bigger Pattern

There is a thing happening with frontier models right now that the prompting tutorials have not caught up to.

The window between “models that compensated for human imprecision” and “models that execute precisely on what you wrote” is closing. Opus 4.7 is the first one I’ve used where the prompt is no longer a hopeful suggestion to a generous AI. The prompt is now an executable spec. What you write is what you get.

This is a good thing if you are willing to do the writing. It means prompts are now reproducible. The same prompt produces the same output across runs. Your team can review prompts the way they review code. You can version them, diff them, A/B test them, and ship them in CI.

It is a terrible thing if you were getting away with vibes. Because the model is not going to bail you out anymore. Whatever ambiguity you embed in your prompt is going to surface in your output, every single time, and you are going to blame the model.

Opus 4.7 is not your friend. It is a careful executor of your written intent. If your intent is sloppy, the output is sloppy. If your intent is sharp, the output is sharper than anything 4.6 could produce.

The era of vibes-based prompting is ending. The era of prompt engineering as actual engineering is starting. You can resist this transition or you can lead it.

I know which side I’m picking. The migration is uncomfortable for the first three days and then it permanently makes your work better.

Resources

Resource                                       │  What it is                                             │  Link
───────────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────
Anthropic prompting best practices (Opus 4.7)  │  Official docs, updated April                           │  platform.claude.com/docs
System prompt leaks repo                       │  Opus 4.7, Cowork, Mobile, Design extracted             │  github.com/asgeirtj/system_prompts_leaks
600-line prompt migration kit                  │  Four-block templates, XML scaffolds, 43 real rewrites  │  [wowhow.cloud/browse/###]
Anthropic console prompt improver              │  Auto-converts 4.6 prompts to 4.7 patterns              │  platform.claude.com/console
Boris Cherny's rate limit announcement         │  Context on the tokenizer-bump response                 │  x.com (search "@bcherny rate limits")

What I Want To Hear In The Comments

Two specific things, because I am genuinely trying to learn from the people doing this work in production.

First — if you have measured before/after token costs on a real workflow after migrating to the four-block pattern, drop the numbers. I have seen a 22% reduction on my own code review pipeline. I want to know if that’s typical or if I’m an outlier.

Second — what is your single most-called prompt, and what is the laziest line in it? The line that requires the model to infer something you should have stated. We’ve all got one. Mine was “review for quality.” I rewrote it and my output got 40% shorter and 3× more useful.

Drop both in the comments. I read every reply.