Opus 5.5 no modo oficial: a Anthropic revela como aproveitar melhor o Opus

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Opus 5.5 OFFICIAL Super Mode: So, ANTHROPIC JUST REVEALED HOW TO MAKE Opus WAY BETTER! · Canal: AICodeKing · 11:04 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Engenharia de prompts e contexto, Engenharia de software com IA, Inferência e otimização de modelos

Resumo

O vídeo apresenta recomendações da Anthropic para obter melhores resultados com Claude Opus 5.5 em tarefas de programação. Entre elas estão definir claramente o que significa concluir uma tarefa, ajustar as instruções e o esforço do modelo, acompanhar o progresso e verificar os resultados com evidências. Também aborda o uso de subagents, orientações para interfaces, a troca de modelo após mensagens sinalizadas e os custos do fast mode. A recomendação geral é testar mudanças de workflow em uma tarefa real antes de pagar por respostas mais rápidas.

Pontos-chave

Descreva comportamentos concretos e critérios de conclusão para que seja possível avaliar se a tarefa foi realmente concluída.
Como o Opus 5.5 usa adaptive thinking, a recomendação é remover instruções genéricas como “pense com cuidado” e ajustar o esforço conforme a tarefa.
Use instruções de projeto para esclarecer quando o Claude Code deve continuar trabalhando e quando precisa pedir sua aprovação.
Acompanhe tarefas longas com uma lista de progresso, verificações concluídas, bloqueios e um breve resumo para retomar o trabalho.
Delegue investigações independentes a subagents quando forem grandes o bastante para justificar a coordenação e o uso extra de tokens.
Ao orientar o design de uma interface, especifique padrões que deseja evitar e descreva elementos concretos que atendam às necessidades de quem usa o app.
Peça evidências e diferencie verificações executadas de conclusões inferidas pela leitura do código; revise também o diff e teste o app.
Mensagens sinalizadas podem fazer a conversa passar para um modelo mais antigo; confira qual modelo está respondendo.
O fast mode pode acelerar a geração de texto, mas custa mais e não acelera tarefas como builds lentos.
Antes de mudar de plano ou pagar por velocidade, teste se uma solicitação mais clara resolve o problema.

Capítulos

Início	Capítulo	Resumo
00:02	Definir tarefas e ajustar as instruções	O vídeo recomenda especificar o comportamento esperado, os critérios de conclusão e o nível de esforço adequado, sem depender de instruções genéricas.
02:37	Manter o trabalho em andamento e delegar investigações	O apresentador mostra como orientar o Claude Code a continuar tarefas, registrar progresso e usar subagents em investigações independentes.
05:17	Orientar o design e verificar os resultados	O vídeo sugere dar instruções concretas sobre a interface e conferir mudanças com relatórios, revisão do diff e testes próprios.
07:57	Mensagens sinalizadas e troca de modelo	O apresentador explica que uma mensagem sinalizada pode levar a conversa a um modelo mais antigo e recomenda conferir qual modelo está ativo.
09:00	Velocidade, custos e recomendações finais	O vídeo compara os preços do fast mode com as tarifas padrão e conclui que é melhor testar instruções mais claras antes de pagar por respostas mais rápidas.

Citações

Uma barra de busca bonita, por si só, não atenderia ao pedido. — 01:05

Escrever uma frase em um arquivo não impõe, por si só, um limite de permissões. — 03:11

Isso proporciona uma conversa sobre design muito melhor do que pedir repetidamente algo mais premium. — 05:50

Esse tipo de verificação me convence muito mais do que uma mensagem confiante dizendo que está tudo funcionando. — 07:25

Eu começaria com uma tarefa real e deixaria o resultado fácil de verificar. — 10:00

Conceitos e entidades

Claude Opus 5.5 (modelo): Modelo da Anthropic discutido no vídeo, com recomendações para tarefas de programação e outras atividades.
Anthropic (empresa): Empresa que publicou o guia sobre como obter melhores resultados com Opus 5.5.
Addy Osmani (pessoa): Autor do artigo citado, publicado no blog de desenvolvedores da Claude.
Claude Code (ferramenta): Ferramenta de programação mencionada no vídeo, que pode usar instruções de projeto e subagents.
adaptive thinking (conceito): Recurso descrito no vídeo como sempre ativado no Opus 5.5, com o nível de esforço controlando quanto trabalho o modelo dedica à resposta.
subagent (conceito): Agente com contexto próprio que pode investigar uma parte independente do trabalho e devolver suas descobertas à conversa principal.
fast mode (ferramenta): Modo do Claude Code que usa o mesmo modelo para gerar respostas mais rapidamente, com tarifas mais altas.
tasks.md (repo): Arquivo sugerido para registrar trabalho pendente, verificações concluídas e bloqueios.

