Opus 5.5 OFFICIAL Super Mode: So, ANTHROPIC JUST REVEALED HOW TO MAKE Opus WAY BETTER!

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Opus 5.5 OFFICIAL Super Mode: So, ANTHROPIC JUST REVEALED HOW TO MAKE Opus WAY BETTER! · Channel: AICodeKing · 11:04 · Watch on YouTube

Topics: AI agents, Claude Code, Prompt and context engineering, Software engineering with AI, Model inference and optimization

Summary

The video walks through Anthropic’s guidance for getting more reliable results from Claude Opus 5.5, using a notes app as a running example. It recommends defining success clearly, removing generic “think carefully” instructions, managing long tasks with progress files, and using sub-agents only for substantial independent work. It also covers giving concrete design feedback, checking results with evidence, and understanding model switches after flagged messages. Finally, it explains fast mode’s added cost and suggests improving the task description before paying for faster output.

Key points

Define the expected behavior and what counts as finished before starting a coding task.
Remove generic saved instructions such as “think carefully”; use specific requirements and begin with medium effort.
Use Claude.md for recurring guidance, but keep actual tool permission checks for destructive actions.
For longer tasks, track completed checks, remaining work, blockers, and handoff notes in a file such as tasks.md.
Use narrowly scoped sub-agents for substantial independent investigations, and verify their findings against evidence.
Describe desired interface elements and give concrete feedback rather than simply asking for a less generic or more premium design.
Ask Claude to distinguish tests it actually ran from behavior it inferred, then review the diff and try the app yourself.
Check which model is responding after a flagged message, since most flagged messages in Claude apps and Claude Code switch to an older model.
Fast mode uses the same model with faster output, but has higher listed API rates and requires paid usage credits on subscription plans.
Consider clearer task instructions before increasing effort or paying for faster output.

Chapters

Start	Chapter	Summary
00:02	Set clear task goals and tune effort	The speaker explains how to define a coding task’s acceptance criteria and why specific instructions are more useful than generic requests to think carefully.
02:37	Keep long coding tasks on track	The video recommends project guidance, visible progress notes, handoffs, and carefully scoped sub-agents to help Claude complete longer jobs.
05:17	Give concrete design feedback and verify results	The speaker suggests describing desired interface details, using screenshots thoughtfully, and checking reports, diffs, and app behavior for evidence.
07:57	Understand model switches, speed, and cost	The video covers flagged-message model switching, fast mode pricing, and selective instructions for handling earlier answers in long chats.
10:00	Start with a checkable outcome	The speaker concludes that clear expectations and evidence are useful starting points before changing settings or paying for faster output.

Quotes

A nice-looking search bar by itself wouldn’t satisfy the request. — 01:05

Writing a sentence in a file doesn’t enforce a permission boundary by itself. — 03:11

It recommends naming the patterns you want excluded. — 05:17

That kind of check is much more convincing to me than a confident message saying everything works. — 07:25

Give Claude the behavior you expect, tell it where it needs your input, and ask for evidence when it finishes. — 10:00

Concepts and entities

Claude Opus 5.5, Anthropic, Addy Osmani, Claude Code, adaptive thinking, subagent, fast mode, tasks.md

Full transcript (original language)

00:02 [music] >> Hi. Welcome to another video. So, Anthropic has published a guide on getting more out of Claude Opus 5.5, and one of its recommendations is to remove those instructions telling the model to think carefully. There are also some useful changes you can make if Claude code keeps stopping halfway through a task or keeps producing the same generic front end. The article is by Addy Osmani on the Claude developer blog. I’ll link it below along with the documentation. I want to go through the advice that matters for everyday coding and show you how I’d turn it into a practical

00:34 workflow. There are also two things to watch. A flagged message can move your session onto an older model, and fast mode has a separate cost. So, let’s get right into it. First, give Claude a task with a clear definition of finished Anthropic positions. Opus 5.5 around longer coding jobs that makes the initial request more important because the model needs to know how far you expect it to go. Let’s say we’re adding search to a notes app. I’d describe the behavior. Search should match titles and note contents, ignore capitalization,

