Your Prompts Were Written for the Last Model: What Changed With Opus 5 and GPT-5.6

Nish · July 24, 2026

⏱️ 15 min read

Anthropic recently deleted more than 80% of Claude Code’s system prompt for its Claude 5 generation of models. Their coding evaluations did not get worse. They did not get better either. Four fifths of the instructions that a frontier lab had built up around its own flagship product turned out to be doing nothing at all. The obvious question is how they were able to cut so much. The more useful question is why the rest of us have not, because the same kind of instruction is still sitting in your CLAUDE.md, in your agent’s system prompt, and in the sentences you type out of habit.

TL;DR: three things changed in the newest models. They reason internally, so you no longer have to ask for it. They follow instructions literally, so old instructions get obeyed rather than ignored. And they have enough judgement to handle situations you used to have to spell out, which also makes them eager rather than lazy. Most of the guidance people wrote to work around the old weaknesses now costs them something. The fix is to go through your context line by line and ask whether each line describes your own situation or the model’s old failings, then delete the second kind.

Table of Contents

What Anthropic deleted

The cut is described in Anthropic’s own writeup on context engineering for the Claude 5 models, and the reason they give is straightforward. “Most recently we found this new class of models want a smaller system prompt,” said Tariq Shihipar, a member of technical staff there. He added that examples “tend to constrain it because it’s actually more imaginative than the examples we give it.” Their internal conclusion was that they had been over-constraining the model, not only through the system prompt but through CLAUDE.md files and skills as well.

There is a pattern in how prompts have changed over the years. Early models needed short prompts with a lot of examples and a lot of rules about what not to do. As models got better at understanding instructions, prompts grew, because longer guidance finally paid off. Now prompts are shrinking again. Most teams are still in the middle phase, adding a line every time something goes wrong. That was the right instinct for about three years, and it stopped being right somewhere in the last one.

The point to hold onto is that an instruction which does nothing is not free. If it contradicts something else in your context, the model has to spend effort working out which one you meant. If it is still being obeyed, it can override a decision the model would now make better on its own. And either way it competes for attention with the instructions that do matter.

What actually changed

Reasoning is a setting now, not a prompt

In 2023, telling a model to “think step by step” genuinely made it better at multi-step problems. By 2025 that behaviour was being trained in directly instead of prompted for, which is the subject of an earlier post on reasoning models: once you can automatically check whether an answer is right, you can train a model to reason rather than asking it to.

In 2026 it is a setting you pass with the request. Anthropic’s effort parameter takes low, medium, high, xhigh or max. OpenAI’s reasoning effort runs from none to max. Both labs arrived at the same control within months of each other. On Claude Opus 5, thinking is on by default and the model decides how much of it to do.

So asking for step-by-step reasoning in the prompt is redundant at best. There is some evidence it is worse than redundant. One study tested 15 models on two instruction-following benchmarks and found that adding explicit chain-of-thought prompting made them follow instructions less accurately, apparently because the reasoning pulled attention away from the constraints they had been given.1

The models take instructions literally

Older models were loose about instructions. That is why so many prompt files ended up full of capital letters and the word ALWAYS: you had to shout to be heard. Newer models simply do what you tell them.

Anthropic’s guide for Opus 5 gives a clear example. If your code review prompt says “only report high-severity issues” or “be conservative”, the model takes you at your word and reports less. Their recommendation is to ask it to report everything and filter in a second pass. The general lesson is that an out-of-date instruction used to be harmless noise. Now it is a command that gets carried out.

There is still a limit to how many instructions a model can hold at once, and the shape of that limit is worth knowing. IFScale is a benchmark that gives a model somewhere between 10 and 500 instructions at the same time on a writing task. At 500, the best frontier models follow about 68% of them, and they show a measurable bias towards instructions that appeared earlier in the prompt. Your context file is not a list of things the model will definitely do. It is a set of requests competing for a limited amount of attention, and where each one sits in the file affects whether it wins.

They use judgement, and they try harder than you asked

Opus 5 checks its own work without being asked. Anthropic’s guidance is therefore to remove any verification instructions you carried over from an earlier model, because they make the model check things repeatedly without producing better results. Tools that used to get ignored now get used at roughly the right rate, so a line like “if in doubt, use the search tool” has turned from a safeguard into a cause of unnecessary tool calls. Prefilling the start of the model’s reply, once a standard way of forcing a particular output format, was withdrawn from the Claude API from version 4.6 onwards, on the grounds that instruction-following had improved enough that most people no longer needed it.

OpenAI says much the same about GPT-5.6, which shipped in July 2026: the model “can better infer the user’s underlying goal and intended level of work from context, so you often do not need to prescribe every step.” Its migration notes carry a smaller version of the same warning. GPT-5.6 is more concise by default than GPT-5.5 was, so a blanket “be concise” sitting in your system prompt may now be doing nothing at all, or trimming answers that needed the room. Nobody edited that line. The model underneath it changed, and so did its effect.

