Opus 5.5 roda sozinho por horas: guia prático

Opus 5.5 não quer microgerenciamento

Opus 5.5 é o primeiro modelo do Claude que realmente pune quem gerencia demais. Se você quebrar a tarefa em pedacinhos, ficar pedindo para pensar com calma e interromper o run a cada cinco minutos, vai ter latência maior, custo maior e resultado pior. O modelo foi feito para receber o problema inteiro, com uma linha de chegada clara, e trabalhar sozinho por muito mais tempo do que o Opus 5 aguentava. É uma mudança pequena de hábito, mas muda tudo no custo da sua atenção como operador.

Quem já testou em repositório grande relata o mesmo padrão: você passa uma migração completa, define o que significa pronto e deixa cozinhar. Horas depois, ele atravessa dezenas de arquivos, roda testes, corrige o que quebrou e te avisa de forma direta o que fez. Para quem constrói com IA todo dia, isso desloca o gargalo. O problema deixa de ser gerar código e passa a ser especificar bem, permitir continuar com segurança e conferir o resultado sem virar revisor de cada linha.

O fato

A Anthropic publicou um guia oficial de uso do Opus 5.5 no Claude e no Claude Code. A mensagem central é simples: o modelo trabalha por mais tempo de forma autônoma, relata com clareza o que executou e raciocina antes de cada resposta sem que você precise pedir. Por isso, parte do que funcionava antes agora atrapalha, como instruções do tipo pense passo a passo, prompts fatiados e regras vagas de design. O guia propõe novos hábitos: dar a tarefa completa de uma vez, remover comandos de raciocínio, direcionar no meio do run em vez de reiniciar, listar padrões visuais proibidos e configurar no CLAUDE.md quando ele deve seguir e quando deve parar e perguntar.

Como funciona na visão de quem opera

Na prática, o Opus 5.5 opera sempre com pensamento ligado. Ele decide sozinho quanto raciocinar antes de responder, o que na arquitetura deve significar um controlador interno de esforço que avalia complexidade, tamanho do contexto e risco antes de gastar tokens de raciocínio. É por isso que manter um pense com cuidado no prompt só adiciona latência no início da resposta sem ganho claro de qualidade nos testes da Anthropic em produto de chat. Se você quer resposta curta para pergunta simples, o caminho mais eficiente é dizer isso de forma explícita, como responda direto. No Claude Code, o ajuste fino passa pelo parâmetro de esforço, que deve controlar profundidade de busca, número de tentativas e quanto contexto ele carrega antes de agir.

O segundo ponto é a sustentação de runs longos. A maior evolução em relação ao Opus anterior está em trabalho multi-etapas, como migrar todos os endpoints de pagamento de um client antigo para um novo, deletar o client antigo e fazer a suíte de testes passar. Quando você nomeia a linha de chegada desse jeito, o modelo tem um critério de parada verificável e consegue encadear edições, execuções de teste e correções sem pedir confirmação a cada passo. Minha inferência técnica é que houve melhoria em memória de trabalho, uso de ferramentas e tolerância a erro, com mais orçamento de contexto e retomada de estado após falha de ferramenta. O custo provável é mais tokens intermediários e mais chamadas de ferramenta, então deixar cozinhar sem critério de pronto é pedir para queimar orçamento.

O terceiro ponto é direcionamento contínuo. Como os runs são mais longos, reiniciar custa caro em tempo e tokens. No Claude Code dá para digitar uma mensagem enquanto ele trabalha e apertar Enter, por exemplo para pedir que mantenha os nomes antigos de endpoints como apelidos. Isso sugere uma fila de instruções que é injetada no próximo ciclo de planejamento, sem derrubar o estado atual. Para o operador, isso muda o ritmo: em vez de planejar tudo perfeito antes, você lança uma boa versão inicial e corrige a rota no meio, como faria com um desenvolvedor júnior bom que já começou a codar.

