Anthropic published a developer playbook for Claude Opus 5.5 the same day it launched, written by Addy Osmani, and it's worth reading in full rather than skimming — several of its recommendations actively contradict habits that were correct advice for Opus 5 and every model before it. The core shift the guide describes: Opus 5.5 reasons before every reply automatically, sustains longer unsupervised runs, and reports its own status more plainly — which changes what a well-constructed prompt should actually contain.
TL;DR
| Old habit | What changes with Opus 5.5 |
|---|---|
| Adding "think carefully" / "think step by step" | Drop it — the model always reasons first, decides depth itself |
| Breaking work into small, supervised steps | Hand over the whole task with a defined "done" state instead |
| Asking for "not generic" design | Name specific patterns to exclude — vague requests just swap one default for another |
| Retyping chart or screenshot data | Attach the image directly — Opus 5.5 reads it more accurately |
| Re-reviewing the same earlier answer in long chats | Tell it earlier answers are settled, to stop it re-litigating them |
| Asking it to show internal reasoning in the reply | Don't — this can trigger a safety flag; ask for a short "why" explanation instead |
Give it the whole task, with a named finish line
The single most repeated piece of advice in Anthropic's guide: stop breaking large tasks into small, individually-supervised steps. Give the entire task in one message, name what "done" actually looks like, and specify exactly when Opus 5.5 should stop and check in rather than continuing on its own.
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.
Anthropic's stated reason: Opus 5.5's biggest measured gains over prior Opus models are specifically on multi-step, long-horizon work — carrying a single change through a large repository until every test passes, unsupervised for hours at a time on early testers' reports. A prompt broken into small steps doesn't let that capability actually engage.
Delete "think carefully" from everything
This is the recommendation most likely to feel wrong on first read, because "think carefully" has been reasonable advice for essentially every prior model. Anthropic's guide is explicit: remove it, along with "think step by step" and similar lines, from both individual prompts and any saved system instructions — Opus 5.5 reasons before every single reply automatically, and decides how much reasoning to apply based on the task itself. In Anthropic's own internal chat-product testing, removing a leftover "think carefully" instruction made replies start sooner with no measurable quality drop. If you specifically want a fast, low-effort answer to something simple, the guide recommends saying so directly ("Answer directly") rather than trying to suppress reasoning with an instruction that no longer does anything.
Steering a long, unattended run
For Claude Code specifically, the guide recommends three additions to a project's CLAUDE.md:
- A stop/continue rule — an explicit instruction for when Opus 5.5 should keep working without checking in, and when it must stop, worded to specifically require a check-in before anything destructive: deleting data, force-pushing, or touching files outside the current repository.
- Subagent delegation for large audits — for work spanning many files or services, ask it to split the work across subagents, verify each subagent's evidence before accepting the result, and finish with a single consolidated table rather than a scattered report.
- A task list kept in a file, not scrollback — for runs long enough to trigger context compaction, a
TASKS.mdfile that Opus 5.5 updates as it works survives the compaction that would otherwise summarize away the original detail, and gives you a checkable-at-a-glance view of what's actually done.
Naming the design patterns you don't want
The guide's design-specific advice is one of the more actionable, concrete pieces of the whole document: with no direction, Opus 5.5 falls back on a small set of visual defaults, and a general instruction like "avoid a generic look" mostly just swaps one default aesthetic for a different one, rather than actually producing something distinctive. The fix that works considerably better in Anthropic's testing is naming the specific patterns to exclude directly:
Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in
headings, numbered "01 / 02 / 03" section labels, monospace labels, or
pill-shaped buttons.
Then look at what it produces instead, and if that result has its own default pattern you don't like, add it to the exclusion list and try again — the guide frames this as an iterative refinement loop rather than a one-shot instruction.
Checking results, and what to read first
When a long run finishes, the guide recommends reading the "what it needs from you" section of the summary before anything else — a decision it left open, or a change it's waiting on you to approve — since Opus 5.5's reports are structured to surface that plainly rather than bury it. For code review specifically, Anthropic reports one early tester found Opus 5.5 at its lowest reasoning effort caught more bugs than Opus 5 did at high effort, with fewer false positives, using a prompt asking it to list only problems that would actually block a merge, with file, line, and a concrete failure demonstration for each.
Handling safety flags
Opus 5.5 shipped with Fable-level cybersecurity and biology safeguards, the first Opus model to do so, which means some messages get automatically re-routed to an older model. In Claude apps, this shows as a "Switched to [model]" notice, and the conversation continues on the older model unless you manually pick Opus 5.5 again in the model picker — starting a fresh chat avoids the same earlier message re-triggering the flag. In Claude Code, /model switches back directly, or pressing Esc twice lets you edit and retry the flagged message. Both surfaces let you disable automatic switching in settings if you'd rather be asked before the model changes. One specific flag category worth knowing about directly: asking Opus 5.5 to reproduce its internal reasoning inside the visible reply can itself trigger a flag — ask for a short, plain-language explanation of its approach instead.
Speed: fast mode, and when it's actually worth it
The guide's final section covers a detail easy to miss in the flood of prompting advice: /fast in Claude Code enables a research-preview mode that returns Opus 5.5's output more than 2.5x faster, at a higher per-token cost, requiring extra usage allocation to be turned on. Anthropic's specific recommendation is narrower than "use it whenever you can afford it" — it's meant for interactive, back-and-forth sessions where a human is actually reading each reply before sending the next message, not for long, unattended autonomous runs where the model is working through a queued task list on its own. The reasoning follows directly from the rest of the guide: if you've structured a task correctly for a long unsupervised run (a named finish line, a stop/continue rule in CLAUDE.md, a task file), you're not sitting there waiting on each individual reply, so the latency fast mode buys you isn't the bottleneck — you'd just be paying the premium for speed you're not using.
Why so much of this guide is about removing instructions
A pattern worth naming across the whole document: nearly every recommendation is about deleting something from an existing prompt or workflow, not adding something new. Drop "think carefully." Drop small-step supervision in favor of whole-task handoff. Drop vague design instructions in favor of specific exclusion lists. Drop requests to reproduce reasoning in the visible reply. That's a genuinely different shape of guidance than most model-launch documentation, which typically emphasizes new capabilities to try rather than old habits to unlearn. It reflects something real about how prompting advice ages across model generations — instructions that compensated for a weaker model's specific failure modes become dead weight, or worse, actively counterproductive, once the underlying capability gap they were patching has closed. The practical lesson for anyone maintaining a library of saved prompts, system instructions, or CLAUDE.md files across multiple projects: treat a major model upgrade as an occasion to audit and prune existing prompt scaffolding, not just an occasion to write new prompts for new features.
Honest limitations
- This post summarizes Anthropic's own published guide, which is inherently written to present the model favorably — treat the specific quantitative claims (e.g., "caught more bugs at low effort than Opus 5 at high effort") as Anthropic's own reported internal testing, not independently reproduced results.
- Fast mode is explicitly a research preview as of this post, requiring extra usage allocation and costing more per token — it is not the default mode, and Anthropic recommends it for interactive sessions specifically, not long autonomous runs.
- Safety-flag behavior is still being tuned by Anthropic's own account — the guide itself states the classifiers "can sometimes flag legitimate work" and that Anthropic is actively working to reduce incorrect flags, meaning current behavior may shift after this post's publication.
What this means for builders
The highest-leverage change to make immediately is deleting leftover "think carefully" instructions from any saved CLAUDE.md, system prompt, or prompt template built for prior models — it's dead weight now, not a quality lever. The second is restructuring how tasks get handed off: if your current workflow breaks work into small, individually-supervised steps out of habit from earlier, less reliable models, Opus 5.5's actual advantage over Opus 5 is specifically in sustained, whole-task delegation with a clearly named finish line — a workflow that under-uses that advantage is leaving real capability on the table.
Related on explainx.ai
- Claude Opus 5.5 Launch: Every Benchmark and Reaction — the full launch coverage this guide accompanies
- Boris Cherny Used Opus 5.5 to Formally Verify the Claude Agent SDK — a real, advanced example of the "hand over the whole task" pattern described here
- Claude Code Commands: Complete Reference Guide — the broader command reference this playbook's
/model,/config, and/feedbackmentions build on - Claude Agent SDK Support for AGENTS.md — related project-configuration guidance for Claude Code
Primary source: Anthropic's "Getting the most out of Opus 5.5" developer guide, September 22, 2026, by Addy Osmani.
This post summarizes Anthropic's official guidance as published September 22, 2026. Specific model behaviors, safety-flag tuning, and fast mode availability are subject to change.