Why old prompts can break after a model upgrade

A model being more obedient doesn’t mean your old instructions will get the same results.

I used to think that after a model upgrade, the same prompt could only work better.

But when Anthropic released Claude Opus 4.7, it specifically flagged something very counterintuitive:

because the new model follows instructions more strictly and more literally, prompts written for earlier models can sometimes produce unexpected results.

With Opus 4.8, this behavior carries on. It executes prompts more precisely, doesn’t automatically extend a requirement aimed at one part to other parts, and doesn’t proactively fill in needs the user didn’t state.

What does that actually mean?

Say you have a code review prompt:

Review this code. Only report high-severity issues. Be conservative in your judgments; don’t nitpick.

The model finds two problems:

• one that could cause users to be charged twice;
• another that would make a few edge-case states display incorrectly.

An earlier model might have read “only report high-severity issues” loosely and told you about both.

A model that follows instructions more strictly may also find both problems but output only the first, because it judges that the second doesn’t meet the severity you specified.

What the user sees, though, is:

why did the new model find one fewer problem?

Its capability hasn’t necessarily dropped. It may just have executed the filter in the old prompt more conscientiously.

Some old prompts that did well in the past may have depended partly on the model not fully doing as it was told.

Why should models become more literal?

Because “guessing for the user” isn’t always a good thing.

For example, you write only under the first section:

use three bullet points under each heading.

An older model might decide on its own that the whole document should be formatted this way.

In chat, that might seem very understanding. But in an API, structured extraction or an automated pipeline, it can become overstepping the scope of the instruction without permission.

Today’s models lean more toward executing only what you’ve explicitly written. If you want it to apply to the whole document, you need to say so:

this rule applies to all sections.

The benefit Anthropic gives is that this is more precise, needs less back and forth, and suits automated pipelines that need stable, predictable results better.

In other words, models used to fill in your meaning for you; now they’d rather you state the scope clearly.

Old prompts may also hide “scaffolding”

By scaffolding I mean an extra set of working rules, beyond the task itself, added to make up for the model’s past weaknesses.

For example, the real task is just fixing a bug, but the project instructions also say:

Make a plan before starting. Report progress after every three tool calls. Summarize after completing each phase. Stop and ask whenever anything is uncertain.

These rules aren’t necessarily wrong.

But some of them may have been added gradually because older models didn’t report proactively and tended to skip steps.

Opus 4.7 and 4.8 proactively give progress updates more regularly during longer agent tasks. So Anthropic suggests that if your workflow has a mechanism like “must report every three tool calls,” try removing it first.

The reason isn’t that serious either: with two reporting systems layered together, you may just get duplicated information and more mechanical updates, taking up extra context and cost.

If the default reporting doesn’t work for you, then tell the model explicitly at which points you want it to report, and what.

The point isn’t that all old rules should be deleted, but:

what was this rule compensating for originally? Can the model now do it on its own?

Sometimes it isn’t the prompt that needs adjusting

Since Opus 4.7, Anthropic has also stressed an important variable: effort.

The same model can run at different effort levels. Higher effort usually means the model puts in more reasoning and tool calls, but is slower and costs more. Anthropic considers adjusting effort within the same model often more appropriate than switching models outright; for most coding and agentic tasks, the official recommendation is xhigh.

So when answers to complex tasks are too shallow, you don’t necessarily need to keep adding to the prompt:

Think deeply. Analyze comprehensively. Don’t miss any possibility.

You can check effort first.

When there are too few tool calls, you may also need to raise effort, or state explicitly when tools must be used.

This also means that when results change, you can’t only blame the prompt.

It may be that the model changed, or that effort, tool-calling habits or default behavior changed.

What do users need to do?

There’s no need to tear down and rewrite all your prompts because of a model upgrade.

For one-off chats where the results are fine, just keep going.

What’s really worth trying again:

• prompts you use repeatedly over the long term;
• Skills;
• project rules for agents like Claude Code;
• automated workflows already wired into real work.

After switching models, run one or two tasks you really use. Focus on a few obvious changes:

• whether content it used to cover is now missing;
• whether constraints are being enforced more strictly;
• whether tone and length have changed noticeably;
• whether tool calls and progress updates still fit your needs;
• whether the current effort suits the task.

Fix whatever has really changed.

If the scope is unclear, spell it out; if the filter is too strict, adjust the selection criteria; if progress reports are duplicated, try removing the old scaffolding; if reasoning is too shallow, check effort; if the model itself doesn’t suit the task, then consider switching models.

After changing models, it’s best to rerun your important old prompts.

This post is about how, when the model changes, old prompts may need re-adapting.

But there’s another situation — the model hasn’t changed, yet prompts and Skills can slowly get worse as you keep adding rules to them.