Opus 5 is excellent, but its behavior is different from before, making it tricky to handle.
However, this isn't a problem with the model itself. The cause is that the request methods and settings that were correct for previous models are still being used.
Anthropic has officially released a prompt guide specifically for Opus 5.
It states that instructions previously considered "correct" are now counterproductive.
If you continue using it without knowing this, you'll keep paying more tokens for the same tasks than before.
Does this sound familiar?
- Responses are so long they are exhausting to read
- Live commentary during tasks is too detailed
- It expands the scope of work to areas you didn't ask for
- It launches multiple sub-agents, causing costs to skyrocket
- Documents it writes are unnecessarily long every time
If even one of these applies to you, this article will be helpful.
These are all behaviors that the official guide says "can be fixed with these instructions."
In this article, I will introduce 11 changes and solutions mentioned by the official guide in an easy-to-understand way.
At the end, I've summarized the points to watch out for starting today, so please bookmark it and make full use of it.
As a quick promotion, I am currently giving away 55 major benefits for free, including a Claude Code textbook, installation methods, and monetization strategies. You can receive them immediately from the link below, so if you haven't yet, please do so.
↓
https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet
Now, let's get to the main topic.
**
What was released?
A prompt page specifically for Opus 5 has been added to Anthropic's official documentation.
It's not just a feature list. It's a practical page focused on "Opus 5 is different from previous models in these ways, so instruct it like this." Only performance improvements related to prompting are listed.
As a premise, the official guide states that prompts written for Opus 4.8 will still work reasonably well. However, there are certain behaviors that tend to require tuning.
In other words, it works, so you don't notice. Continuing to pay for waste without noticing is the most disadvantageous pattern.
1. Responses are long. Lowering effort doesn't reduce the amount of talking
Opus 5's responses are longer than previous models. This is officially acknowledged.
The tricky part is that lowering the "effort" (thinking capacity) doesn't guaranteed a reduction in the amount of talking. The official guide explicitly states, "Effort controls the amount of thinking, not the amount of talking."
If you want to cut the length, you have to explicitly instruct the length. Here is the instruction provided by the official guide:
1Keep responses short and to the point.2Minimize prefaces and disclaimers, and use the character count for the answer itself.3When I ask for an explanation, only return a summary of key points unless I say I want to know more in detail.
For those with long CLAUDE.md or system prompts, write this and then place a short reminder at the end. The official guide also recommends this method.
1<tone_preference>2Keep output concise.3</tone_preference>
Instructions buried in the middle of a long instruction set are less effective. A reminder at the end compensates for that.
For those who don't use settings, it's even easier. Just reply "Keep it short" on the spot when you feel it's too long.
2. Too much live commentary during tasks
Opus 5 talks a lot while working. It tends to declare what it's about to do every time, and the output per message is longer than previous models.
The way to reduce this isn't to say "don't give live commentary." You write when and in what form you want reports.
1Before starting work, say only one sentence about what you are going to do.2Only report during work when you find something important or when you change direction.3When finished, write the conclusion first. Answer "what you did" and "what you found" in the first sentence, and leave the details for later.
Conversely, those who want to increase live commentary can use the same method. The official guide states, "Showing examples of the desired format is more effective than prohibiting what you don't want."
3. Documents written are always long
Aside from conversation length, things written to files (reports, md documents, summaries) also tend to be long.
This is effective for people who have AI save research results in markdown. Just adding one line for the length standard makes a difference.
1Keep documents written to files within the necessary length.2Don't omit content, but don't make it long with chapters just to fill space, repeated summaries of the same content, or standard prefaces.
4. "Always verify" and "Double-check" are unnecessary
This is the biggest point.
To be clear, if you have nothing written in your settings, you can leave it as is. This item is about "deleting it if it's written" and "not saying it in individual instructions."
Opus 5 verifies its own work even if not told. Therefore, the official guide says to delete instructions that command verification if they are in your prompt. These types are specifically named:
- "Always include a verification step at the end for non-trivial tasks"
- "Use a sub-agent to verify"
- "Double-check before answering"
These overlap with Opus 5's built-in verification and cause over-verification. The official description says, "Deleting these reduces wasted tokens without dropping quality." It's not a trade-off with quality; it just eliminates waste.
The same applies if a mechanism to add verification steps to old harnesses remains.
On the other hand, Opus 5 has more live commentary for corrections than previous models. If "I'm correcting my previous statement" appearing frequently is a nuisance, add instructions to narrow it down rather than deleting it.
1Only correct what you said previously when that mistake would change my code or judgment.2State the correction briefly and continue working.3For minor typos that change nothing, fix them silently and proceed.
**
5. Expanding scope without being asked
Opus 5 may expand the scope of work based on its own judgment. It adds steps you didn't ask for. It re-decides what should be done.
For tasks where you want to keep the scope narrow, explicitly bind the scope.
1Do what I asked, within the scope I asked.2Make minor judgments yourself. Only check in with me when the result would change significantly depending on the interpretation.3If my request seems wrong or if there is a better way, point it out in one sentence and then proceed as requested.4Do not narrow, expand, or change the scope to something else on your own.5Complete the requested scope to the end. Do not do things I clearly did not ask for.
Including this reduces accidents where "fix one file" turns into changing the entire project.
6. Creating too many sub-agents
Opus 5 delegates to sub-agents more readily than previous models.
Delegation itself isn't bad. The official guide says it's effective for truly independent, large tasks. The format of separating the writer and the verifier also works, and it's evaluated that accidents where agents overwrite each other's work are rare.
The problem is when it's used for small tasks. The cost and time for the number of units are added directly.
1Only delegate to sub-agents for large, independent tasks that can be done in parallel (e.g., researching multiple files across a wide range).2Do not delegate tasks that you can finish yourself in a few steps.
There's a trick even for people who don't write settings. Tell it the number of units yourself when asking. Put "Do it yourself without using sub-agents" or "If you use them, up to X units" in the first message.
7. Writing "only tell me major issues" in reviews increases the risk of missing things
Opus 5 is strong at code reviews. The official guide says it has a high rate of finding real bugs in one go, and additional points it raises are more often real than false positives. Since accuracy doesn't drop easily even with low effort, you can use it for a light review once and a thorough review later.
However, there is a pitfall. If you write "only report major problems" or "be conservative" in the review prompt, Opus 5 may follow that instruction literally and reduce reporting.
The official recommendation is to "have it report everything and filter in a separate step." Let it out, then discard. Not letting it out from the start is a loss.
The way to ask is like this: "List everything you're concerned about. Rank them by importance." You decide which ones to fix after seeing the list.
8. Use low and medium as the main effort levels
In Claude Code, you can switch the amount of thinking with "/effort". There are 5 levels available in Opus 5: low, medium, high, xhigh, and max, with high being the default. Only max is limited to that session; the other four are carried over to the next session.
The official recommendation is this: Start with high, and actively use low and medium where quality doesn't drop to use as the main control for cost and wait time. Only raise to xhigh for heavy coding or agent tasks.
For side-hustlers, this is relevant because if you don't touch this, you'll keep paying for high thinking capacity even for light tasks. You don't need high for finding files or simple text generation.
The official guide also says that if you're carrying over settings from the previous model era, you should re-measure with your own tasks.
There's one thing to do today. Type "/effort medium" before starting a light task. Only return to "/effort high" when entering heavy implementation. This alone will change wait times and consumption.
**
9. Provide all specs at the beginning and leave it alone
From here on, it's about how you should change the way you ask because performance has improved.
The official guide positions Opus 5 as "strongest at difficult coding." Listed areas of expertise include adding features across multiple files, large refactoring, and finishing features completely. It's also explicitly stated that it doesn't run away by placing stubs or "this is for later" placeholders.
The important part is how to give instructions. The official way is this: Performance is best when you give all the task specs at the beginning and then let it run.
Adding instructions bit by bit is a loss in Opus 5. It's faster to write out all conditions before asking.
These four things are enough to put in the first message: files it's allowed to touch, how far to go, promises you want it to keep, and conditions to judge that it's finished. Adding conditions after it starts running is the slowest.
It can be used normally for light tasks like a one-line fix, but the official guide says the difference from previous models shows in heavy tasks.
10. Homemade workarounds for images are unnecessary
Reading charts, documents, and diagrams, as well as reproducing the look of UI and front-ends, has become stronger.
What the official guide specifically mentions is to review image-related workarounds built into the prompt for previous models. They may no longer be necessary.
There's one more thing. Accuracy with images is highest when you give it tools to let the model itself perform cropping or visual confirmation. It's explicitly stated that giving it tools is more cost-effective than raising the effort level.
If using it in Claude Code, stop the format of pasting an image and asking for impressions. Give it the location of the image file and let it open, enlarge, and check it itself while fixing. You should do this before raising the effort level.
11. Pass styles for spreadsheets and slides
It can now create spreadsheets across multiple sheets, including non-simple formulas. Slides also come out with a well-organized structure.
The official instruction here is just one: If there's a style or template you want it to follow, put it in the prompt.
For people who fix the look of the created materials every time, it's faster to increase the information you provide before increasing the fixing work.
The quickest way is to provide one document you made yourself before and say, "Match this format." It's faster to show one real example than to explain colors and fonts in words.
Summary
- Response and document length do not decrease with effort level. Instruct length explicitly.
- Delete instructions commanding verification or double-checking. Opus 5 does it without being told.
- It's better to write scope constraints and sub-agent delegation conditions.
- For reviews, "let it output everything and filter later." Don't let it filter from the start.
- Use low and medium as the main effort levels.
- Don't give specs bit by bit; give them all at the beginning and leave it alone. The heavier the task, the bigger the difference.
When the model changes, the "correct" way to ask also becomes old.
Tips you learned last year might just be increasing wait times and costs now.
I hope you'll bookmark and try even just one thing today.
I usually post about the latest AI information and monetization methods using AI. If this article was helpful, please follow me.
Finally,
I am currently giving away 55 major benefits, including a Claude Code textbook, installation methods, and monetization strategies. If you haven't yet, please receive them here.
https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet
Reference page
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
