Theo walks through Anthropic's own usage guide for Opus 5.5, line by line, and adds the real prompts and a six-and-a-half-hour mistake to prove which parts actually hold up.
Opus 5.5 runs longer and more independently than prior models, but only if you name the finish line, state what you don't want, and never touch Max reasoning.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You use Claude Code or Claude apps for multi-step coding work and want fewer needless check-ins mid-run.
You've been burned by a long agent thread that either stalled asking permission or ran forever without stopping.
You want a plain-English breakdown of reasoning levels (low/medium/high/X-high/Max) instead of marketing copy.
You're deciding whether to use Max reasoning mode and want real cost numbers first.
SKIP IF…
You've already read Anthropic's original blog post and just want the source link.
You don't use Claude Code or the Claude apps at all.
TL;DR
The full version, fast.
Anthropic published a guide on using Opus 5.5 well; Theo walks through it and stress-tests each tip against his own agent runs. The core mechanism: Opus 5.5 works for longer stretches on its own and reports back more plainly, so prompts need a named finish line, explicit permissions, and explicit stop conditions instead of step-by-step hand-holding. The clearest data point is Max reasoning: in Theo's own benchmark it used 15x the tokens and took 20x as long as X-high for one extra correct answer out of a hundred. Actionable conclusions: hand over the whole task with a clear done-state, name what you don't want (especially for design), write a short CLAUDE.md rule for when to stop and ask, and never use Max.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Theo introduces the video and vouches for Addy Osmani, the ex-Chrome-team writer now at Anthropic behind the guide.
00:55 – 02:31
02 · Sponsor: Browserbase
Sponsor read for Browserbase, a hosted browser for agents to search, fetch, and act on the web.
02:31 – 04:32
03 · Three things to try first
The guide's opening exercise: hand over the whole task with a defined done-state, drop 'think carefully' lines, and read what a long run needs from you when it ends.
04:32 – 10:41
04 · The 6.5-hour Max-reasoning cautionary tale
Theo's own thread ran unattended on Max reasoning for six and a half hours; he then walks through the exact prompt he used to hand a full implementation off to an agent on a remote machine, including explicit permissions and an escape hatch.
10:41 – 14:46
05 · Name the finish, then the real cost of Max mode
The guide's 'how to ask' section (name the finish line, stop telling it to think hard) followed by Theo's Skatebench numbers showing Max reasoning's token and time cost against X-high.
14:46 – 16:22
06 · Steering: mid-run follow-ups now work
Modern models treat a mid-run message as steering instead of a reason to abandon the original task, a fix over older models that would forget everything once interrupted.
16:22 – 18:29
07 · Design work: name what you don't want
Using the Witch AI comparison, the guide argues vague design instructions just swap one generic default for another; specific negative instructions work far better.
18:29 – 20:36
08 · CLAUDE.md rules for long runs
Theo pastes the guide's suggested stop/continue rule directly into his own CLAUDE.md and has an agent commit and push it to the rest of his fleet.
20:36 – 21:26
09 · Split big work across subagents
For audits, migrations, and large-codebase reviews, splitting work across subagents keeps each piece inside a manageable context window, but the model won't do it unless told it's allowed to.
21:26 – 25:02
10 · Checking results: risk questions and cross-model review
Theo's go-to prompts for checking a long run ('what's the risk of merging this right now') and his benchmark results showing OpenAI-family and Grok models finding more review issues than Claude models reviewing their own work.
25:02 – 27:49
11 · What models still can't do, and Claude's safety flags
Models can verify their own code but don't yet know how to work with a human; the section closes on Opus 5.5's stricter safety flagging and why asking about its reasoning risks a silent model switch.
27:49 – 28:41
12 · Checklist and sign-off
A quick recap checklist (name done, don't tell it to think hard, give design negatives, attach screenshots) and a tease for an upcoming video, then sign-off.
Atomic Insights
Lines worth screenshotting.
Opus 5.5 works for longer on its own and tells you plainly what it did, which means prompts need a named finish line instead of step-by-step instructions.
In a benchmark comparing X-high to Max reasoning, tokens per response jumped from 338 to 5,000, a 10x increase, for one additional correct answer out of a hundred.
Max reasoning doesn't raise the ceiling on how much a model can think, it removes the model's ability to think less, which is why it burns tokens on easy steps too.
The average Max-reasoning response took 50 seconds versus 6 seconds on X-high, and the slowest Max run took 600 seconds, 20 times the slowest X-high run.
A three-part prompt structure works best: state what you want, name what counts as done, and give the model an explicit condition under which it should stop and ask.
Telling a model to 'think carefully' or 'think hard' is now unnecessary noise; Opus 5.5 already decides how much to think before every reply.
Explicitly granting permission for actions you know an agent will need, like copying environment variables, prevents it from stopping mid-run to ask.
Stating what you don't want a model to do is as important as stating what you want; an explicit 'don't spam my screen with popups' instruction stopped that behavior entirely.
Giving a model an explicit 'out' to ask a question when confused makes it more willing to stop and check instead of guessing and pushing through, which is its default trained behavior.
Newer models handle a mid-run follow-up message as steering rather than as a reason to drop the original task, a real change from older models that would forget everything else once interrupted.
With no design direction, a model falls back to a handful of generic visual defaults no matter how many times you ask it to 'avoid generic looks.'
A list of specific negative instructions, like 'no cream backgrounds' or 'no pill-shaped buttons,' changes a model's design output far more reliably than a single vague instruction.
A short CLAUDE.md rule naming exactly when to stop and ask, versus when to keep going, measurably cuts down on needless mid-run check-ins.
A model won't spin up subagents for a large audit or migration on its own unless you explicitly tell it that it's allowed to.
Asking an agent 'what's the risk of merging this right now' surfaces more useful information than trying to manually read every line of an hours-long agent's diff.
Getting a second model from a different lab to review code catches issues that the original model's own family tends to miss entirely.
Opus 5.5 launched with stricter safety flagging than prior Opus models, and asking it to explain its own reasoning is more likely to trigger a silent model switch.
Takeaway
Nine habits for getting more out of Opus 5.5
PROMPT HABITS
Across nine habits the same theme repeats: tell Opus 5.5 exactly what done looks like, what to avoid, and when to stop, and it will run further on its own than any model before it.
03Three things to try first
Hand over the whole task in one message instead of one step at a time, and define what 'done' looks like before you hit send.
Name the finish line explicitly, such as 'the tests pass' or 'every endpoint is migrated,' so the model knows when to stop.
Delete 'think carefully' and similar phrases from your prompts; Opus 5.5 already decides how much to think on its own.
04The 6.5-hour Max-reasoning cautionary tale
Running a long agent thread on your own laptop instead of a remote machine means you can't walk away without tying up your computer.
Give the model explicit permission for actions you know it will need, like copying environment variables, so it doesn't stop to ask.
State what you don't want as clearly as what you want; telling a model not to spam your screen with popups stopped it from doing so.
Give the model an explicit 'out' to ask a question if something doesn't work, or by default it will guess and push through instead.
05Name the finish, then the real cost of Max mode
A three-part prompt works best: what you want, what counts as done, and the one condition where it should stop and ask.
Reasoning levels below Max are caps, not targets; low and medium think only as much as the problem needs, then stop.
Max removes the model's ability to think less, not just its ability to think more, which is why it burns tokens even on easy steps.
In one benchmark, moving from X-high to Max reasoning used 15x the tokens and took 20x as long for one extra correct answer out of a hundred.
06Steering: mid-run follow-ups now work
Modern models handle mid-run follow-up messages as steering now, not as a reason to abandon what they were already doing.
You can add a forgotten requirement while the model is still working instead of stopping the thread and rewriting the whole prompt.
Older models used to treat an interruption as the new full task and silently drop everything else you'd asked for.
07Design work: name what you don't want
With no direction, a model defaults to a handful of generic visual styles no matter how many times you ask for something 'not generic.'
A list of specific things to avoid works far better than a vague instruction like 'avoid generic looks.'
Naming concrete negatives, like 'no cream backgrounds' or 'no pill-shaped buttons,' changes what a model produces more reliably than naming what you want.
Pointing at a screenshot with an arrow and saying 'this sucks, make it better' works better than describing the problem in words.
08CLAUDE.md rules for long runs
Put a short rule in CLAUDE.md naming exactly which situations should make the model stop and ask versus keep going.
A model told to keep going unless it can't continue without you, or is about to do something destructive, produces far fewer needless check-ins.
Status updates belong in the same message as the next action, not as a stopping point that waits for a reply.
09Split big work across subagents
For large audits, migrations, or reviews across a big codebase, splitting work across subagents keeps each piece inside a manageable context window.
A model won't spin up subagents on its own unless you explicitly tell it that it's allowed to use them.
10Checking results: risk questions and cross-model review
When a long run ends, look first for anything the model is explicitly waiting on you for before reading the rest of the summary.
Asking 'what's the risk of merging this right now' surfaces more useful information than trying to read every line of an hours-long agent's diff.
Getting a second model from a different lab to review code catches issues the original model's own family tends to miss.
OpenAI-family models reportedly dig deeper into review details and report more false positives, while Claude models under-report but are more consistently right.
11What models still can't do, and Claude's safety flags
Ask the model to explicitly flag what it could not verify, whether that's a hardware limitation, a missing environment variable, or a subjective call.
Give the model the tooling to check its own work, like a browser, a test suite, or computer use, so it can confirm changes instead of just claiming they work.
Opus 5.5 ships with stricter safety flagging than prior Opus models, and messages that ask it to explain its reasoning are more likely to get switched to another model.
Glossary
Terms worth knowing.
Reasoning levels
Settings (low, medium, high, X-high, Max) that cap how much a model can think before replying. Below Max, they're ceilings the model may not use fully; Max forces maximum thinking on every response.
Max reasoning
The highest reasoning setting in Claude Code. It removes the model's ability to think less rather than simply allowing it to think more, which drives up token cost and response time even on easy steps.
Steering
Sending a follow-up message to an already-running agent thread so it incorporates the new instruction into its current work, instead of treating the interruption as a reason to stop or restart.
CLAUDE.md
A markdown file read by Claude Code at the start of a session that holds project-specific rules and instructions, including when the model should stop and ask versus keep working.
Subagents
Separate agent instances a coding assistant can spin up to split a large task, such as a codebase audit, into pieces that each fit inside a manageable context window.
“I really don't think you should use Max on Opus 5.5.”
blunt, contrarian, one sentence→ TikTok hook↗ Tweet quote
12:25
“Max isn't just making it so the model can think more. It is removing its ability to think less.”
reframes a settings toggle as a real tradeoff→ IG reel cold open↗ Tweet quote
13:52
“It cost 13 times more. It used 15 times the tokens. It took 20 times longer in the worst cases. And I got jack fucking shit out of it.”
escalating stat list with a blunt punchline→ TikTok hook↗ Tweet quote
14:47
“Don't tell the model to fucking think. It knows that it should think. It is smarter than you probably think.”
quotable one-liner that closes the reasoning section→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogystory
Opus 5 .5 has been out for a bit now, and the more I use it, the more I think this model might actually be really, really good. I've been very impressed with the code it puts out, with how nice it is to interact with, with how it stays on task for long work, as long as you don't use Macs. I'll talk about that in a bit, don't worry.
Today I want to talk about how you can get the most out of this model. I've had a couple videos like this and they vary in performance, but I think it's some of the more important work we can do, especially when awesome people like Addy Osmani, who used to be part of the Chrome team, recently joined Anthropic and is using his depth of knowledge and education capabilities to write something awesome like this.
If all goes well here, not only are you going to learn about how you can use Opus 5 .5 more effectively, hopefully I will as well. I trust Addy with my damn life if I'm being real. This guy is super legit.
And when I saw him joining Anthropic, I got really hyped. And I am so excited to see what he has to teach us about maximizing the value we get out of the new Opus release. the topic of maximizing value, we should take a quick break for today's sponsor.
If a chef doesn't have access to ingredients, they probably can't cook a very good meal. So why do we think our agents are going to make good results if they don't have access to 80 % of the data they need that is currently locked away on the internet? It turns out agents need a way to get that data.
They need a way to browse the web. And that's why Browserbase built the browser for your agents, not just for going to sites and clicking through them, but for getting all the context they need from the internet. Whether it's through their search API to get results on whatever arbitrary queries they need to resolve, or their fetch API where they need to get some data out of a page that is hard for them to access how many times have you seen an agent write a curl request fail give up and then go find something else that was incorrect if you've ever seen codex or cloud do this you know how miserable it can be you've probably already burned hundreds of dollars in tokens hitting these errors silently and not even noticed and if your agents do need real browsing capabilities to do actions on your behalf whether it's to sign into a page to book something or go find some data that's behind a paywall or a signed in state that you need browserbase can handle all of that for your agents too
Firebase's goal is simple. Since agents are good at calling APIs, turn the whole web into one. This means that they handle all the details, from scaling up their servers to make sure you're always able to access what you need, to catching broken flows in your apps with real agents clicking things and noticing issues, to getting around captchas, handling auth, and so, so much more.
Ready for a crazy lore drop? Browserbase is so good that it's what Google officially recommends for their computer use work. This is a real Google repo demoing computer use, and they recommend Browserbase.
Figure out why everyone from Theo to Google loves them at soydiv .link slash browserbase. Let's talk about getting the most out of Opus 5 .5. Opus 5 .5 works well in the way that you already use Clod.
A few things do behave differently though. It works for longer on its own, it tells you plainly what it did, and it thinks before every reply. This guide covers how to work with Opus 5 .5 in Clod apps and Clod code, including how to prompt the model, steer long runs, and check your results.
He starts with a really fun exercise. He recommends trying three specific things in your first sessions with Opus 5 .5. The first example he has here is a thing I talk a lot about.
The idea of handing over the whole task. I call this prompting wider, having the model come in earlier and go further. And an important part of doing this is defining good done states.
What is complete? Rather than start working on this feature, say I want you to build it so it has these three things. Verify it by showing me a screenshot and then file a PR after.
That gives the model a clear end state. It's not done until it has made the feature, there is a screenshot of the feature, and there is a PR up including that feature and the screenshot. Generally speaking, these higher tier models from Anthropic and OpenAI work really, really well if you tell them what done is, because they'll keep going until they get there.
The next two things are... More vague, so I'm curious how he frames these as we go on. The second one was delete think carefully lines.
You don't need to tell the model to think. It already is going to. I don't know if that really fits here exactly, but interesting inclusion.
The last piece, I don't like the wording for, but it is important. When long runs end, read what it needs from you first. This is an important thing, and I actually think the new model does this quite well, where after it does a run, it will tell you exactly what it needs.
It does sometimes miss this though, so I'll often find myself prompting accordingly. Here's a real threat I kicked off earlier today in T3 code that I think showcases what I'm talking about relatively well. This is a threat I had started on my machine testing out the new Opus model with Max reasoning.
Six and a half hours later, I realized I wasn't going anywhere. I really don't think you should use Max on Opus 5 .5. It just...
This thread ran for way too long as I had it on max reasoning, and I was running it on my own computer, which was even more annoying. As y 'all who have been around for a bit know, I have moved pretty much all my agent work off my laptop and onto other machines, mostly in my apartment, but a few remote servers as well. So normally when I use T3 code, I trigger it somewhere else.
But in this particular case, I only had the code base and everything set up on this particular machine, and I wanted to see it working too. So I ran it on here, forgot about it, went and did other things, came back, and it had been running for six and a half hours. I switched to high reasoning.
asked what was going on. I only asked it, what's the state of the work? It didn't continue the work after there.
I told it to continue and it did. 10 minutes later, it had finished and it was in a pretty good spot. I asked how long it thinks these changes will take.
That was for another demo in a video. But here's the prompt I actually care about. Remember, this thread was running on this laptop I'm on right now and I wanted it to run somewhere else.
I could have put the manual work in here. I could have... SSH into the other computer, clone to the repo, add it to T3 code, opened it there, SSH in again to go dump all the environment variables, make sure it has browser use and everything it needs set up, and then tell it to go take this markdown file that would copy paste over.
Instead, I just told the model what I wanted. This is the prompt that I think does a good job of giving the agent an out when it needs it. I want you to kick off an agent run on my computer named left book.
you should be able to see how to connect through the fleet repo on this machine. This was me letting it know how to connect, so it doesn't try to do anything sketchy to connect, and also so it doesn't do something dumb that might cause it to hit a security guard or flag. I want you to make sure, one, that the repo is cloned, two, all the needed environment variables are there, and three, that you can run Opus 5 .5 through cloud code and T3 code, such that I can still see the thread how I normally do in T3 code.
There's a couple pieces here that are important. I want you to make sure... is me telling the model, not only do I want you to do these things, I want you to validate that you can and inform me if it fails.
I also am explicitly giving it permission for very specific, important things, like its ability to copy my environment variables. If I didn't tell it it could do that, it might be concerned when it goes to do that and then stop and ask me. I don't want it to stop.
I know it's going to have to do that for this work, so I just told it it can, so I don't have to give it permission. Then we get to the other parts I had here, specifically what my goal was. My goal here is to do the whole implementation on that machine in one pass with however many subagents and whatever else are needed with full computer use capability on the other machine.
This is an explicit statement of what I want. Being explicit about what you want is great, but being explicit about what you don't want is even better. I don't want you to be spamming my machine with computer use requests and browser control while I'm using it.
This is the most annoying thing in the world that actually made me not use browser use and computer use as much. I got so annoyed with Codex just popping windows up on my screen constantly. When I started using this remotely on other boxes, I started liking computer use a lot more.
When I didn't have to watch it. pulling Windows up when I'm trying to do other shit on my computer. Because I fire and forget.
I throw up a thread, I let it do its thing, and then I go respond to some messages in Slack. Or I go play a game through my fork of moonlight. I do other things while my threads run.
I don't want them interrupting the other things while they're running. So this specific request to not spam my machine makes it very explicitly clear that even if it thinks remote controlling my machine to access the other machine is a good idea, that it knows not to. Then we get to what might be the most important piece.
If anything does not work as expected when you move this workload over to Leftbook, don't hesitate to ask questions so we can get it working right. It sounds silly, but these models have been RL'd to fucking hell and back to not give up on tasks. So if the model asks a question, the initial thing it's been RL'd to do is to try and answer the question itself.
So if it did have questions or issues with my request here, it by default might not do the right thing. It might ask itself, should we try another way or is this still right? And then go blast through it anyways.
This particular last sentence gives it an out. It makes the model more willing to stop and ask the question if it does run into a problem or it does get confused. Thankfully, it didn't run into any problems here.
Everything went relatively well. It gave me an overview of all the things that it did in this process. Called out that I have some connection issues with Leftbook remotely right now, which I do actually need to figure out.
I have some PRs up that should fix that. But the point here is that I gave the model exactly what I wanted. I upfront told it about the things that I was scared it would ask about because I didn't want it to stop and get permission.
I just wanted to do the thing. And I also gave it an out, where if it didn't have confidence in a path, it could ask me so I could hand it the solution. And the result was that after about 17 minutes, it was able to get all of this set up.
And most importantly, I now had the thread from my other machine. Here it is. This thread from my other machine appeared and is behaving.
And apparently it only did phase zero. Great. Let me see the prompt it ran here.
Goal, build the whole ping rewrite described in OverhaulMD in one pass on this branch. Read the whole plan before you start. Follow its phase 0 to 7 in order.
And it did phase 0. And then stopped. I want you to hold off on all questions until the very end when you get through to phase 7 in completion.
I don't want you to stop after every phase to ask for permission to continue. I want you to do the whole thing. Continue working on this port until the entirety of it is completed.
And don't inform me until you have a tailscale link I can click on that is the complete rewrite so I can test it and make sure everything works. Don't worry about how it's hosted. Don't worry about how it's built.
Just worry about completing the work as assigned. I am admittedly a little disappointed that that first prompt wasn't enough to get it to behave properly, but now it will be. Now I do not have to look at this thread again for at least an hour or two.
Yay. So with that all running, let's dive back into this blog post. The first section is how should you ask?
It starts with this important piece that, funny enough, Opus doesn't understand. That's why it just had the issues there. You have to say what done looks like, then let it run.
Name the finish. Give the whole task in one message. Something like the tests pass or every endpoint is migrated.
It needs specific instructions. The reason that we have to do this is because despite Opus 5 .5 being much better at going on long multi -part work, it might still stop to ask for permission. With a clear finish line, it will know when it's done.
But again, as you saw with that example there, without that, it might just randomly stop. Addy gives an example here of what this would look like. Migrate the payment's endpoint from the old client to the new one.
Done means every endpoint uses the new client, the old one is deleted, and the test suite passes. Stop and ask me only if a test fails for a reason that you can't explain. This is the perfect simple one, two, three.
What you want, what means done, and the out if it needs an out, if it does get confused or does something wrong. Next point, stop telling it to think hard. I am amazed people still do this.
I've seen so many people say like, think deeply about this. The models are pretty good at knowing how much to think. In fact, a video I kind of want to do, but I don't know how to like phrase the ideas and like package it well enough, admittedly a crash on max reasoning.
Because the cool thing about these models now is that the reasoning levels aren't necessarily think this much. The reasoning levels are think up to this much. Low and medium are effectively saying think as much as you need until you hit this point and then stop.
High and X high are much higher caps for how much thinking the model can do before it stops and gives up because the thing was too hard. Max isn't just making it so the model can think more. It is removing its ability to think less.
And that's what scares me about max reasoning and why I specifically think you shouldn't use it. Funny enough, I was talking about this with Addy earlier, and he's trying to figure out how they can improve max reasoning levels in Opus 5 .5 in Cloud Code. But the way I would recommend thinking about max right now isn't it can think more.
It's forcing it to not think less. You can see this very easily here with my runs with 5 -5 using X high and max in Skatebench, which is admittedly kind of silly benchmark. On X high, the average tokens per response was 338.
The average duration for a response was 6 seconds, and the slowest was 31 seconds. On max, the tokens went from 338 average to 5 ,000 average. More than a 10x.
Much scarier. It bumped the average duration to 50 seconds. So the average max run took longer than the slowest X high run.
And the slowest run was 20 times slower at 600 seconds. You know what the best part is? All it got out of that was one additional correct answer.
It went from 78 % to 79%. It cost 13 times more. It used 15 times the tokens.
It took 20 times longer in the worst cases. And I got jack fucking shit out of it. Are there things where max could help?
Like maybe it is falling for a simple trick answer, but if it has to reason more, it doesn't fall for the trap. Perhaps. I still don't think you should ever use max reasoning.
All the other reasoning levels just change the ceiling and X high can still be fast. It could still not do much reasoning. It's just a matter of how much can it do, not how much will it do.
Max is a will. You are setting it and forcing it to think more. I just leave it on higher X high and don't think about it right now.
personally, but yeah, low kind of sucks. I'll be real there. This model does need to think a bit.
That's why they don't have a no reasoning version. So yeah, I'm sure a lot of y 'all like the comment I got the most in my previous video was what reasoning level should I use higher XI? They're both fine.
I don't have any issue with either. I can barely notice the difference with either XI feels like it takes a little longer high sometimes misses like smaller details that XI doesn't not that big of a gap. I just leave it a higher XI.
And don't tell the model to fucking think it knows that it should think it is smarter than you probably think. Hell, it's smarter than you probably are. It's smarter than I am.
Next, we have add to a running task. If you remember something mid run, you can type a follow up while it works. Why does this matter?
It matters because the runs are longer. So going back to the start is more expensive. I've done this before.
I've had times where I noticed the model was just going the wrong way when I was reading its outputs and just decided, fuck it, stop. New thread, copy paste prompt, make a few adjustments, add two more things to the bottom. Like, by the way, do these things as well.
I don't do that anymore. The modern models, specifically Opus, Fable, Sol, kind of, and Astra mostly, are way better at what we call steering. That's when you hit send when it's already working and it steers the model in the direction of what you sent while it's running.
Steering used to have a pretty rough problem where the RL was on a per message basis. So if you said, I want you to do tasks one, two, and four, and it started working, and you're like, wait, I forgot to mention three. It would then forget about one, two, and four, immediately do three, and then be like, okay, I finished three, and then not do the other tasks from the previous message.
Because through its training, it effectively was taught to complete the message and ignore the history beyond how it helped the context. They have now been trained better about this to take these interruption messages, not as a reason to stop previous work or treat it as done, but as what they are steering additional things to help the model go the right way.
Here's another one that's really important around design. This one actually bit me a bit when I was using the model. When I took a look at Witch AI, which I still think is one of the cooler projects I can use to showcase model capabilities, this was built by Dara to show the front -end capabilities of different models.
I noticed that Fable 5 .1 had much better designs overall than Opus 5 .5 did. This is the Opus 5 .5 version of this design, and this is the Fable 5 .1 version. I hope we can all agree that the Fable version is obviously better and nicer.
But I saw other people saying Opus was a way better designer. And I was confused because when I took this quick look here, didn't seem to be the case. Turns out the thing Opus 5 .5 is good at isn't just making a nice design when you say, hey, make it pretty.
It's much better at going the right direction with design instructions. If you tell it what you want, and more importantly, also tell it what you don't want, it can make really good designs. I like how Addy framed it here.
This is another example of like Anthropic loosening their death grip on comms, letting the employees say things that the models are bad at. The reason this matters with Opus 5 .5 is that with no design direction, Opus 5 .5 will fall back on a few default styles. A general instruction like avoid generic looks will mostly just swap one default for another.
A list of specific patterns will work much better. For example, build a personal website with placeholder content. Don't use a cream or off -white background.
Italic accent words and headings. Numbered 1, 2, 3 section labels. Monospace labels or pill -shaped buttons.
I don't think you should have to specify that many negatives, but you get the idea. When you tell it to not do a thing, it won't do the thing. And once that's done, you can look at it and decide if you like it or not.
If you don't like something it added, put that on the list and then ask again. Or something I do a lot. I use a tool like Shotter where I take a screenshot.
I draw an arrow, I point it, and then I just paste this into the chat prompt. Like, I don't know, here, paste. And then I'll say something like, this sucks, make it better.
That works way better than you would think. Next, we have more on steering. Steering long runs in quad code.
The first point, tell it which stops you want. You can put a short rule in your quad MD file about when to stop and ask and when it should keep going. The reason this is important is because Opus 55 will keep you posted as it works.
On long tasks, it'll sometimes stop to report instead of going on, 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 the stops that you want as well.
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 of this repo. You know what I'm going to do?
I'm putting my money where my mouth is. I'm pasting this directly into my CloudMD. I already have a section around approvals here, and I'm putting it at the end of this.
When a step doesn't need my input, keep going. Put status of same message, yada yada. It's the exact thing we just read.
Now this will be in my CloudMD, but I don't have a script that auto pushes this. I am much sillier than that nowadays. So I hop here, I switch over to Opus 5 .5, and I say, I just updated the CloudMD in this repo.
Commit it and push it out to the rest of the fleet. One of the rare instances of typeless screwing up my pros, but that is fine. Cool.
Oh, it actually does have a dictionary. That's nice. Hopefully this will be a meaningful improvement.
I like that. We'll see how it helps. If a run stops with, want me to continue?
Reply continue. If it happens often, the rule above will help. Yep, that's why I added it.
A rule to keep going means fewer stops, so keep your own check before anything risky or hard to undo. The last line of the rule above does that. It also calls out the example of prepared programming, where you might want the opposite.
Maybe a one -line plan before it starts and a short recap at the end, because you want to be more involved with it, or maybe you have another person working on this with you too. It can be very useful. I don't want that.
I want to kick off the thread and come back to it when it's done, if even. So I very much prefer the telling it to just keep going here. The next point.
ask it to split big work across subagents. The point here is that for audits, migrations, reviews across large code base and stuff like that, splitting the work up into subagents can make it much easier for the work to get done within the context window and for those different subagents to go explore different things. The reason this matters is because early testers had Opus 5 .5 coordinate parallel subagents on long audits with little oversight, and it was successful.
The other thing he isn't saying here is that I've noticed Opus 5 .5 seems less willing to spin up subagents unless you tell it that it can't. So I find myself often telling at the end of prompts, use subagents and workflows however you choose. I trust your judgment there.
Even then, it doesn't always do it. So if you like... know the task is better with sub -agents like a giant pile of PR reviews or an audit of your code base, just tell it to you sub -agents.
And it does. The next section is around checking the results. What should you do?
When long runs end, look first for anything Claude is waiting on you for, like a decision it left open or a change it wants you to approve. Then read the rest of the Claude summary. The reason this matters is because Opus 5 .5 reports on its work more clearly than Opus 5 did, so it's actually worth reading the outputs.
The updates and our final summaries say what they did, what they found, and what it needs from you in plain language. This is interesting. He actually suggests putting this in the CloudMD.
End every run with three headings. Blocked on me, changed, and found. I'm not going to go that far.
When I do want this, I usually just ask. I often will find myself going back to a really old thread and not remembering what it's for or what the status is. I'll just ask it.
What's the status of this work? What do you need from me? Another one I ask a lot, and I'm amazed at how helpful this has been.
What are the risks of merging this code today? That's probably my most common prompt. I'll often have a PR up from an agent that ran for hours, made a bunch of changes, simplified it, and it gives me like a 300 line of code thing that I don't fully understand or really care to read.
And I don't know if I should bother reading it or not until I know how risky it is. So I'll just ask. How much risk do you perceive with this change?
What's the worst thing that would happen if we merge this right now? And I have found myself much, much better understanding the state of my work when I ask questions like that. Another fun thing you can have the model do is review code.
It can review its own code. It can review code from other agents and other models. I have personally found that swapping between model families and labs is actually pretty useful.
I think that like... Generally speaking, I find open AI models to be better at review still. They just really dig into the details and won't let go of the thing until it's confidence found everything.
It'll report more stuff that doesn't matter, but it will occasionally find things that do matter that the cloud models just miss entirely. So personally, when I have Opus code being reviewed, I don't want just Opus reviewing it. I would like for Aster or even like Sol to give it a review as well.
That said. 5 .5 does find a lot more than previous Opus models did. I mentioned this in both my Grok and Opus videos.
I put together a bench, in quotes, that measures how well different models are able to find areas of improvement in the T3 code codebase. And I was very surprised to see that Grok 4 .7 came in second place and Fable was quite a bit lower. The reason why is pretty clear when you look at the number of supported unresolved and contradicted findings.
Astra and Grock47 both found eight things that could be improved and substantiated and supported its claims. GBD6Soul actually found nine things, but apparently they weren't quite as valid because the judge panel I had set up found it less quality overall. Fable found only five things in its two runs.
That's a big difference. Fable absolutely vetted the things and they all matter and are worth improving, but it just didn't find as much as the open AI models and help. Even Grock did.
But also you can see the gap with Opus 5 to 5 .5 here. Opus 5 .5 was almost twice as successful according to my judging system. And also didn't find any unresolved or contradicted things.
Where with Opus 5, it had four supportive findings and then two that weren't. So for every two findings that are valid, it has one that's bullshit. The point I'm trying to make is hopping between model families can be useful here.
And as much as I prefer coding with Fable and Opus, the review quality I get out of Astra is also really solid. and maybe even grok by the way so consider using grok for your reviews too one more important piece with the reviews though and i do this a lot you should ask the model to mark the things that it can't confirm so it can review and verify as much as possible ideally you give it the tooling it needs to open up a browser and check your changes or run the system and use computer use to verify it or a test suite that it can use or build to verify the things that it's concerned about so the model knows the code works But if there are things that cannot confirm for any of many reasons, whether it's like a tool that you need to use different hardware for, or it's just an environment variable, or it's a more subjective thing.
If you ask the model to let you know what things it can't verify, it will. And this is kind of the point we're at now. The models know your code base really well.
They know how to operate really well autonomously. They know how to get stuff done. They can even verify their changes.
They don't know how to work with a human yet. That's partially because the data doesn't exist. It's partially because this is still a new phenomenon.
But if you tell the model how to work with you and you tell it what you need and what you're expecting, it'll usually give it to you. Especially models like Opus 5 .5, Fable 5 .1, and GPT -6 Astra, mostly. Okay, this is a little bit of a silly call -out.
This is actually about how to use the cloud apps more effectively. And the first piece is to check the model picker says Opus 5 .5. This is making me feel like I should be reading this article.
So let's skip down to what to do when messages are flagged. Opus 5 .5 is the first Opus model to launch with Fable -level bio and cyber safeguards. In cloud apps as well as cloud code, most flagged messages move to older models, and your work goes on there.
Finding security vulnerabilities in source code is allowed, and everyday health and educational questions should still work. These safeguards can sometimes flag legitimate work, and we're tuning them to cut down on incorrect flags. If you're switched, here's what you'll see and what to do.
In the cloud apps, you'll get a notice that says you were switched to a different model. Quad answers on that model and the chat stays on it too. If you go back and choose 5 -5 again in the model picker, it might work.
It might flag again. Starting a new chat should avoid it. They also have settings for quad where you can turn off the auto switch and instead you'll get a pause or an error.
I'll be real. I have not hit as many flags recently. It doesn't seem like that big a deal, but to each their own.
One thing that is called out here is that you shouldn't ask the model to show its reasoning. This is a little annoying because sometimes I want the model to explain why it did a thing. And my like natural English way of doing that is, what was your reasoning for these changes?
That might flag as you asking it to share the reasoning traces, which Anthropic doesn't want to do because that can be used to distill their models. They don't want that, so they hide them. It is what it is.
As such, anything that mentions reasoning is risking getting a flag. I guess it's a cute little checklist at the end here. make sure you tell the model what done looks like don't tell it to think hard it will anyways design requests should have the styles to leave out as well as what you want it to look like charts and screenshots should be attached yeah i think it will underrate how useful screenshotting is half the time i would need to give a model like context on an error i don't copy paste the error i just screenshot the browser and paste that they're good at reading these things and cloud code even has tools where if the screenshot is too high res and it can't read the text it will crop to the area it needs to get the context it needs The other sections we've spent this whole video going through, but if you do want to read this and check it yourself, the link is in the description as always.
This is a pretty fun article, and I'm thankful to see once again that Anthropic and I are pretty aligned on the best way to use these models. We're now at the point where we need to give our agents more leash. They need to have the ability to verify their changes.
They need to be told when done is done and given enough trust to go do the thing. I talk about a lot of these layers in a video coming out soon, all about how Anthropic made the performance for the Claude site and desktop app three times faster because the systems you build to verify these changes are just as important as the raw source code itself.
Hopefully this video will help you maximize your usage of Opus 5 .5. It really is a great model. And the more you trust it, the more you give it the things it needs to trust its own work, the further it can go and the more you can build.
I hope this was helpful. And until next time, peace nerds. Also, do not touch max mode.
Seriously, it's so bad.
The Hook
The bait, then the rug-pull.
Opus 5.5 has been out for a bit, and Theo is convinced it's genuinely good, so when a former Chrome team member turned Anthropic educator published a usage guide, he read it live and checked every claim against his own agent runs, including one that quietly burned six and a half hours on the wrong reasoning setting.
Frameworks
Named ideas worth stealing.
02:31list
Three Things to Try First
Hand over the whole task and define what done looks like
Delete 'think carefully' lines from your prompts
When a long run ends, read what it needs from you first
Addy Osmani's opening exercise for a first session with Opus 5.5, meant to reset habits built around older, more hand-held models.
Steal forthe first prompt you send to any new coding agent session
10:41model
What / Why / How Prompt Structure
What to do
Why it matters on Opus 5.5
How to execute it
The three-part shape the blog post uses for every tip, and the shape Theo recommends copying into prompts: the ask, the finish line, and the one condition under which the model should stop and ask.
Steal forstructuring any agent prompt so the model always knows what done looks like
CTA Breakdown
How they asked for the click.
VERBAL ASK
28:12next-video
“I talk about a lot of these layers in a video coming out soon, all about how Anthropic made the performance for the Claude site and desktop app three times faster.”
soft tease for a future video with no hard subscribe ask, delivered right before the sign-off line
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
Theo spends forty minutes inside Anthropic's own Fable 5.1 prompting guide, rebuilding his habits around effort levels, finishing the whole task, and trusting the model's defaults instead of babysitting them.
A developer who shipped 89 merged PRs in 24 hours breaks down Claude Fable 5.1's pricing, benchmarks and real-world coding behavior against Fable 5 and GPT-5.6 Sol.
Boris Cherny said coding is solved. Matt Pocock called it VC-funded bullshit. Theo argues they're both right, because they're using the word coding to mean two different things.
Theo spends a week testing two rival "skills" repos for AI coding agents, Matt Pocock's 215,000-star collection and Cursor engineer Lauren's PStack, and finds the real value in a handful of specific files, not the whole install.
Theo reacts line-by-line to Boris Cherny's post arguing that automation — CLAUDE.md rules, lint checks, CI — matters more than ever in the agent era, not less.
Theo runs OpenAI's GPT-5.6-Sol through Claude Code instead of Codex and gets visibly better designs and cheaper orchestration — then reads Codex's system prompt on camera to find out why.
00:32
00:53
01:36
01:58
02:14
03:02
03:24
03:45
04:07
04:28
04:50
05:33
05:54
06:16
06:37
06:59
07:21
07:42
08:04
08:25
08:47
09:08
09:30
09:51
10:13
10:34
10:56
11:17
11:39
12:22
12:43
13:26
13:48
14:09
14:31
15:14
15:35
15:57
16:29
16:33
17:44
18:04
18:27
19:03
19:41
19:53
20:15
20:58
21:19
21:41
22:03
22:46
23:07
23:29
23:50
24:12
24:33
24:55
25:38
25:59
26:21
26:42
27:04
27:17
27:55
28:32
41:32
55:06
33:48
38:21
19:12
30:48