Tradução completa (pt-BR)

00:02 [música] >> Oi. Bem-vindos a mais um vídeo. A Anthropic publicou um guia sobre como aproveitar melhor o Claude Opus 5.5, e uma das recomendações é remover aquelas instruções que dizem ao modelo para pensar com cuidado. Também há algumas mudanças úteis que você pode fazer se o Claude Code continuar parando no meio de uma tarefa ou produzindo sempre o mesmo frontend genérico. O artigo é de Addy Osmani, no blog para desenvolvedores da Claude. Vou deixar o link abaixo, junto com a documentação. Quero passar pelas recomendações que importam para a programação do dia a dia e mostrar como eu as transformaria em um fluxo de trabalho prático

00:34 de trabalho. Também há duas coisas a observar. Uma mensagem sinalizada pode transferir sua sessão para um modelo mais antigo, e o modo rápido tem um custo separado. Então, vamos direto ao assunto. Primeiro, dê ao Claude uma tarefa com uma definição clara de concluído. A Anthropic posiciona o Opus 5.5 para tarefas de programação mais longas, o que torna o pedido inicial mais importante, porque o modelo precisa saber até onde você espera que ele vá. Digamos que estamos adicionando uma busca a um aplicativo de notas. Eu descreveria o comportamento. A busca deve encontrar correspondências nos títulos e no conteúdo das notas, ignorar maiúsculas e minúsculas,

01:05 e atualizar os resultados quando eu editar uma nota. Uma busca vazia deve mostrar todas as minhas notas, e uma busca sem correspondências deve exibir uma mensagem útil. Depois, eu pediria que implementasse esse comportamento, verificasse no aplicativo em execução e informasse quais verificações não conseguiu concluir. Também diria que qualquer mudança na forma como as notas existentes são armazenadas exige uma conversa prévia. Esse é um pedido que posso avaliar quando o agent voltar. Posso testar um título, uma palavra do meio de uma nota, editar a nota e ver se os resultados são atualizados. Uma barra de busca bonita, por si só, não atenderia ao pedido. Você não

01:36 precisa de uma especificação enorme para tudo, mas os poucos detalhes que determinam se você aceitaria os resultados devem estar presentes antes de o modelo começar. Agora, sobre aquelas instruções de pensamento. O pensamento adaptativo está sempre ativado no Opus 5.5. A configuração de esforço controla quanto trabalho ele dedica a uma resposta, e o padrão do modelo é médio. A Anthropic recomenda remover de prompts salvos instruções genéricas como “pense com cuidado”. Eu revisaria as instruções que acumulei ao longo do tempo e perguntaria se cada uma ainda tem uma finalidade. Um requisito específico

02:06 para verificar casos extremos é útil. Repetir que o modelo deve ser extremamente inteligente não diz muita coisa sobre o meu aplicativo de notas. Eu começaria com esforço médio e compararia os resultados nas minhas próprias tarefas. Se um bug difícil precisar de mais trabalho, aumentaria o esforço. Um esforço maior pode usar mais tokens e demorar mais, então eu não colocaria automaticamente toda pequena edição na configuração máxima. O mesmo vale para explicações. Peça que explique uma decisão, descreva uma suposição ou mostre um cálculo que você precise verificar. Você pode obter uma explicação útil sem pedir uma transcrição do raciocínio interno privado dele.

02:37 Agora, vamos falar de uma das coisas mais irritantes nos agents de programação: parar quando ainda há trabalho óbvio a fazer. Para preferências recorrentes, o Claude Code lê suas instruções no Claude.md. É lá que eu colocaria uma regra curta sobre continuar com o trabalho rotineiro e perguntar quando uma decisão realmente depender de mim. Para o nosso aplicativo de notas, minha instrução seria algo como: continue com o restante do comportamento de busca após cada verificação bem-sucedida. Se uma parte estiver bloqueada, explique o impedimento e trabalhe no que for independente. Pergunte antes de mudar o formato de armazenamento ou excluir notas existentes. Esses limites dependem do projeto. Se eu estiver aprendendo uma nova base de código, talvez

03:11 prefira uma explicação breve antes de cada mudança. Se já concordei com a implementação, quero que ele conclua o trabalho que puder fazer. Mas o Claude.md é uma orientação para o modelo. Mantenha as verificações de permissão das ferramentas de que você precisa, especialmente para comandos destrutivos. Escrever uma frase em um arquivo não impõe, por si só, um limite de permissão. Para tarefas mais longas, mantenha o progresso em algum lugar que você possa inspecionar. Eu pediria ao Claude que mantivesse um arquivo tasks.md com o trabalho restante, as verificações concluídas e quaisquer impedimentos. O Claude Code resume o conteúdo de conversas antigas conforme a sessão se preenche, então um arquivo dá à próxima etapa do trabalho algo concreto para consultar.

