Anthropic Deleted 80% of Claude Code's System Prompt. Here's What to Delete From Yours.

Claude Opus 5 just shipped and the benchmark numbers are strong. The one that should reshape how most developers work sits outside the charts: Anthropic removed over 80% of Claude Code's system prompt for Opus 5, and their coding evals didn't move. Four fifths of the guidance came out and the model wrote code at the same quality.

Their explanation is more interesting than the number. In their write-up on context engineering for Claude 5 models, the team says they "were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills." The guidance was fighting itself. One line said to leave documentation as appropriate while another said DO NOT add comments, and the model spent reasoning deciding which instruction won before it could touch a file.

Every constraint I've written into a CLAUDE.md over the last year was built for a model that needed the guardrail. Opus 5 mostly doesn't. Going by Anthropic's own guidance, some of those constraints will now cost me tokens and quality, because they stack on top of behavior the model already has.

So here's my migration plan: what I'll be cutting over the next few weeks, what goes in to replace it, and the two API changes that will break your integration if you skip them.

Where Opus 5 Lands Against Fable 5 and Opus 4.8#

Before any of the prompting changes, you need to know what you're tuning for.

Claude Fable 5 is the ceiling of the lineup. Opus 5's pitch is that it gets close to that ceiling at Opus pricing, which is where the interesting comparisons come from. Against Opus 4.8, the pricing is identical, so the upgrade is a model-ID swap with no budget conversation attached.

Cursor summed up the positioning in one line in the release post: "near Fable 5 intelligence at Opus speed and cost." Aider's take was the same shape, describing it as approaching Fable-level performance at half the cost.

Two other data points from the launch partners are worth more than the benchmark table for anyone running long agentic sessions. QuantumThinking measured Opus 5 solving their tasks with a seventh of the reasoning tokens and under half the latency of Opus 4.8. Lovable reported it as "steadier, with far less variance run to run." Peak capability makes a good chart. Low variance is what decides whether an unattended run finishes clean, and that's the part I care about when a plan doc has eight phases queued up.

Where the model is strongest, in the order it'll matter to most developers:

• Multi-file agentic coding. Larger refactors and end-to-end feature work, finishing tasks rather than leaving stubs and placeholders behind. It performs best when handed the complete specification up front and left alone to run.
• Code review and bug-finding. High precision and high recall in the same pass, and the accuracy holds at lower effort settings.
• Long-horizon work. A 1M token context window as both the default and the maximum, with instruction following and tool calling staying consistent across the whole window.
• Vision and UI replication. Chart, document, and diagram understanding improved enough that prompt-side workarounds you wrote for older models deserve a re-test before you keep carrying them.
• Multi-agent coordination. Writer-verifier patterns hold up, with few cases of agents clobbering each other's work.

Pricing is $5 per million input tokens and $25 per million output, unchanged from Opus 4.8 (accurate as of July 2026, check current rates before you budget against it). Fast mode runs roughly 2.5x quicker at twice the base price.

So the practical picture: Fable 5 stays the pick when you need the absolute ceiling and cost is not a constraint. For everything else, Opus 5 lands close enough to that ceiling that the price gap decides it. Coming from Opus 4.8, there's no tradeoff to weigh at all, which is exactly why the prompting changes below matter. The model got better, and the scaffolding you built for the old one is still sitting in your context window.

Two API Changes Before Any Prompting Talk#

One of these returns a 400, so it goes first.

Thinking is on by default. On Opus 4.8, requests ran without thinking unless you set thinking: {"type": "adaptive"}. On Opus 5 that same request thinks, and the model decides when and how much on each turn. The wire value is unchanged, so thinking: {"type": "adaptive"} still works and means the same thing as the default. What bites is max_tokens: it's a hard cap on total output, thinking plus response text. Any workload that ran thinking-free on 4.8 needs that number revisited before it starts truncating.

Disabling thinking now depends on your effort level. thinking: {"type": "disabled"} is accepted only at effort high or below. Pair it with xhigh or max and every request returns a 400. It's enforced per request, and it's a breaking change from 4.8 where the two settings were independent. If you disable thinking at high effort today, either drop effort to high or below, or keep the effort level and remove the thinking field.

The rest of the platform changes are upside:

• 1M token context window as both the default and the maximum. There's no smaller variant to choose, and instruction following, tool calling, and reasoning stay consistent through the window.
• The full effort ladder including max, with no beta header.
• Prompt cache minimum drops to 512 tokens from 1,024 on Opus 4.8. Short system prompts that couldn't cache before now can, with no code change.
• Mid-conversation tool changes in beta, so you can add or remove tools between turns without throwing away the prompt cache.

The Instructions to Delete Today#

These are the ones going first, ordered by how much I expect them to be costing me.

"Verify your work"#

Opus 5 verifies its own work without being asked. If your system prompt says "include a final verification step for any non-trivial task" or "use a subagent to verify," those lines now stack on top of behavior the model already runs. Anthropic's Opus 5 prompting guide is blunt about it: instructions like these cause over-verification, and removing them cuts wasted tokens with no loss in quality.