01:05 and update when I edit a note. An empty search should show all my notes, and a search with no matches should show a useful message. Then I’d ask it to implement that behavior, check it in the running app, and report any checks it couldn’t complete. I’d also say that changing how existing notes are stored requires a discussion first. That’s a request I can evaluate when the agent comes back. I can try a title, try a word from the middle of a note, edit the note, and see whether the results update. A nice-looking search bar by itself wouldn’t satisfy the request. You don’t

01:36 need a massive specification for everything, but the few details that determine whether you’d accept the results should be there before the model starts. Now, about those thinking instructions. Opus 5.5 has adaptive thinking enabled all the time. The effort setting controls how much work it puts into a response, and medium is the model’s default. Anthropic recommends removing generic instructions such as think carefully from saved prompts. I’d review the instructions I’ve accumulated over time and ask whether each one still has a purpose. A specific

02:06 requirement to check edge cases is useful. Repeating that the model should be extremely intelligent doesn’t tell it much about my notes app. I’d start with medium effort and compare results on my own tasks. If a difficult bug needs more work, I’d raise it. Higher effort can use more tokens and take longer, so I wouldn’t automatically put every small edit on the maximum setting. The same applies to explanations. Ask it to explain a decision, describe an assumption, or show a calculation you need to check. You can get a useful explanation without asking for a transcript of its private

02:37 internal reasoning. Now, let’s come to one of the more annoying things about coding agents, stopping when there’s still obvious work left. For recurring preferences, Claude Code reads your Claude.md instructions. That’s where I’d put a short rule about continuing through routine work and asking when a decision really needs me. For our notes app, my instruction would be something like continue with the remaining search behavior after each successful check. If one part is blocked, explain the blocker and work on anything independent. Ask before changing the storage format or deleting existing notes. Those boundaries depend on the project. If I’m learning a new code base, I might

03:11 prefer a brief explanation before each change. If I’ve already agreed on the implementation, I want it to finish the work it can do. Claude.md is guidance for the model, though. Keep the tool permission checks you need, especially around destructive commands. Writing a sentence in a file doesn’t enforce a permission boundary by itself. For longer jobs, keep progress somewhere you can inspect. I’d ask Claude to maintain a tasks.md file with the remaining work, completed checks, and any blockers. Claude Code summarizes older

03:41 conversation content as a session fills up, so a file gives the next stretch of work something concrete to read. For this example, I I to see whether search handles edited notes, whether empty results work, and whether the browser checks ran. If the list says everything is finished, but browser testing is still pending, I know exactly what to ask about. I’d also ask it to record a brief handoff before stopping. What changed, what failed, and where it would resume. That would be useful if I closed the session and came back tomorrow. And if you remember a requirement while

04:13 Claude code is working, you can send a follow-up. For example, I might add that search should handle accented characters. Keep that message specific so the agent knows which part of the task it changes. Now, sub-agents can help when the work has independent parts. Claude code gives sub-agents their own context, and they return findings to the main conversation. For a larger app, I might ask one to investigate how notes are loaded, and another to examine the existing search tests. I’d keep those assignments narrow. The first should report which code loads the

04:45 notes and what assumptions it makes. The second should report which behaviors the tests cover, and what’s missing. Then the main agent can use those findings to plan the change. For a review across several services, separate investigations can happen in parallel. But I’d still ask the main agent to check the evidence before accepting each finding. A report should point to the relevant code or a reproducible failure. I wouldn’t spin up a team for a button label. There’s coordination overhead, and extra agents can increase token usage. Use them when the separate investigations are large enough to justify it. Now, the

05:17 front-end advice is something I particularly like. Anthropic says that vague requests to avoid a generic AI look can just produce a different default style. It recommends naming the patterns you want excluded. I’d take that a little further and describe what I want to use. For our notes app, I’d ask for a compact sidebar, readable text, and a search field that stays visible. I don’t want a giant welcome panel taking up half the screen every time I open my notes. I’d also ask for the result count beside the search field, a visible keyboard focus state, and enough space to read a useful

05:50 excerpt from each match. Those choices come from what someone needs to do in the app. Then I’d look at the result and give specific feedback. If the sidebar is too wide, say that. If the excerpts are hard to scan, explain why. I think that gives you a much better conversation about design than repeatedly asking for something more premium. Screenshots can help with that conversation, too. Anthropic reports improved reading of charts, diagrams, and screenshots with Opus 5.5. You can attach the image and ask about the details directly. For a crowded interface, I’d ask which elements