03:41 Para este exemplo, eu gostaria de ver se a busca funciona com notas editadas, se os resultados vazios funcionam e se as verificações no navegador foram executadas. Se a lista disser que tudo está concluído, mas o teste no navegador ainda estiver pendente, sei exatamente o que perguntar. Também pediria que registrasse uma breve passagem de contexto antes de parar: o que mudou, o que falhou e de onde retomaria. Isso seria útil se eu encerrasse a sessão e voltasse no dia seguinte. E, se você se lembrar de um requisito enquanto o Claude Code estiver trabalhando,

04:13 pode enviar uma mensagem de acompanhamento. Por exemplo, eu poderia acrescentar que a busca deve lidar com caracteres acentuados. Mantenha essa mensagem específica para que o agent saiba qual parte da tarefa ela altera. Agora, subagents podem ajudar quando o trabalho tem partes independentes. O Claude Code dá aos subagents seu próprio contexto, e eles retornam as descobertas à conversa principal. Para um aplicativo maior, eu poderia pedir a um deles que investigasse como as notas são carregadas e a outro que examinasse os testes de busca existentes. Eu manteria essas atribuições restritas. O primeiro deveria informar qual código carrega as

04:45 notas e quais suposições ele faz. O segundo deveria informar quais comportamentos os testes cobrem e o que está faltando. Então, o agent principal pode usar essas descobertas para planejar a mudança. Em uma revisão que abranja vários serviços, investigações separadas podem ocorrer em paralelo. Mas eu ainda pediria ao agent principal que verificasse as evidências antes de aceitar cada descoberta. Um relatório deve apontar para o código relevante ou para uma falha que possa ser reproduzida. Eu não montaria uma equipe para mudar o rótulo de um botão. Há um custo de coordenação, e agents extras podem aumentar o uso de tokens. Use-os quando as investigações separadas forem grandes o suficiente para justificar isso. Agora, o

05:17 conselho sobre frontend é algo de que gosto particularmente. A Anthropic diz que pedidos vagos para evitar uma aparência genérica de IA podem simplesmente resultar em outro estilo padrão. Ela recomenda nomear os padrões que você quer excluir. Eu iria um pouco além e descreveria o que quero usar. Para o nosso aplicativo de notas, eu pediria uma barra lateral compacta, texto legível e um campo de busca sempre visível. Não quero um enorme painel de boas-vindas ocupando metade da tela toda vez que abro minhas notas. Também pediria que a contagem de resultados ficasse ao lado do campo de busca, que houvesse um estado de foco do teclado visível e espaço suficiente para ler um trecho útil

05:50 de cada resultado. Essas escolhas vêm do que alguém precisa fazer no aplicativo. Depois, eu examinaria o resultado e daria feedback específico. Se a barra lateral estiver larga demais, diga isso. Se for difícil percorrer os trechos rapidamente, explique por quê. Acho que isso proporciona uma conversa sobre design muito melhor do que pedir repetidamente algo mais sofisticado. Capturas de tela também podem ajudar nessa conversa. A Anthropic relata melhorias na leitura de gráficos, diagramas e capturas de tela com o Opus 5.5. Você pode anexar a imagem e perguntar diretamente sobre os detalhes. Para uma interface visualmente carregada, eu perguntaria quais elementos competem pela atenção

06:20 e pediria mudanças relacionadas à captura de tela real. Para diagramas, pediria que identificasse as conexões que sustentam a resposta. E, para imagens densas, ainda forneceria uma versão legível. Uma compreensão visual melhor não torna rótulos minúsculos magicamente claros. O artigo também sugere usar o Claude para verificar documentos longos e pedir o arquivo final quando é disso que você precisa. Por exemplo, eu pediria uma planilha comparativa para download, com uma coluna para as fontes e um espaço separado para as informações ausentes. Assim, teria algo que posso inspecionar e compartilhar depois de verificar. Enfim, agora vamos falar sobre como verificar o resultado da programação. Eu abriria o relatório final para ver o que requer minha atenção.

06:53 Se o Claude não conseguiu executar uma verificação porque precisava de acesso, quero ver isso imediatamente. Posso incluir o formato de relatório que prefiro nas instruções do projeto. Para o aplicativo de notas, pediria que distinguisse as verificações que executou dos comportamentos que inferiu ao ler o código. Eu gostaria de ver o resultado dos testes relevantes, qualquer falha restante e uma breve explicação do que mudou. Depois, faria uma revisão separada do diff. Meu pedido se concentraria em falhas que afetam os usuários: resultados de busca desatualizados depois de editar, notas ausentes ou exclusões acidentais