Same story for "double-check your answer" and "re-verify before responding." The model catches and fixes its own mistakes well. Telling it to do the thing it already does buys you a second pass you paid for and didn't need.

This is the one I'd have least expected, because verification instructions always felt free. They aren't. On a long agentic run, an extra verify loop per phase adds up to real money, which makes it the first thing I'm measuring once I've cut it.

"Only report high-severity issues"#

This one is a trap specific to code review. Opus 5 finds real bugs at a high rate per pass, and its extra findings are mostly genuine problems rather than false positives. Accuracy holds up at lower effort settings too, so you can run a fast pass at review time and a deeper one later.

But if your review prompt says "be conservative" or "only report high-severity issues," the model takes that literally and reports less than it found. Ask for everything, then filter in a separate pass. You get the model's real recall instead of its guess at where your severity bar sits.

I run a two-model PR review loop precisely because different reviewers surface different classes of bug. Muzzling one of them at the prompt level defeats the point.

Uncapped subagent delegation#

Opus 5 delegates to subagents more readily than earlier models. On genuinely independent tracks of work that's a win, and its writer-verifier coordination holds up with few cases of agents overwriting each other. On small tasks it multiplies cost and wall-clock time for nothing.

If your harness supports subagents, tell it when delegation earns its cost:

Delegate to a subagent only for large tasks that are genuinely
independent and parallelizable, such as a wide multi-file
investigation. Do not delegate work you can finish yourself in a
handful of tool calls, and do not use subagents to verify or
double-check your own work. If one subagent can complete the task,
use one rather than several, and keep spawn counts low.

I wrote about when Agent Teams beat subagents back in February, and that decision framework still holds. What changed is that the model now reaches for delegation on its own, so the cap earns its place in the prompt more than the encouragement does.

Your CLAUDE.md Is Probably Costing You Quality#

Everything in a checked-in CLAUDE.md loads on every single turn. That was always a token cost. On Opus 5 it's also a quality cost, because the file is where most of us stored the constraints the model no longer needs.

Anthropic's guidance is to keep CLAUDE.md lightweight: a brief description of what the repository is, plus the gotchas specific to it. Skip anything Claude can work out by reading files.

Claude Code will do the cut for you. /doctor (aliased as /checkup) starts by deduplicating your local CLAUDE.md against the checked-in one. Then it trims the checked-in file, pulling out anything Claude could derive from the codebase, and moves what survives into skills and nested CLAUDE.md files that load on demand. The split it uses is the useful part:

It reports findings first and asks before changing anything. The CLAUDE.md trim check needs Claude Code v2.1.206 or later.

My own CLAUDE.md fails this test in an obvious way. It carries a full src/ directory tree and a stack rundown, both of which Claude reconstructs in about three tool calls.

Rules Become Judgment#

The clearest before-and-after from Anthropic's post is their commenting instruction. Here's what Claude Code used to carry:

In code: default to writing no comments. Never write
multi-paragraph docstrings or multi-line comment blocks — one short
line max. Don't create planning, decision, or analysis documents
unless the user asks for them — work from conversation context, not
intermediate files.

Here's what replaced it:

Write code that reads like the surrounding code: match its comment
density, naming, and idiom.

One sentence, and it produces better results across more codebases than the rule set did. The rule version fails the moment you point it at a repository whose house style includes docstrings. The judgment version reads the room.

That same swap generalizes. The table below is the shape of the whole shift:

The tool-interface row is the one most teams will sleep on. If you're writing usage examples to teach the model how to call your tool, the better fix is usually a more expressive parameter set. A well-named, well-typed interface teaches the model how to use it without spending context on demonstrations.

The Thing You'll Notice First: It Talks More#

Default responses run longer on Opus 5 than on earlier Opus models, it narrates while it works by announcing each move before making it, and the reports and summaries it writes to disk come out longer as well. All three are the same instinct showing up in different places.

The instinct is to reach for the effort parameter. That doesn't work. Effort controls how much the model thinks, not how much it says, so turning it down cuts thinking volume without reliably shortening the visible response. You have to ask for length explicitly.

For conversational verbosity:

Keep responses focused, brief, and concise. Keep disclaimers and
caveats short, and spend most of the response on the main answer.
When asked to explain something, give a high-level summary unless an
in-depth explanation is specifically requested.

In a long system prompt, repeat a compressed version near the end. Anthropic suggests a small tagged block:

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

For agentic narration, describe the cadence you want rather than banning the behavior:

Before your first tool call, say in one sentence what you're about to
do. While working, give a brief update only when you find something
important or change direction. When you finish, lead with the
outcome: your first sentence should answer "what happened" or "what
did you find," with supporting detail after it for readers who want
it.

Positive examples of the style you want beat instructions about what not to do. That holds in both directions, so the same lever turns narration up if you want a chattier agent.

For written deliverables, one line does most of the work:

Match the length of written documents to what the task needs: cover
the substance, but do not pad with filler sections, redundant
summaries, or boilerplate.

