Theo Browne: How to Get the Most Out of Opus 5.5

TL;DR

Theo reads through Addy Osmani's new Anthropic guide to working with Opus 5.5 and layers on his own daily practice. Opus 5.5 works for longer on its own, reports plainly on what it did, and always thinks before it replies — so the skill shifts from micromanaging to setting it up to run: say what done looks like, pre-approve what you know it will need, give it an explicit out to ask questions, and tell it which stops you actually want. Don't tell it to "think hard", and don't use Max reasoning — in his benchmark it cost ~13× more for one extra correct answer. When a long run ends, read what it needs from you first, ask about merge risk, and get a second opinion from a different model family.

Key takeaways

• Define "done", then let it run. Opus 5.5 keeps going until it reaches a clear end state — and without one it may stop at a random point to ask permission.
• Every good prompt has three parts: what you want, what done means, and the out (when to stop and ask).
• Pre-approve the scary-but-necessary steps. If it will need to copy your env vars, say so up front, or it will pause and ask.
• Say what you don't want. Explicit negatives ("don't spam my machine with computer-use windows") are even more useful than explicit goals.
• Give it permission to ask. These models are RL-trained to never give up, so they answer their own questions and barrel on. One sentence inviting questions changes that.
• Delete "think carefully" lines. The model already decides how much to think.
• Don't use Max reasoning. Reasoning levels are ceilings; Max is a floor that forces long thinking. Use High or X-High.
• Steer mid-run instead of restarting. Modern models treat follow-ups as additions, not replacements for the original task.
• Design needs negatives. "Avoid generic looks" just swaps one default style for another; a list of specific patterns to avoid works.
• Name the stops in CLAUDE.md so it keeps going when it doesn't need you, and stops before anything destructive.
• Ask for subagents explicitly — Opus 5.5 is less eager to spin them up unless told it can.
• Keep the task list in a file. A TASKS.md checklist survives context summarization on long runs — read the file, not the scrollback.
• Run a review pass before a person does, and get a second opinion from a different model family.
• Ask it to mark what it couldn't confirm — and say where it looked.
• Attach the chart or screenshot itself instead of retyping it; Opus 5.5 reads images more accurately than Opus 5.
• Know your flag escape hatches — the model picker or /model to switch back, and a setting to be asked first.
• Use fast mode (/fast) for back-and-forth work where you read every reply.

Start here: three things to try first

The guide opens with three habits to try in your first sessions with Opus 5.5.

How to ask: say what done looks like

The single most important habit: name the finish, give the whole task in one message, then let it run. Something like "the tests pass" or "every endpoint is migrated." Then, in the guide's words, "let it cook." Compared to prior Opus models, Opus 5.5's biggest gains are on multi-step work — like carrying a change through a large repository until the tests pass — and early testers had it run long coding tasks for hours with little oversight. It may still stop to ask for permission midway, though; a clear finish line tells it when it's actually done.

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.

Anatomy of a real prompt: moving a run to another machine

Theo had a thread running locally (on Max reasoning — more on that below) and wanted it moved to another machine in his fleet, "Leftbook". Instead of manually SSHing in, cloning the repo, copying env vars and setting up browser use, he just described the outcome. Every sentence of the prompt does a job:

Part of the prompt	Why it's there
"You should be able to see how to connect through the fleet repo on this machine."	Tells it how to connect, so it doesn't try something sketchy or trip a security guard.
"Make sure (1) the repo is cloned, (2) the env vars are there, (3) you can run Opus 5.5 through Claude Code and T3 Code so I can still see the thread."	Not just "do it" — validate each step and report if it fails.
Explicit permission to copy environment variables	Pre-approves the sensitive step it would otherwise stop to ask about.
"Do the whole implementation on that machine in one pass, with however many subagents are needed, with full computer use."	An explicit statement of the goal and the tools it may use.
"I don't want you spamming my machine with computer-use requests and browser control while I'm using it."	An explicit negative — even if remote-controlling his laptop looks useful, it knows not to.
"If anything does not work as expected, don't hesitate to ask questions so we can get it working right."	The out. Without it, the model asks itself the question and blasts through anyway.

It finished the setup in about 17 minutes with no interruptions — and flagged a real connectivity issue with that machine along the way.

Reasoning: stop saying "think hard" — and skip Max

Opus 5.5 always thinks before it replies, and it decides how much. Remove "think carefully", "think step by step" and similar lines — from your prompts and your saved instructions.

Theo's key mental model for effort: reasoning levels are ceilings, not targets.