07:25 mudanças nos dados armazenados. Eu pediria detalhes suficientes para reproduzir cada problema. Ainda tentaria usar o aplicativo por conta própria. Uma verificação útil seria criar uma nota com uma palavra distinta, pesquisá-la, alterar a palavra e pesquisar de novo. Se o resultado antigo continuar visível, encontrei algo que a revisão precisa resolver. Esse tipo de verificação me convence muito mais do que uma mensagem confiante dizendo que tudo funciona. E, se uma afirmação depender de um documento ou de uma fonte externa, quero saber o que o modelo realmente verificou. Há outra configuração que você deve entender antes de uma sessão longa. O que acontece quando uma mensagem é sinalizada?

07:57 Opus 5.5 tem salvaguardas adicionais para biologia e cibersegurança. Nos aplicativos Claude e no Claude code, a maioria das mensagens sinalizadas faz com que a conversa mude para um modelo mais antigo e continue nele. Você recebe um aviso, então preste atenção ao nome do modelo que aparece depois. No Claude code, use /model para selecionar Opus 5.5 novamente. Você pode alterar a preferência de troca automática com /config e informar uma sinalização incorreta com /feedback. Nos aplicativos Claude, a preferência de troca fica em configurações e, em seguida, em recursos.

08:29 Desativar a troca automática faz com que as conversas sinalizadas parem para você escolher o que fazer. As verificações podem incluir conteúdo anterior da conversa, arquivos anexados e resultados de pesquisa. Voltar ao modelo anterior pode acionar a mesma sinalização novamente. O guia também diz que trabalhos legítimos podem ser sinalizados por engano, então eu não presumiria que um aviso prova que há algo de errado com a solicitação. Para mim, é importante saber qual modelo está respondendo, especialmente se estou comparando resultados ou tentando entender uma mudança de comportamento. Eu verificaria isso antes de atribuir a resposta a Opus 5.5. Agora,

09:00 vamos falar de velocidade e custo. O preço padrão da API do Opus 5.5 é de US$ 4 por milhão de tokens de entrada e US$ 20 por milhão de tokens de saída. Essas são tarifas da API, então não as confunda com uma assinatura mensal do Claude. O Claude code também tem o modo rápido, que você pode ativar ou desativar com /fast. Ele usa o mesmo modelo, mas gera respostas mais rápido. A Anthropic o descreve como uma prévia de pesquisa, com velocidade de saída até 2,5 vezes maior no Opus 5.5. As tarifas listadas para o modo rápido são US$ 8 por milhão de tokens de entrada e US$ 40 por milhão de tokens de saída. Nos planos de assinatura,

09:30 o modo rápido exige créditos de uso pagos, mesmo que você ainda tenha uso incluído disponível. Portanto, essa não é uma opção gratuita para acelerar. Eu consideraria usá-lo quando estivesse esperando ativamente entre respostas e essa demora estivesse interrompendo meu trabalho. Se o agent estiver ocupado executando um build lento, gerar texto mais rápido não fará o build terminar antes. Eu testaria em uma tarefa real antes de decidir se o custo extra vale a pena. Há também uma dica mais específica para acompanhamentos lentos em conversas longas. A Anthropic diz que o Opus pode levar um tempo reconsiderando respostas anteriores. Você pode instruí-lo a se concentrar na pergunta atual e tratar as respostas anteriores como resolvidas, a menos que você as

10:00 reabra. Eu usaria isso de forma seletiva. Se estou fazendo uma análise longa em que novas evidências podem mudar uma conclusão anterior, quero que o modelo reavalie o trabalho. Não colocaria essa instrução em todos os projetos. No geral, acho que o ponto de partida mais útil é escolher uma tarefa real e deixar o resultado fácil de verificar. Diga ao Claude qual comportamento você espera, informe onde ele precisa da sua contribuição e peça evidências quando terminar. Você pode experimentar a maioria dessas mudanças no workflow com o acesso que já tem. Eu faria isso antes de pagar a mais por respostas mais rápidas. Um pedido mais claro talvez resolva o problema que você está enfrentando

10:33 sem mudar seu plano nem sua configuração de esforço. Vou deixar abaixo o guia original e a documentação de apoio. Conte nos comentários qual parte do seu workflow no Claude code dá mais trabalho: tarefas inacabadas, designs genéricos ou o tempo gasto verificando tudo depois. No geral, é bem legal. Enfim, deixe sua opinião nos comentários. Se você gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro clicando no botão de participar. Além disso, [música] deixe um gostei neste vídeo e inscreva-se no meu canal. Até o próximo. Até lá, tchau.

11:04 >> [música]

Transcrição original

[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]