The common failure mode has also flipped, and this is the part that catches people out. In 2024 the complaint was laziness: stub functions, placeholder comments, work left half finished. In 2026 it is the opposite. Opus 5 widens the scope of tasks beyond what was asked, narrates what it is doing more than most people want, writes longer documents than needed, and hands work to subagents more readily. GPT-5.6 is described as more proactive, and its guidance asks you to spell out what each request does and does not authorise it to do.

The instructions people wrote to stop models being lazy therefore push the new ones further in a direction they are already going too far in. Anthropic’s own migration checklist has a bullet called “tune anti-laziness prompting” for exactly this reason. That is the whole problem in miniature. The fix outlived the flaw it was written for and became a flaw of its own.

What old instructions cost you

Those three costs are worth keeping apart, because only the last one is about wasted tokens.

They contradict each other. When the Claude Code team read transcripts of their own internal usage, they found conflicting instructions inside single requests: “leave documentation as appropriate” in one place and “DO NOT add comments” in another, as the system prompt, the skills and the user’s message pulled in different directions. The model can usually work out what you probably meant, but it has to spend reasoning to do it, and one of the two instructions still has to lose. Saying nothing is safer than saying two things. When you say nothing, the model uses its judgement. When you say two contradictory things, you have no control over which one wins.

They override good judgement. A rule written for the worst case still applies in the 95% of cases that are not the worst case. “Never write comments” existed because older models wrote bad ones, and it was a sensible trade when their judgement could not be trusted. The line Anthropic replaced it with is revealing: write code that reads like the surrounding code, matching its comment density, naming and idiom. That is not a softer rule. It describes the situation and hands the decision back to the model.

They crowd out the instructions that matter. Context windows have grown enormously, but attention has not grown with them. Chroma’s context-rot research found that reliability drops at every step up in input length across 18 models, not only near the advertised limit. Anthropic says Opus 5 follows instructions, calls tools and reasons consistently across its full million-token window, which would be a real change if it holds, but it is a vendor’s claim about its own model and independent long-context research has not caught up to this generation. Either way, the ordering effect from IFScale still applies: the rule you care about is competing with everything stacked above it.

The only published figure on what tidying up is worth comes from OpenAI. Its guidance for GPT-5.6 reports internal testing where leaner system prompts scored roughly 10 to 15% better on their evaluations while using 41 to 66% fewer tokens.2

Why nobody updates their instructions

Products move to a new model far faster than they rewrite the instructions around it. The reasons are structural rather than a matter of anyone being lazy.

  • Changing the model is easy; changing the context is not. Swapping models is a one-line change and a conversation about cost. Auditing the context means working through a system prompt, a set of skills, a CLAUDE.md, and whatever the user types out of habit.
  • Instruction files only ever grow. Nothing removes lines. Each one was added after something went wrong, so each one has someone who will defend it, and deleting it feels like inviting the old bug back.
  • Your tests were written for the old failure. A regression suite that checks the model does not do the banned thing cannot show you what the ban costs elsewhere. Over-constraining a model never fails a test. It just quietly returns a slightly worse answer.
  • The people who own the instructions do not see the damage. In a product, the system prompt belongs to a platform team. The worse output reaches users, who reasonably conclude the model is bad at their task.
  • Your habits are part of the context too. The persona you open with and the three examples you always paste are scaffolding you carry from one product to the next, and they live in no file that anyone can review.

Rule of thumb: the model changes when someone edits one line of config. Your context only changes when someone sits down and reads it. Those two things happen at very different rates.

How to audit your own context

Every line in your context makes a claim about something, and the useful question is what it makes a claim about.

Some lines describe your situation: how your codebase is laid out, what your team’s conventions are, how much risk you can take, who your users are, what counts as finished, and what needs approval before it happens. The model has no way of knowing any of this, and no new release will change that.

Other lines describe the model: it forgets to check its work, it will not use tools unless pushed, it is lazy, it needs an example before it gets the format right. Each of those is a bet that a particular weakness will still be there, and every release is a chance to lose that bet.

The two kinds have very different lifespans, which is the practical reason for sorting them.

Two panels sorting lines of agent context. The left panel, labelled model-facing, holds instructions like think step by step and double-check your work, each annotated with why it is now dead weight, under a footer reading half-life about one model release. The right panel, labelled world-facing, holds project-specific lines such as a definition of done, who the users are, a data hazard, and an authorisation boundary, under a footer reading half-life as long as the system it describes.
Sorting context by what each line describes. The half-life labels are a rough framing rather than a measurement, but the asymmetry is the point: one half of your context gets absorbed by each model release, and the other half is only ever written by you.

