▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=ejjBbaq9RmY
• Original title :: Getting the most out of Opus 5.5

Theo walks through Anthropic's "Getting the most out of Opus 5.5" guide (written by Addy Osmani, ex-Chrome, now at Anthropic) and annotates each recommendation with his own experience running long agent sessions in T3 Code. The through-line: Opus 5.5 works autonomously for much longer than its predecessors, so the leverage has moved from telling it how to work to telling it when it is done, what you don't want, and when it is allowed to stop and ask.

Say what done looks like

The single most important prompting change: name the finish line. Instead of "start working on this feature", write the whole task in one message with an explicit completion state - "migrate the payments endpoint to the new client; 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 you can't explain." Theo's formula is what you want, what done means, and an out. The higher-tier models from Anthropic and OpenAI will keep grinding until they reach a stated end state; without one they stop at arbitrary points to ask permission.

He demonstrates with a real prompt that moved a build onto a remote machine: he named the machine, pointed at the repo that documents how to connect (so the model wouldn't improvise something that trips security), listed the three things to verify, explicitly pre-authorised the scary bit (copying environment variables) so the model wouldn't halt for permission, stated what he did not want (no computer-use windows popping up on the laptop he's working on), and closed with "don't hesitate to ask questions if anything doesn't work." That last sentence matters because these models are RL'd hard against giving up - left alone, a confused model will try to answer its own question and blast ahead. Giving it an explicit out makes it willing to stop.

Stop telling it to think hard

Reasoning levels are caps, not quotas: low/medium/high/xhigh all say "think up to this much and then stop". Max is different - it removes the model's ability to think less. Theo's SkateBench numbers: xhigh averaged 338 tokens and 6s per response (slowest 31s); max averaged 5,000 tokens and 50s (slowest 600s), 13x the cost and 15x the tokens, for exactly one more correct answer (78% → 79%). His advice is to leave it on high or xhigh - the difference between the two is barely perceptible - and never use max. Also delete "think carefully" from your prompts; the model already thinks before every reply.

Steering instead of restarting

Because runs are long, restarting a thread is expensive. Older models handled mid-run messages badly: the RL was per-message, so an interruption would make the model do only the new thing and treat the earlier tasks as finished. Current models (Opus, Fable, and mostly Astro) treat interruptions as steering rather than as a new task, so typing a correction while it works is now the right move.

Design direction: say what you don't want

With no direction Opus 5.5 falls back on a handful of default styles, and a vague "avoid generic looks" just swaps one default for another. Its actual strength is following specific design constraints, including negative ones - "don't use cream backgrounds, italic accent words, numbered section labels, monospace labels, or pill buttons". Theo adds a workflow he uses constantly: screenshot the UI, draw an arrow on it, paste it in with "this sucks, make it better" - which works far better than it has any right to.

Naming the stops in CLAUDE.md

Opus 5.5 keeps you posted as it works, and on long tasks it sometimes stops to report rather than continue. The fix is a rule in CLAUDE.md that names which stops you want. Theo pastes Anthropic's suggested wording into his own config live: when a step doesn't need my input, keep going; put status notes in the same message as the next action; stop and ask only when you genuinely can't continue, or before anything destructive - deleting data, force pushing, or changing anything outside this repo. Pair programming wants the opposite rule (a one-line plan up front, a short recap at the end), but Theo's mode is fire-and-forget.

He also notes Opus 5.5 is less willing to spin up subagents than previous versions unless told it may - so for audits, migrations, and big review piles, say so explicitly.

Checking the results

When a long run ends, look first for anything the model is waiting on you for, then read the summary. Opus 5.5 reports more clearly than Opus 5 did, so the summaries are worth reading. Theo's most-used follow-up prompts: "what's the status of this work and what do you need from me?" and - his favourite - "what are the risks of merging this today? what's the worst thing that happens if we ship it right now?" For a 300-line agent-authored diff he doesn't intend to read, the risk answer tells him whether he needs to.

For review, he recommends crossing model families. OpenAI models still dig harder and report more, including noise, but catch things Claude misses entirely; on his own T3 Code improvement benchmark Astro and Grok 4.7 each found eight supported issues, GPT-6 Soul nine (lower quality), Fable only five. Opus 5.5 nearly doubled Opus 5's score and, unlike Opus 5, produced no unsupported findings. He also asks reviewers to explicitly mark what they could not verify, and gives them the tooling (browser, test suite) to verify the rest.

Safeguards and flags

Opus 5.5 is the first Opus to ship with Fable-level bio/cyber safeguards in both Claude apps and Claude Code. Flagged messages usually get silently routed to an older model; starting a new chat generally clears it, and the auto-switch can be disabled in settings. One practical gotcha: asking "what was your reasoning for these changes?" can trip the filter, because Anthropic hides reasoning traces to prevent distillation.

Takeaway

Theo's framing is that the models now know your codebase, know how to work autonomously, and can verify their own changes - what they don't yet know is how to work with a human, because that data doesn't exist. So tell them: what done means, what to avoid, when to stop, and when to keep going.