Tem ainda a camada de controle operacional via CLAUDE.md. O Opus 5.5 tende a narrar o progresso, mas às vezes para para relatar em vez de continuar, com um resumo que cita o próximo passo sem executar, uma oferta de continuar ou uma lista de opções que não bloqueiam nada. Uma regra curta resolve a maior parte disso, algo como seguir quando não precisar da sua entrada, colocar status na mesma mensagem da próxima ação e só parar quando não der para continuar sem você ou antes de algo destrutivo como deletar dados, forçar push ou mexer fora do repositório. Para programação em par, vale o inverso: pedir um plano de uma linha antes de começar e um resumo curto no fim. E mantenha os prompts de permissão ligados para comandos destrutivos, porque autonomia maior exige trava maior.

O vício de design padrão

Na geração de páginas, apps e artefatos, o Opus 5.5 sem direção cai nos mesmos padrões: fundo creme ou off-white, palavra em itálico no título, rótulos numerados tipo 01 / 02 / 03, etiquetas em monospace e botões em pílula. Uma instrução genérica como evite visual genérico só troca um padrão por outro. O que funciona é listar de forma específica o que deixar de fora e depois iterar sobre o que ele escolheu no lugar. Isso indica um prior forte de estética aprendido no treinamento, que só é quebrado com restrição negativa explícita. Se você gera interface com frequência, vale salvar essa lista de proibições no seu arquivo de instruções para não repetir toda vez.

O que isso muda na prática

Quem ganha primeiro é quem vive migração e manutenção: trocar client, atualizar SDK, atravessar monorepo grande até os testes passarem. Esse trabalho era fragmentado porque o modelo perdia o fio, e agora dá para delegar o caminho inteiro com uma definição de pronto testável. Quem perde é quem acumulou um prompt cheio de muletas antigas, com pense passo a passo em todo lugar, microtarefas e instruções vagas de estilo. Esse setup vai parecer lento e caro no 5.5. Também muda a função do revisor. Você revisa menos o passo a passo e mais o diff final, os testes e os efeitos colaterais, o que exige disciplina de verificação.

A ação prática mais imediata é limpar e travar seu padrão operacional. Faça isso hoje no repositório onde você mais usa o Claude Code. Abra seu prompt salvo e seu CLAUDE.md, remova linhas de pense com cuidado, defina a linha de chegada de cada tarefa com condição verificável e adicione uma regra de continuação com limite de segurança. Um modelo simples que funciona bem é este:

• Defina pronto verificável: todo endpoint usa o client novo, client antigo deletado e suíte de testes passa sem erro inexplicado.
• Permita steering no meio: em vez de reiniciar, injete ajustes curtos enquanto o run roda e deixe o estado continuar.
• Trave autonomia segura: seguir sozinho por padrão, parar só se travar ou antes de ação destrutiva, com permissões ativas para comandos de risco.

Se o run parar com um quer que eu continue, responda continue uma vez e depois ajuste a regra para reduzir essas paradas. Para frontend, crie uma lista de padrões proibidos e refine a cada geração. Esse pequeno kit reduz interrupções, corta latência de primeira resposta e deixa o custo mais previsível porque você evita restarts longos.

A tensão que fica

A dúvida real não é se ele codifica bem em demo, e sim se essa autonomia escala no seu caos. Um run de horas que atravessa um repositório grande consome muito contexto, muitas chamadas de ferramenta e muitos tokens de raciocínio. Se a linha de chegada for vaga, ele pode andar em círculos, refatorar demais ou relatar progresso confiante com teste quebrado por motivo errado. A promessa de pedir ajuda só quando não consegue continuar sem você é ótima, mas depende de ele saber quando está travado de verdade. Na prática, autonomia sem verificação forte só move o gargalo de escrever código para auditar código. Vale a pena se você investir em testes que realmente provam algo, diffs pequenos por etapa e permissão restrita. Sem isso, o custo compensa no curto prazo e cobra depois em retrabalho silencioso.

Conclusão

Opus 5.5 rende mais quando você especifica o destino, deixa ele dirigir e confere o resultado com rigor. A pergunta que fica é direta: seus testes e suas travas de segurança aguentam um agente que trabalha horas sem te chamar.