Claude Opus 5.5 is out, and most people are using it the same way they used Opus 5. That leaves a lot on the table.
Anthropic's own guide, Getting the most out of Opus 5.5 (22 September 2026), lists what changed. It's a good read, but it's written mostly with developers in mind. This post takes the same advice and turns it into something you can use today, whoever you are:
- Everyday Claude users - the web, desktop and mobile apps.
- Business teams - shared projects, standard prompts, and what to hand over first.
- Claude Code users - a copy-paste
CLAUDE.md, subagents, reviews and fast mode.
The short version: tell Opus 5.5 what "done" looks like and let it work. Stop telling it to "think hard" - if you want more thinking, raise the effort level instead. And when a long task finishes, read what it needs from you before anything else.
What Changed in Opus 5.5 (and Why Your Old Habits Don't Fit)#
Three changes drive almost every tip below. Understanding the why makes the tips easy to remember.
| What changed | What it means for you |
|---|---|
| It always thinks before replying, and decides how much on its own | "Think step by step" is now noise. Removing it makes replies start sooner, with no drop in quality. The effort level is now the dial for how hard it thinks - and its default dropped from high to medium. |
| It keeps going on long, multi-part work better than Opus 5 | Hand over the whole job, not one step at a time. But be clear about when it should stop. |
| It pays more attention to detail - in documents, charts and screenshots | Give it the real file or image, and ask it to check things, not just write things. |
There's a fourth change that trips people up: Opus 5.5 is the first Opus model to launch with stricter safeguards around biology and cybersecurity. Occasionally a normal message gets flagged and your chat quietly moves to an older model. We cover how to spot and fix that further down.
The Three Habits That Matter Most#
If you only change three things, change these. They apply everywhere - apps, teams and Claude Code.
1. Define the finish line#
Old habit: ask for step one, check it, ask for step two. With Opus 5.5 that wastes its main strength. Instead, give it three things in one message:
- The whole task.
- What "done" looks like - something you could check.
- When to stop and ask you.
Compare:
❌ "Can you help me with the Q3 supplier review?"
✅ "Compare the three supplier quotes attached. Done means: one table with price, delivery time, payment terms and contract length for each, plus a one-paragraph recommendation. Stop and ask me only if a quote is missing something you need."
The second prompt tells Claude where the finish line is. Without one, it has to guess when to stop - and it guesses short.
2. Delete "think carefully"#
Opus 5.5 thinks before every reply and chooses how much. Lines like "think carefully", "think step by step" or "take a deep breath" no longer help. Anthropic's testing found that removing them made replies start sooner with no loss of quality.
Check the places those lines hide: saved project instructions, custom styles, team prompt libraries, and CLAUDE.md files. If you want a quick answer, say "Answer directly." If you want more thinking, don't ask for it in words - turn up the effort level, explained next.
3. Read "what it needs from you" first#
Opus 5.5 writes clearer summaries after long tasks. When one finishes, don't read top to bottom. Find the part where Claude says what it's waiting on you for - a decision, a login, a missing file - and deal with that first. Everything else can wait.
Effort Levels Explained: Low, Medium, High, Xhigh, Max#
Opus 5.5 always thinks before it answers. Effort is the dial for how much. It's the single most useful setting to understand, because it changes quality, speed and cost all at once.
A good way to picture it: effort is how long a colleague spends on something before replying. A quick Slack message gets a quick answer. A board report gets a morning. Neither is "better" - it depends on the job.
The same question at every level#
Ask Claude something simple: "Is the sky blue?" Here's roughly how the levels behave (an illustration, not real transcripts):
| Effort | What it does | Typical answer |
|---|---|---|
| Low | Barely thinks. Answers straight away. | "Yes." |
| Medium | Thinks briefly, adds useful nuance. | "Yes, on a clear day - sunlight scatters off air molecules, and blue light scatters most." |
| High | Checks edge cases before answering. | The above, plus sunsets, overcast skies, and why it isn't violet. |
| Xhigh | Reasons in depth. | A short explainer on light scattering and how our eyes see colour. |
| Max | Thinks as long as it needs. | Can overthink a simple question - slower, more expensive, not more useful. |
For "is the sky blue?", low is plenty. For "why did our Q3 margin fall?", low would give you a shallow answer. Match the effort to the problem, not to how important the task feels.
Which level to use#
| Level | Use it for | Everyday example | Claude Code example |
|---|---|---|---|
| Low | Quick exchanges where you check each reply | Rewording an email, quick facts, brainstorming names | Renaming a variable, a first sketch |
| Medium (default) | Most day-to-day work with a clear scope | Summarising a report, drafting a proposal | Building a new feature |
| High | Work where edge cases and checking matter | Reviewing a contract against your template | Fixing a bug in an existing codebase |
| Xhigh | Deeper reasoning, at higher cost | Untangling a messy financial model | A tricky refactor across many files |
| Max | Hard problems you want solved without you | Rare - most business tasks don't need it | Hunting for security vulnerabilities |
Four things worth knowing:
- Medium on Opus 5.5 is not medium on Opus 5. Anthropic says Opus 5.5 at medium matches or beats Opus 5 at high on coding and knowledge work. So the lower default isn't a downgrade - start at medium and only go up if the results show you need to.
- Higher effort uses your limits faster. More thinking means more tokens. On a Claude plan, you'll hit usage limits sooner; on the API, you pay more.
- Want less thinking? Lower the effort - don't ask in words. Turning the dial down cuts thinking, cost and waiting time more reliably than "be quick" in a prompt.
- Max isn't "best". Anthropic's own docs warn it can show diminishing returns and is prone to overthinking. Save it for genuinely hard problems.
Where to change it#
| Where | How |
|---|---|
| Claude apps (web, desktop, mobile) | Click the model name next to the send button, then choose Effort. Thinking itself can't be switched off on Opus 5.5. |
| Claude Code | Type /effort for a slider, or /effort high to set it directly. You can also use the arrow keys in the /model picker, or start with claude --effort high. |
| Claude Code, one turn only | Put ultrathink anywhere in a prompt to get deeper reasoning on that turn, without changing your setting. |
| Claude Code, saved | Add "effortLevel": "high" to your settings file, or effort: low in a skill's or subagent's frontmatter. |
| Claude API (developers) | Set output_config: { effort: "high" } on the request. The API default on Opus 5.5 is also medium. |
Don't confuse effort with fast mode. Low effort makes Claude think less. Fast mode keeps the same thinking but delivers the answer faster, at a higher price. One changes the work; the other changes the delivery speed.
Part 1: Using Opus 5.5 in the Claude Apps#
This is for anyone using Claude on the web, desktop or phone.
First, check the model. Open the model picker and make sure it says Opus 5.5. Old chats and some projects may still be on an earlier model. While you're there, check the Effort setting - medium suits most chats; go to high for analysis you'll act on.
Send the screenshot, not a description of it#
Opus 5.5 reads charts, diagrams and screenshots more accurately than Opus 5. Retyping numbers from a chart adds mistakes. Attach the image and ask one specific question:
"Here's our sales dashboard. Which region fell furthest from its target last month, and by how much?"
This works for error messages, spreadsheet screenshots, whiteboard photos and org charts too.
Ask it to check, not just write#
Its attention to detail makes Opus 5.5 a good proofreader for long documents. In testing, it caught dates on the wrong weekday and numbers in the text that didn't match the chart. Try:
"Check this report for anything that contradicts itself: numbers, dates and names. Quote each problem and say where it is."
Run this on board packs, proposals, tender responses and pitch decks before they go out. It's one of the cheapest checks you can do.
Ask for the finished file#
You don't need an outline first. Opus 5.5's spreadsheets and documents need less editing than Opus 5's, so ask for the real thing:
"Make this a spreadsheet I can share: one row per vendor, with columns for cost, contract end date and owner."
Tell it to stop revisiting old answers#
In a long chat, Opus 5.5 sometimes goes back over an earlier answer when you ask a small follow-up. If that happens, add this to your project instructions:
Once you have answered something, treat that answer as done. Focus on
what I'm asking now, and don't go back over an earlier answer unless I
ask about it or point out a problem with it.
When not to use it: long analysis where a later step might show an earlier one was wrong. There, you want Claude to go back.
Designing something? List what you don't want#
With no design direction, Opus 5.5 falls back on a handful of default styles. Rather than saying "make it modern", list what to avoid:
"Build a landing page for our bakery. Don't use a cream background, italic words in headings, numbered '01 / 02' section labels or pill-shaped buttons."
Look at the result, add anything you dislike to the list, and ask again. After two or three rounds you'll have an exclusion list worth saving.
Part 2: Rolling Opus 5.5 Out Across a Business#
Individual tips help one person. The real gains come when a team shares the same setup. Here's how we'd approach it.
Put the rules in a shared project, not in people's heads#
A Claude project with good instructions is the easiest way to get consistent results across a team. A solid starting point:
You're helping the [team name] team at [company].
- When you finish a task, start with what you need from me, then what
you did, then anything surprising you found.
- Mark anything you couldn't confirm, and say where you looked.
- Use UK English and our house style: [short list].
- Once you've answered something, treat it as done unless I ask again.
Notice what's not in there: no "think carefully", no "you are an expert". Opus 5.5 doesn't need them.
Build a small prompt library around "done"#
Most teams have five to ten tasks they repeat every week. Write one prompt per task, each with a clear finish line, and keep them in one shared place. For example:
| Task | Finish line to include |
|---|---|
| Weekly sales summary | "One page: top three wins, top three risks, numbers checked against the attached sheet." |
| Supplier comparison | "One table, one row per supplier, plus a recommendation in under 100 words." |
| Policy or contract check | "List every clause that differs from our template, quoted, with the section number." |
| Customer complaint reply | "A reply under 150 words, plus a note of anything I need to approve first." |
| Board pack review | "Every contradiction in numbers, dates and names, quoted, with page number." |
Make it say what it couldn't verify#
For research, market analysis or anything that ends up in front of a client, add one line:
"Mark anything you couldn't confirm, and say where you looked."
This is the single best guard against confident-sounding mistakes. It turns "the answer" into "the answer, plus a list of what to double-check" - which is what a manager actually needs.
What to hand over first#
Start with tasks where a mistake is easy to spot and cheap to fix:
- Consistency checks on long documents - high value, low risk.
- Turning messy notes into finished spreadsheets - fast to check against the source.
- Reading screenshots and charts into summaries.
- First drafts of reports and proposals, with a human edit.
Leave anything that sends, pays, deletes or signs until you've built trust - and even then, keep a person approving the final step.
Agree on effort levels#
Left alone, people either never touch the effort setting or put everything on max "to be safe" - and burn through the team's usage. A simple house rule works better: medium by default, high for anything that goes to a client or a board, low for quick rewrites. On Enterprise plans, admins can also cap effort per role from the admin console.
Decide your policy on flagged messages#
Because of the new safeguards, a message can occasionally be flagged and the chat moved to an older model. Decide as a team whether you want that to happen automatically, or whether people should be asked first (see the setting below). If your work touches security testing, lab science or medical topics, tell staff this can happen so they don't assume Claude is broken.
Part 3: Opus 5.5 in Claude Code#
Opus 5.5 can run for much longer in Claude Code than earlier models. That makes steering - not prompting - the key skill.
Start with a CLAUDE.md that sets the rules#
CLAUDE.md is a file Claude Code reads at the start of every session. Put one in your repository root for project rules, or in ~/.claude/CLAUDE.md for rules that follow you across projects. Think of it as the standing brief you'd give a new colleague.
Here's a version that combines Anthropic's advice into one block you can paste in:
## How to work
- When a step doesn't need my input, keep going. Put status notes in the
same message as your next action.
- Stop and ask only when you can't continue without me, or before anything
destructive: deleting data, force-pushing, or changing anything outside
this repository.
- On any task with more than a few steps, keep a checklist in TASKS.md.
Tick each item when it's done, and add anything new you find.
## How to report
End every run with three headings: Blocked on me, Changed, Found.
Why each line is there:
- "Keep going" - on long tasks Opus 5.5 sometimes stops to report when it doesn't need to. This tells it not to.
- "Stop before anything destructive" - the other half of the rule. You want autonomy, not surprises.
- TASKS.md - long runs fill up Claude's memory of the conversation (its context window), and older details get summarised away. A checklist in a file survives that, and you can open it any time to see progress.
- The three headings - "Blocked on me" goes first, so you always know what to do next.
Prefer to pair? If you like working step by step with Claude, replace the first rule with "Give me a one-line plan before you start, and a short recap at the end."
Keep permission prompts on for destructive commands, whatever your CLAUDE.md says. A written rule is a request; a permission prompt is a lock. And if Claude still stops to ask "Want me to continue?", just reply "continue".
Clean out old "think hard" lines#
Many repos still carry prompting tricks from older models. Find them:
grep -rniE "think (hard|carefully|step by step)|take a deep breath" \
CLAUDE.md .claude/ ~/.claude/CLAUDE.md 2>/dev/null
Delete what you find, including in custom skills and slash commands. If a skill genuinely needs deeper reasoning, set effort: high in its frontmatter instead - that's a real setting, not a hopeful sentence.
Write the task with a finish line#
The same "done" rule from above, applied to code:
Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is
deleted, and the test suite passes.
Stop and ask me only if a test fails for a reason you can't explain.
"The test suite passes" is a great finish line because Claude can check it itself. Wherever possible, give it a finish line it can verify - tests, a build, a linter, a script that exits with 0.
Steer while it runs#
You don't need to stop a long run to change something. Type your message while Claude is working and press Enter - for example, "Also keep the old endpoint names as aliases." It picks the change up without starting again, which matters more now that runs are longer.
Split big jobs across subagents#
A subagent is a separate Claude worker that gets its own task and its own fresh context, then reports back. For audits, migrations and large reviews, ask Opus 5.5 to hand parts out and check each result before accepting it:
Audit every service in services/ for the retry bug in the linked issue.
Give each service to its own subagent. When a subagent reports back,
check its evidence before you accept it.
Finish with one table: service, affected yes or no, and the evidence.
The last two lines do the real work. "Check its evidence" stops one lazy subagent from polluting the result; "one table" gives you something you can read in 30 seconds.
Effort tip: if you define your own subagents, give simple, repetitive ones (searching files, collecting facts) effort: low in their frontmatter, and keep the main session at medium or high. The workers stay cheap and fast; the coordinator does the careful thinking.
Ask for a review before you ask a human#
Anthropic says one early tester found Opus 5.5 at its lowest effort setting caught more bugs than Opus 5 at high effort, with fewer false alarms. That makes a review pass before human review close to free:
Review the diff on this branch against main.
List only problems you'd block the merge for. For each one, give the
file and line, why it's wrong, and how to show it fails.
"Only problems you'd block the merge for" is the key phrase. Without it, reviews fill up with style comments and the real bugs get buried.
Use fast mode when you're watching every reply#
Fast mode (type /fast) makes Opus 5.5's answers arrive sooner, at a higher price per token. It launched as a research preview and needs extra usage turned on.
| Use fast mode | Skip fast mode |
|---|---|
| Quick back-and-forth where you read each reply | Long runs you leave alone |
| Debugging with short loops | Big migrations and audits |
| Live pairing sessions | Anything overnight |
Rule of thumb: pay for speed only when you're the one waiting.
When Claude Switches to an Older Model#
Because of the new safeguards, a flagged message moves your conversation to an older model. Most flags are false alarms on normal work - and tuning is ongoing. Finding security bugs in your own code is allowed, and everyday health and study questions should work as normal.
| In the Claude apps | In Claude Code | |
|---|---|---|
| How you'll know | A "Switched to" note with the older model's name | A message naming the older model |
| Go back to Opus 5.5 | Pick it again in the model picker - or start a new chat, so earlier messages aren't flagged again | Type /model |
| Edit and retry | Start a new chat with a reworded message | Press Esc twice to edit your last message |
| Be asked before switching | Settings → Capabilities → turn off "Switch models when a message is flagged" | /config → "Switch models when a message is flagged" |
| Report a wrong flag | Use the feedback buttons | Type /feedback |
In the apps, the check covers everything in the chat - including attached files and search results - not just what you typed.
One common cause you can fix: asking Claude to "show your full reasoning" or "print your chain of thought" in the reply. It may decline, and it's one of the things that gets flagged. Ask for what you actually need instead: "Explain why you chose this approach in three sentences."
Your Opus 5.5 Checklist#
Everyone
- Model picker says Opus 5.5
- Prompts say what "done" looks like
- No "think hard" lines in prompts or saved instructions
- Effort set on purpose: medium by default, higher only when results need it
- Charts and screenshots attached, not retyped
- Research answers mark what couldn't be confirmed
Teams
- Shared project with standard instructions
- Prompt library for repeat tasks, each with a finish line
- Clear policy on flagged messages and model switching
- A human approves anything that sends, pays or deletes
Claude Code
CLAUDE.mdsays when to keep going and when to stop- Permission prompts stay on for destructive commands
- Long tasks keep a checklist in
TASKS.md - Big audits and migrations use subagents that get checked
- A review pass runs before human review
- Fast mode only for back-and-forth work
Frequently Asked Questions#
Is Claude Opus 5.5 better than Opus 5?#
For most work, yes. According to Anthropic, it keeps going on long, multi-part tasks better, pays more attention to detail, reads charts and screenshots more accurately, and produces spreadsheets and documents that need less editing. It also writes clearer summaries at the end of long tasks.
Do I still need to tell Claude to think step by step?#
No. Opus 5.5 always thinks before it replies and decides how much on its own. Anthropic found that removing lines like "think carefully" made replies start sooner without any loss of quality. If you want a quick answer, say "Answer directly."
What effort level should I use with Opus 5.5?#
Start with the default, medium - Anthropic says Opus 5.5 at medium matches or beats Opus 5 at high on coding and knowledge work. Use low for quick rewrites and simple questions, high when edge cases matter (bug fixes, contract reviews), and keep xhigh and max for genuinely hard problems, since they cost more and max can overthink.
Why did Claude switch to an older model in my chat?#
Opus 5.5 has stricter safeguards around biology and cybersecurity, and when a message is flagged the conversation moves to an older model. You can switch back in the model picker (or with /model in Claude Code), and you can turn off automatic switching in settings so you're asked first.
What is CLAUDE.md?#
It's a plain text file Claude Code reads at the start of every session. You use it to give standing instructions - for example, when to keep going, when to stop and ask, and how to report at the end. It can live in your project folder or in your home folder for personal rules.
Is fast mode in Claude Code worth it?#
Only when you're waiting on each reply, such as quick debugging or live pairing. It costs more per token, so for long runs you leave alone it rarely pays off. It needs extra usage enabled and is turned on with /fast.
Getting the prompts right is step one. Step two is connecting Claude to the systems your team actually works in - your CRM, your documents, your internal tools - so it can finish the job, not just describe it. That's what our MCP integration service does. If you're not sure where to start, our AI consultancy can map which of your team's tasks are worth handing to Claude first.
AI engineer at BrightBit Digital