• Low / Medium — think as much as needed, up to a low cap. Low "kind of sucks" on this model; it needs to think a bit (which is why there's no no-reasoning version).
• High / X-High — much higher caps. X-High can still be fast when the task is easy; it's about how much it can think, not how much it will.
• Max — not "can think more" but "can't think less." It removes the model's ability to think briefly, forcing long reasoning on everything.

Theo's own run of Opus 5.5 on SkateBench, X-High vs Max:

	X-High	Max
Avg tokens per response	338	~5,000
Avg duration	6s	50s
Slowest response	31s	600s
Score	78%	79%

The average Max response took longer than the slowest X-High one. His six-and-a-half-hour Max run that "wasn't going anywhere" finished in about 10 minutes once he switched to High.

Steering: add to a running task

If you remember something mid-run, type a follow-up while it works instead of killing the thread. Runs are longer now, so restarting from scratch is expensive. In Claude Code, just type the message and press Enter while Claude works — the guide's example: "Also keep the old endpoint names as aliases."

This used to be risky. Older models were RL-trained per message, so if you asked for tasks 1, 2 and 4 and then sent "wait, I forgot 3", they'd do 3, declare victory, and drop the rest. Current models (Opus, Fable, and mostly the GPT-6 family) treat interruptions as what they are — steering that adds to the work, not a signal that earlier work is done.

Design: say what you don't want

Comparing front-end output across models, Theo initially found Fable 5.1's designs clearly nicer than Opus 5.5's. The catch: Opus 5.5 isn't best at "make it pretty" — it's best at following design direction, especially negative direction.

With no direction, Opus 5.5 falls back on a few default styles. A general "avoid generic looks" just swaps one default for another. A list of specific patterns to avoid works much better:

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 chose instead. If you don't like that either, add it to the list and ask again. This applies to any page, app, or artifact you ask for.

Steering long runs in Claude Code

Name the stops you want

On long tasks, Opus 5.5 sometimes stops to report instead of continuing: a summary that names the next step without taking it, an offer to continue, or a list of choices that don't actually block the work. It follows instructions that name the stops — so name them. Theo pasted this rule straight into his CLAUDE.md on camera and had Opus push it to his whole fleet:

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.

• If a run still stops with "Want me to continue?" — just reply "continue". If it happens often, the rule above is the fix.
• Keep a check before anything risky. A keep-going rule means fewer stops, so the last line of the rule preserves your safety net for destructive or hard-to-undo actions. The guide adds: keep permission prompts on for destructive commands too.
• Pair programming? Flip it. If you want to stay involved (or share the session with someone), put the opposite in your CLAUDE.md: a one-line plan before it starts and a short recap at the end. Opus 5.5 follows either one. Theo prefers fire-and-forget.

Split big work across subagents

For audits, migrations, and reviews across large codebases, ask Opus 5.5 to split the work across subagents and check each result. Splitting keeps each piece inside the context window and lets them explore in parallel; early testers had Opus 5.5 coordinate parallel subagents on long audits and migrations with little oversight.

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.

Keep the task list in a file

From the guide. For a run that will take a while, ask Opus 5.5 to keep its task list in a file and update it as it goes — then read the file, not the scrollback, to see where the run is. A long run fills the context window and Claude Code summarizes older turns; a list in a file survives that, and shows at a glance what's done and what's left.

Keep a checklist in TASKS.md. Tick each item when it's done, and add anything new you find.

Checking the results

Read what it needs from you first

When a long run ends, look first for anything Claude is waiting on — an open decision, a change it wants approved — then read the rest. Opus 5.5 reports much more clearly than Opus 5: its updates and summaries say what it did, what it found, and what it needs, in plain language. To change the summary's format, the guide suggests a CLAUDE.md rule: "End every run with three headings: Blocked on me, Changed, Found." Theo skips the rule and just asks when he needs it.

Theo's go-to follow-up questions

Run a review pass before a person does

From the guide. Ask Opus 5.5 to review a diff or pull request before a human does. One early tester said Opus 5.5 at its lowest effort caught more bugs than Opus 5 at high effort, with fewer false alarms — and it explains its changes in plain language, so its PR descriptions are easier to review.

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.

Review across model families

Opus can review its own code and other agents' code, but Theo gets the most from swapping labs. OpenAI models still dig harder in review: they report more noise, but occasionally catch things Claude models miss entirely. So Opus-written code gets a second pass from GPT-6 Astra (or Soul), and he suggests trying Grok too.

In his informal review benchmark on the T3 Code codebase (findings judged by a model panel):

• GPT-6 Astra and Grok 4.7 each surfaced 8 well-supported improvements — Grok placed second overall.
• GPT-6 Soul found 9, but the judges rated them lower quality.
• Fable found only 5 across two runs — all valid, just fewer.
• Opus 5.5 was almost twice as successful as Opus 5, with zero unresolved or contradicted findings. Opus 5 had 4 supported and 2 unsupported — one bad finding for every two good ones.

Ask it to mark what it can't confirm

The guide frames this for research and analysis: "I couldn't find this" is worth reading, so make it easy to find. Add "Mark anything you couldn't confirm, and say where you looked" to the request — it works in a Claude research report and in Claude Code.

Theo applies the same idea to code. Give the model tools to verify its own changes — a browser, computer use, a test suite it can run or extend. And for anything it can't verify (special hardware, a missing env var, subjective judgment), ask it to tell you. It will. As Theo puts it: the models know your codebase and can work autonomously; what they don't know yet is how to work with a human — so tell them what you need and expect.

Using Opus 5.5 in the Claude apps

Theo skipped most of this part of the guide ("this is making me feel like I shouldn't be reading this article"), but it's useful if you work in the Claude apps. First, check that the model picker says Opus 5.5. Then, from the guide:

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 a message is flagged

Opus 5.5 is the first Opus model to launch with Fable-level bio and cyber safeguards. In the Claude apps and Claude Code, most flagged messages move to an older model and your work goes on there. Finding security vulnerabilities in source code is allowed, and everyday health and educational questions should still work. The safeguards can sometimes flag legitimate work, and Anthropic says it's tuning them to cut down on incorrect flags. Theo says he rarely hits them.

Don't ask it to show its reasoning

Requests to reproduce its internal reasoning in the reply can be declined — it's one of the flag categories. Remove them from your prompts and saved instructions. Theo notes this can bite even innocent phrasing like "what was your reasoning for these changes?" (Anthropic hides reasoning traces, which could be used to distill the model). Ask for what you actually need instead — the guide's example: "Explain why you chose this approach in three sentences."

Speed: fast mode

From the guide. In Claude Code, turn on fast mode (type /fast) for back-and-forth work where you read each reply before sending the next message. It's the same model with the text arriving sooner — available for Opus 5.5 at launch as a research preview. It needs extra usage turned on and costs more per token than standard mode, so save it for interactive work, not fire-and-forget runs.

The checklist

The guide's checklist, with Theo's additions folded in. Run through it before your next long task.

Notable moments

• The six-and-a-half-hour Max run. Left running on his laptop on Max reasoning, it made little progress; switched to High and nudged with "continue", it wrapped up in 10 minutes.
• Putting his money where his mouth is. Mid-video, Theo pasted the "name the stops" rule into his CLAUDE.md and had Opus commit it and push it out to every machine in his fleet.
• Computer use is better off your machine. He nearly gave up on browser and computer use because agents kept popping windows up on his screen. Running agents on remote boxes, fire-and-forget, is what made him like it.
• "It's smarter than you probably are." Theo's case against "think deeply about this" prompts: the model already knows it should think.

Chapters

Time	Topic
00:00	Why Opus 5.5 is so good (and Addy Osmani's guide)
02:28	Three things to try first
04:14	The six-hour Max run and the handoff prompt
08:02	Giving the model an out
09:36	When the first prompt isn't enough
10:40	Say what done looks like
11:43	Stop telling it to think hard — and why not Max
14:54	Steering a running task
16:19	Design: say what you don't want
18:19	Naming the stops in CLAUDE.md
20:22	Splitting work across subagents
21:09	Checking results and merge risk
22:30	Cross-model code review
24:39	Marking what it can't verify
25:42	Claude apps: flags and reasoning requests
27:17	The checklist and wrap-up

Caveats & advice for builders

Much of this is one power user's workflow: Theo runs agents remotely across a fleet of machines and wants to kick off a thread and come back only when it's finished. If you prefer to stay in the loop, the same levers work in reverse — ask for a plan up front and a recap at the end. His benchmarks (SkateBench, the T3 Code review bench) are informal, and he says so; the Max-reasoning result is striking but comes from one benchmark. Where Theo and the guide overlap, they agree — the guide is the more careful source for exact prompts and product behavior, and Theo's additions (effort levels, explicit permissions, giving the model an out, cross-lab review) are his own practice. The bigger point holds regardless: we're at the stage where agents need more leash — permission to act, a definition of done, and the tooling to verify their own work. The systems you build to verify changes matter as much as the code itself.