One more flavor of chattiness, and this is the one that bites in user-facing products. Opus 5 narrates corrections to its own earlier statements more than previous models, which reads as flakiness to anyone on the other side of the screen. Scope it to corrections that matter:

Only correct an earlier statement when the error would change the
user's code, conclusions, or decisions. State corrections plainly and
briefly, then continue the task. For slips that change nothing for
the user, make the fix and move on without noting it.

Effort Is the Cost Dial Now#

The effort parameter affects every token in the response: text, thinking, and tool calls. Lower effort means fewer tool calls and terser preamble, which is why it's a better cost control than trying to shorten prompts.

The recommendation for Opus 5 starts in a familiar place and then diverges:

The part to act on: low and medium are meaningfully stronger on Opus 5 than the same settings on earlier Opus models. If you carried effort defaults over from 4.8, those numbers are stale. Run a fresh sweep against your own evals rather than reusing what worked before. The same applies to any prompt-side vision workarounds you tuned for older models, since chart, document, and UI-replication performance moved as well.

Two operational notes that cost people money:

• At xhigh or max, set a large max_tokens. 64k is a reasonable starting point. The model needs room to think and act across tool calls, and max_tokens caps thinking plus text together.
• Hold effort constant inside a cached conversation. Effort shapes the rendered prompt, so changing it between requests throws away your cached prefixes. Vary effort across workloads, not within a session you're relying on cache hits for.

If you're already doing token-aware phase planning, effort slots into that model cleanly: cheap phases run at medium, the phases where correctness is load-bearing run at xhigh.

Don't turn thinking off to save money#

Lower effort is the right lever for cost. Disabling thinking carries two failure modes beyond the 400 error covered earlier.

The model can write a tool call into its user-facing text instead of emitting a structured tool_use block. The turn completes, the call never runs, and in an agentic loop that leaked text stays in conversation history and poisons later turns. It shows up most on tool-heavy workloads like search. If you have to keep thinking disabled, give the model explicit permission to talk before a call: You may say a brief sentence before using a tool.

The second is internal XML tags leaking into visible output. If your system prompt contains a rule telling the model not to think or not to reason, delete it, because that instruction makes the leakage more likely. Use a general instruction instead: Do not include internal or system XML tags in your response. Naming <thinking> tags specifically works worse than the general form.

What Still Earns Its Place in Context#

Deleting is most of the work. A few things went the other way and got more valuable.

Tool interfaces. Context spent on a clearer parameter design pays off on every call. Context spent on usage examples pays off once and then sits there.

Skills with progressive disclosure. A skill's description stays in context so Claude knows the capability exists, while the body loads only when the task calls for it. That's the right home for procedures and reference material that are relevant sometimes. When a skill gets long, split it across multiple files so the model pulls in only the section it needs.

References over descriptions. For specifications, mockups, and prior art, an @ mention of the real thing beats prose about it. Anthropic notes that code references generally work better than descriptions or screenshots, which matches how it's gone for me on earlier models: pointing at a working implementation communicates more than three paragraphs describing one.

Curated team knowledge. Claude Code's auto memory now writes what it learns about a project to a local file and loads it at session start, which covers a real chunk of what people were hand-maintaining in CLAUDE.md. What it doesn't cover is knowledge that needs to be shared and versioned with the codebase. That's why I still run a checked-in knowledge base. A knowledge base survives a laptop swap and onboards the next person.

The distinction between those two is the whole game. Automatic memory replaced the tedious part of maintaining context. It didn't replace the part where a team decides what's worth remembering.

Delete First, Then Measure#

Every context-engineering habit worth having pre-July 2026 assumed a model that needed to be told. Opus 5 changes the default assumption, and the migration is mostly subtraction:

• Pull every "verify," "double-check," and "re-verify" instruction out of your prompts.
• Trim CLAUDE.md to the things Claude can't derive from the repository. Run /doctor and let it propose the cuts.
• Replace rule lists with judgment framing, starting with anything that dictates comment or documentation style.
• Cap subagent spawning explicitly if your harness supports delegation.
• Add explicit length and narration instructions, because effort won't do it for you.
• Re-run your effort sweep from scratch. low and medium are better than the numbers you measured on Opus 4.8.
• Check max_tokens on any workload that ran without thinking, and audit for thinking: disabled paired with xhigh or max before it 400s in production.

The 80% number is the headline, but the useful frame is what Anthropic called unhobbling. Most of us built prompt scaffolding to compensate for model limits that have since moved. That scaffolding doesn't quietly become a no-op. It stays in the context window, competes with the instructions that still matter, and compounds with behavior the model already has.

That list is my plan for the next few weeks rather than a report from the far side of it. I'm starting with this site's repo, where I already know which CLAUDE.md lines carry real information and which ones I wrote out of habit. If the token savings hold without a quality drop, the same pass goes to my plugin repos after.

Open your CLAUDE.md and read it as if you were the model. How much of it would you have worked out on your own?