06:20 compete for attention and request changes tied to the actual screenshot. For diagrams, I’d ask it to identify the connections that support its answer. And for dense images, I’d still provide a readable version. Better visual understanding doesn’t make tiny labels magically clear. The article also suggests using Claude to check long documents and asking for the finished file when that’s what you need. For example, I’d ask for a downloadable comparison spreadsheet with a source column and a separate place for missing information. That gives me something I can inspect and share after checking it. Anyway, now let’s talk about checking the coding result. I’d open the final

06:53 report at whatever needs my attention. If Claude couldn’t run a check because it needed access, I want to see that immediately. I can put my preferred reporting format in the project instructions. For the notes app, I’d ask it to distinguish checks it ran from behavior it inferred by reading the code. I’d want the relevant test result, any remaining failure, and a short explanation of what changed. Then I’d do a separate review of the diff. My request would focus on failures that affect users: stale search results after editing, missing notes, or accidental

07:25 changes to stored data. I’d ask for enough detail to reproduce each issue. I’d still try the app myself. One useful check would be to create a note with a distinctive word, search for it, change the word, and search again. If the old result stays visible, I found something the review needs to address. That kind of check is much more convincing to me than a confident message saying everything works. And if a claim depends on a document or an external source, I want to know what the model actually checked. There’s another setting you should understand before a long session. What happens when a message gets flagged?

07:57 Opus 5.5 has additional safeguards for biology and cybersecurity. In Claude apps and Claude code, most flagged messages cause a switch to an older model and the conversation continues there. You get a notice, so pay attention to the model name after it appears. In Claude code, use {slash} model to select Opus 5.5 again. You can change the automatic switching preference through {slash} config and report an incorrect flag with {slash} feedback. In Claude apps, the switching preference is under settings, then capabilities.

08:29 Turning automatic switching off makes flagged conversations pause for your choice. The checks can include earlier conversation content, attached files, and search results. Switching back may trigger the same flag again. The guide also says legitimate work can be flagged incorrectly, so I wouldn’t assume a notice proves there’s something wrong with the request. For me, knowing which model is answering matters, especially if I’m comparing results or trying to understand a change in behavior. I’d check that before blaming the output on Opus 5.5. Now,

09:00 let’s talk about speed and cost. Standard Opus 5.5 API pricing is $4 per million input tokens and $20 per million output tokens. Those are API rates, so don’t confuse them with a monthly Claude subscription. Claude code also has fast mode, which you can toggle with {slash} fast. It uses the same model with faster output. Anthropic describes it as a research preview with up to 2.5 times the output speed for Opus 5.5. The listed fast mode rates are $8 per million input tokens and $40 per million output tokens. On subscription plans,

09:30 fast mode requires paid usage credits, even if you have included usage remaining. So, this isn’t a free speed switch. I’d consider it when I’m actively waiting between replies and that delay is interrupting my work. If the agent is busy running a slow build, faster text won’t make the build finish sooner. I’d try it on a real task before deciding the extra cost is worthwhile. There’s also a more specific tip for slow follow-ups in long chats. Anthropic says Opus can spend time reconsidering earlier answers. You can tell it to focus on the current question and treat earlier answers as settled unless you

10:00 reopen them. I’d use that selectively. If I’m doing a long analysis where new evidence could change an earlier conclusion, I want the model to revisit its work. I wouldn’t put that instruction into every project. Overall, I think the most useful starting point is to take one real task and make the outcome easy to check. Give Claude the behavior you expect, tell it where it needs your input, and ask for evidence when it finishes. You can try most of these workflow changes with the access you already have. I’d do that before paying extra for faster output. A clearer request might resolve the problem you’re having

10:33 without changing your plan or your effort setting. I’ll leave the original guide and the supporting documentation below. Let me know which part of your Claude code workflow causes the most trouble, unfinished tasks, generic designs, or the time spent checking everything afterward. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the Super Thanks option or becoming a member by clicking the join button. Also, [music] give this video a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye.

11:04 >> [music]