There is a second question worth applying to every line: would a competent new colleague with access to this repository need to be told this? If not, cut it. Whatever survives belongs in one of four places.

  1. Delete it. Personas for reasoning tasks, “think step by step”, “double-check your answer”, “if in doubt use the tool”, anything written to stop the model being lazy, and lists of prohibitions aimed at behaviours it no longer has.
  2. Turn it into a setting. Anything about how hard to think, how long the answer should be, or how much to spend is now a parameter: effort levels, verbosity settings, and structured outputs instead of asking nicely for valid JSON. Re-run an effort sweep rather than reusing the level you picked for the last model, because low and medium on Opus 5 buy more than those labels used to. OpenAI’s advice for the same move is to keep your current effort level as the baseline and then test one level below it.
  3. Move it somewhere the model can fetch it. Guidance that matters occasionally should load when it matters, rather than on every request. Anthropic moved code review and verification out of Claude Code’s system prompt and into skills the model calls when they are relevant. Your long “how we do X” sections can go the same way.
  4. Keep it, and prefer showing to describing. A failing test, a rubric, a mockup, or an existing function to copy carries far more information than a paragraph describing any of them, because it is a specification written in a language the model reads precisely.

Here is what the exercise looks like on an ordinary instruction file:

  # CLAUDE.md
- You are an expert senior Python engineer with 15 years of experience.
- Think step by step before writing any code.
- ALWAYS read the entire file before editing it.
- If you are unsure about anything, use the search tool.
- Before finishing, double-check your work and verify it is correct.
- Never write comments.
- Write documentation where appropriate.
+ Django billing service. Postgres, Celery, pytest.
+
+ Done = `pytest -q` exits 0 and `ruff check .` is clean.
+
+ Gotchas the file tree won't tell you:
+ - Every model class lives in `billing/models.py`. Don't add new model modules.
+ - `staging.db` is shared with the data team. Never reset or re-migrate it.
+ - Money is `Decimal`, never float, including in tests.
+
+ Changes under `billing/payments/` need a human reviewer before merge.
+ Ask before touching migrations or anything that sends email.

Seven lines out, eleven in. The file got longer, not shorter, and it changed subject completely. Everything removed was a statement about the model, and everything added is a statement about the billing service. The two deleted lines about comments had also been contradicting each other for as long as the file existed, which is the kind of thing nobody notices. This is the usual outcome, and it is why “shorten your prompt” is bad advice on its own. Most context files say too much about the model and not nearly enough about the project.

Three things this does not mean

It does not mean examples are useless. Anthropic’s general prompting guidance still recommends three to five examples wrapped in <example> tags. The narrower claim is the accurate one: examples showing the model how to approach a problem box it into your way of thinking, while examples showing what the output should look like still work well for format, tone and structure. Sort yours into those two piles before deleting anything.

It does not mean stop verifying. Delete the sentence telling the model to check itself, but keep the test that tells you both whether the work is right. Earlier posts on working with coding agents and goals and loops argued that giving an agent a check it can run is the highest-leverage thing you control. A model that checks itself confidently and widens the scope of tasks on its own needs an external stop condition more than a timid one did, not less.

It does not mean the evidence is settled. Anthropic’s 80% and OpenAI’s 10 to 15% are both internal results, on evaluations nobody outside can see, for their own products. The independent research supports the mechanism but was run on older models. Believe the direction, then measure the size of the effect on your own work. In practice that means running an effort sweep and comparing your trimmed prompt against the original on cases you actually care about.

This advice will expire too

Everything specific in this post is a claim about two families of models in the middle of 2026, and it will date exactly as badly as the guidance it is telling you to delete. The part worth keeping is not the list. It is the habit of asking, every time a model ships, which of your sentences were written for the model it replaced.

Anthropic could cut four fifths of Claude Code’s system prompt because they read their own transcripts and had evaluations good enough to prove the cut was safe. That is the real work, and it is not glamorous. Everyone else’s four fifths is still sitting there, instructing a model that no longer needs it, in a voice that model now takes literally.

Sources & further reading

  1. Li et al., 2025. The models they tested came before this generation, so treat it as evidence about why the effect happens rather than a measurement of Opus 5. The effect was uneven: reasoning helped with formatting and word choice, and hurt by causing the model to overlook simple constraints. 

  2. This is internal testing on evaluations OpenAI has not published, for its own model, so nobody outside can check the exact size of the effect. The direction matches Anthropic finding no measurable loss after cutting 80%, which is a different experiment pointing the same way. 

Citation Information

If you find this content useful, please cite this work as:

Bhana, Nish. "Your Prompts Were Written for the Last Model: What Changed With Opus 5 and GPT-5.6". Nish Blog (July 2026). https://www.nishbhana.com/Written-For-The-Last-Model/

Or use the BibTeX citation:

@article{bhana2026writtenfor,
  title   = {Your Prompts Were Written for the Last Model: What Changed With Opus 5 and GPT-5.6},
  author  = {Bhana, Nish},
  journal = {nishbhana.com},
  year    = {2026},
  month   = {July},
  url     = {https://www.nishbhana.com/Written-For-The-Last-Model/}
}

x.com, Facebook