Eu estava no meio de uma refatoração em um projeto de cliente — 47 arquivos dentro de uma migração de monolito Laravel — quando o Claude Code simplesmente... continuou. Sem aviso de truncamento. Sem aquele corte constrangedor no meio de uma função onde o modelo fica sem fôlego e você precisa costurar a saída manualmente. Ele simplesmente escreveu. E escreveu. E terminou a classe de serviço inteira em uma única resposta.
Foi quando eu verifiquei a versão. Opus 4.6. E o limite padrão de tokens de saída tinha silenciosamente saltado para 64.000.
Eu vinha trabalhando com os padrões anteriores por meses, desenvolvendo memória muscular ao redor das limitações. Quebrando gerações complexas em pedaços menores. Fazendo prompts em etapas. Construindo andaimes mentais para contornar o teto. E de repente o teto estava três andares acima de onde eu vinha batendo a cabeça.
Essa única mudança já teria sido suficiente para escrever a respeito. Mas a Anthropic não parou por aí. A atualização do Opus 4.6 e Sonnet 4.6 é um dos lançamentos mais completos que já vi da equipe do Claude Code — abrangendo capacidade de tokens, gerenciamento de sessões, patches de segurança, ajustes de performance, arquitetura de plugins e uma longa lista de correções de terminal que me fizeram pensar se alguém tinha estado lendo meu rastreador pessoal de bugs.
Aqui está minha análise honesta de tudo que foi lançado, o que realmente importa para o trabalho do dia a dia, e as duas mudanças que acho que a maioria das pessoas vai ignorar completamente.
Por que esta atualização é diferente das anteriores
A maioria das atualizações de modelos parece incremental. Uma melhoria de benchmark aqui, uma pontuação ligeiramente melhor em seguimento de instruções ali. Você lê o changelog, acena com a cabeça e volta ao trabalho sem mudar nada no seu fluxo de trabalho.
Esta me forçou a mudar três coisas sobre como uso o Claude Code nas primeiras 48 horas. Não porque o jeito antigo parou de funcionar — porque as novas capacidades fizeram meus velhos padrões parecerem dirigir um carro esportivo em primeira marcha.
A expansão de tokens sozinha reestruturou como eu penso sobre engenharia de prompts para fluxos de trabalho agênticos. As melhorias de sessão mudaram como gerencio projetos de longa duração. E uma correção de segurança me deixou retroativamente nervoso com uma configuração de produção que eu vinha rodando por semanas.
Tenho testado tanto o Opus 4.6 quanto o Sonnet 4.6 em projetos reais desde que a atualização saiu — não benchmarks sintéticos, não exemplos de brinquedo, mas trabalho real de clientes e projetos pessoais. O que segue é tudo que aprendi, organizado pelo quanto vai realmente afetar seu fluxo de trabalho diário.
Vou começar pela mudança que mais importa.
Como 128K tokens de saída mudam os fluxos de trabalho do Claude Code?
O número manchete: Claude Opus 4.6 agora tem como padrão 64.000 tokens de saída por resposta. Tanto Opus 4.6 quanto Sonnet 4.6 suportam um limite superior de 128.000 tokens. E se você está no plano Claude, pode acessar até 1 milhão de tokens em contexto.
São números grandes. Mas números sem contexto são apenas marketing. Aqui está o que eles realmente significam na prática.
O fluxo de trabalho antigo (antes do padrão de 64K)
Com os limites de tokens anteriores, qualquer geração complexa exigia coreografia. Eu dividia um arquivo grande em seções, fazia prompt para cada seção individualmente, e depois combinava as saídas manualmente. Migrações de banco de dados com mais de 30 tabelas? Três ou quatro prompts separados. Uma suíte completa de testes para uma API com 15 endpoints? Eu agrupava em lotes de cinco.
A sobrecarga não era os prompts em si — era a perda de contexto entre prompts. Cada novo prompt começava ligeiramente desconectado do anterior. Convenções de nomenclatura desviavam. Declarações de import eram duplicadas ou esquecidas. O modelo não conseguia ver o panorama completo porque eu estava alimentando-o por uma fechadura.
A nova realidade
Com 64K como padrão e 128K como teto, tenho gerado camadas de serviço completas em passadas únicas. Na semana passada, pedi ao Claude Code para construir um sistema de notificações completo — a classe do modelo, a migration, a classe de serviço, os event listeners, o job de fila, o controller da API, a validação do form request e os testes PHPUnit. Um prompt. Uma resposta. Tudo internamente consistente porque o modelo conseguiu manter todo o contexto sem eu precisar fatiar.
A diferença de qualidade é perceptível. Quando o modelo consegue ver tudo que está gerando em uma única passada, o código é mais coeso. Nomes de variáveis permanecem consistentes. Métodos auxiliares são reutilizados em vez de reinventados. O tratamento de erros segue um único padrão por todo o código. É a diferença entre um arquiteto projetando um prédio versus cinco empreiteiros diferentes construindo cada um um andar sem conversar entre si.
Quando 128K realmente importa
Você não vai bater no teto de 128K em uso conversacional normal. Onde se torna crítico é em fluxos de trabalho agênticos — quando o Claude Code está lendo múltiplos arquivos, analisando um codebase e gerando saída, tudo dentro de uma única janela de contexto. Refatorações grandes em monorepos. Implementações full-stack que tocam frontend, backend e camadas de banco de dados simultaneamente. Geração de documentação que precisa referenciar dezenas de arquivos fonte.
Fiz um teste na semana passada: apontei o Claude Code para um projeto Laravel de 340 arquivos e pedi para gerar um site completo de documentação de API. Com os limites antigos, isso teria exigido um pipeline personalizado de operações fragmentadas. Com 128K tokens de saída disponíveis, o agente leu os arquivos de rotas, analisou os controllers, inspecionou os form requests e gerou documentação estruturada cobrindo cada endpoint — em uma única sessão sem bater no muro.
A janela de contexto de 1 milhão de tokens para usuários do plano Claude leva isso ainda mais longe. Você pode carregar codebases inteiros em contexto e operar neles como um todo unificado. Ainda estou explorando os limites do que é prático nessa escala, mas os primeiros resultados são promissores para tarefas de análise e refatoração de código em larga escala.
Mas a expansão de tokens é apenas metade da história. As melhorias de sessão são o que me fez repensar completamente meu fluxo de gerenciamento de projetos.
Gerenciamento de sessões: 45% mais rápido ao retomar e sessões com nome automático
Aqui vai uma dor de fluxo de trabalho que eu simplesmente tinha aceitado como normal: eu estava imerso em uma sessão do Claude Code, saía para almoçar, voltava, e a retomada da sessão demorava o suficiente para eu abrir uma nova aba do terminal e começar a verificar emails enquanto esperava. Em sessões grandes com contexto significativo, a retomada parecia lenta.
O Opus 4.6 reduz a velocidade de retomada de sessão em 45% e diminui o uso máximo de memória durante a retomada em até 150 MB. Os números soam abstratos até você experienciar. Minhas sessões de projetos grandes agora retomam no tempo que antes eu levava para decidir se esperava ou iniciava uma nova sessão. A decisão se faz sozinha — já está de volta.
Sessões com nome automático mudaram como organizo meu trabalho
Esta é sutil, mas está remodelando meu fluxo de trabalho diário. As sessões agora se nomeiam automaticamente com base no conteúdo do plano aceito. Em vez de ver uma lista de sessões rotuladas com timestamps ou identificadores genéricos, vejo nomes descritivos que me dizem exatamente o que cada sessão estava fazendo.
Antes desta atualização, eu tinha quatro ou cinco sessões concorrentes abertas e constantemente perdia a noção de qual estava cuidando da refatoração de autenticação versus a integração de API versus a configuração de deploy. Eu espiava cada uma, escaneava o contexto e me orientava. Dez a quinze segundos de fricção, repetidos dezenas de vezes por dia.
Agora dou uma olhada na lista de sessões e imediatamente sei onde tudo está. É o tipo de melhoria que não vira manchete mas economiza sobrecarga cognitiva real ao longo de um dia de trabalho completo.
O comando /branch renomeado
O comando /slashwalk foi renomeado para /slash branch, o que faz significativamente mais sentido semanticamente. Você está ramificando sua conversa, não caminhando por ela. O nome antigo é preservado como alias para que nada quebre, mas se está construindo memória muscular, comece a usar /branch agora.
O comando /copy também recebeu uma melhoria silenciosa — agora aceita um índice opcional para pegar a enésima resposta mais recente do assistente em vez de sempre pegar a mais recente. Funcionalidade pequena, mas já usei três vezes esta semana quando precisei pegar um bloco de código anterior que tinha sido empurrado para cima pela conversa subsequente.
Essas melhorias de sessão se acumulam. Retomada mais rápida significa menos fricção de troca de contexto. Sessões com nome automático significam menos sobrecarga cognitiva. Melhores comandos de cópia significam menos rolagem manual. Individualmente, cada uma economiza segundos. Juntas, ao longo de um dia completo de uso intenso do Claude Code, me economizam pedaços significativos de tempo focado.
Agora — aqui vem a parte desta atualização que me manteve acordado até meia-noite reauditando um ambiente de produção.
A correção de segurança que você precisa entender agora mesmo
Enterrado no changelog, entre os chamativos números de tokens e as melhorias de qualidade de vida, está um patch de segurança que merece mais atenção do que está recebendo.
A correção aborda uma vulnerabilidade onde hooks pre-tool-use podiam burlar regras de permissão de negação. Incluindo configurações gerenciadas corporativamente. Deixe-me explicar por que essa frase deveria te incomodar se você está rodando o Claude Code em qualquer ambiente com controles de acesso.
O que era realmente vulnerável
O sistema de permissões do Claude Code permite definir o que o agente pode e não pode fazer. Regras de negação devem ser limites rígidos — se você nega acesso a um diretório, o agente não deveria poder ler ou escrever lá. Ponto.
A vulnerabilidade significava que hooks pre-tool-use — código que roda antes de uma ferramenta ser executada — podiam contornar essas regras de negação. Em ambientes corporativos onde as regras de permissão são gerenciadas centralmente, isso significava que o limite de segurança não era tão sólido quanto os administradores acreditavam.
Era provável que isso fosse explorado acidentalmente? Provavelmente não. Mas em um cenário direcionado — digamos, um plugin malicioso ou um prompt projetado para exfiltrar dados de um diretório restrito — o bypass poderia ter sido aproveitado. A superfície de ataque existia, e em segurança, é isso que importa.
A nova configuração de sandbox permitida
Junto com a correção, a Anthropic introduziu uma nova configuração de sandbox permitida que restaura o acesso de leitura dentro de regiões negadas com controle mais granular. Esta é uma decisão de design inteligente. Em vez do modelo binário de permitir/negar, agora você tem um meio-termo: "negar escritas mas permitir leituras" para regiões específicas.
Isso importa para fluxos de trabalho onde o Claude Code precisa ler arquivos de configuração ou referenciar código em diretórios onde absolutamente não deveria fazer alterações. Anteriormente, você ou concedia acesso total (arriscado) ou negava todo acesso (limitante). A configuração de sandbox dá a precisão que ambientes de produção realmente precisam.
A correção de final de linha CRLF
Mais uma correção adjacente à segurança que vale mencionar: a ferramenta de escrita não mais converte silenciosamente finais de linha ao sobrescrever arquivos CRLF. Isso soa trivial até você ter lidado com isso. Se você trabalha em um ambiente misto — arquivos originados no Windows em um projeto que também tem arquivos com estilo Unix — a conversão silenciosa de finais de linha pode quebrar scripts de shell, corromper arquivos adjacentes a binários e criar bugs sutis que levam horas para rastrear.
O fato de a ferramenta estar convertendo silenciosamente sem informar o usuário é o verdadeiro problema. Modificação silenciosa de dados, mesmo bem-intencionada, erode a confiança nas ferramentas. Esta correção restaura o princípio de que a ferramenta deve fazer exatamente o que você pediu e nada mais.
Se preferir que alguém audite sua configuração de segurança do Claude Code e limites de permissão para um ambiente de produção, aceito trabalhos de revisão de segurança. Você pode ver o que construí em fiverr.com/s/EgxYmWD.
Certo, essa foi a seção que demandou atenção séria. O que segue é um conjunto de melhorias que são menos urgentes mas vão tornar sua experiência diária visivelmente mais suave.
Ganhos de performance: morte por mil milissegundos
Tenho uma teoria sobre ferramentas para desenvolvedores: as ferramentas que vencem a longo prazo não são as com funcionalidades mais chamativas. São as que eliminam micro-fricção tão consistentemente que você esquece que a fricção alguma vez existiu. Esta atualização acerta em cheio nessa filosofia.
Inicialização no macOS: 60 milissegundos mais rápida
Sessenta milissegundos parece insignificante. Não é. O Claude Code no macOS agora lê credenciais do keychain em paralelo em vez de sequencialmente durante a inicialização. Essa melhoria de 60ms acontece toda vez que você inicia a ferramenta. Se você inicia o Claude Code 20 vezes por dia — o que eu facilmente faço entre diferentes projetos, sessões de terminal e testes — isso é mais de um segundo de fricção diária removida.
Mais importante, é um sinal de prioridades de engenharia. A equipe está perfilando caminhos de inicialização e otimizando loops quentes. Essa disciplina se acumula através das versões.
Correção de crescimento de memória para sessões longas
Esta me atingiu de perto. Eu havia notado que sessões do Claude Code de várias horas consumiam gradualmente mais memória, eventualmente fazendo o ventilador do meu notebook acelerar e desacelerando outras aplicações. Eu vinha culpando o gerenciamento de memória do macOS. Acontece que era um bug no tratamento de sessões do Claude Code — a memória não estava sendo devidamente recuperada durante sessões de longa duração.
A correção significa que agora posso rodar sessões de dia inteiro sem a degradação gradual de performance que eu inconscientemente vinha contornando matando e reiniciando sessões periodicamente. Mais um ponto de fricção invisível, eliminado.
Mensagens de progresso sobrevivem à compactação
Quando o Claude Code compacta uma conversa para se manter dentro dos limites de contexto, mensagens de progresso costumavam desaparecer. Isso significava que durante operações agênticas longas — modificações de arquivos em múltiplos passos, processos de build complexos — você perdia visibilidade do que o agente tinha realizado se a compactação fosse acionada no meio da operação.
Mensagens de progresso agora persistem através da compactação. Você mantém visibilidade completa do trabalho do agente independentemente de quanto tempo a sessão dure. Para qualquer pessoa rodando fluxos de trabalho agênticos complexos de múltiplos passos, esta é a diferença entre confiança e ansiedade sobre o que está acontecendo por baixo dos panos.
Correção do rastreamento de custos
Uma correção mais silenciosa: o rastreamento de custos e uso de tokens agora está correto para fallback de API quando o modo non-streaming é usado. Se você estava monitorando seus gastos com API e os números pareciam ligeiramente incorretos, provavelmente é por isso. Não é um bug dramático, mas rastreamento preciso de custos importa quando você gerencia orçamentos de API em múltiplos projetos.
Essas melhorias de performance não vão parar no feed de ninguém no Twitter. Mas empilhadas juntas, representam uma experiência diária significativamente melhor. A ferramenta é mais rápida para iniciar, mais estável em sessões longas, mais transparente durante operações e mais precisa em seus relatórios.
Falando em transparência — as mudanças de ferramentas de plugins merecem sua própria seção.
Ferramentas de plugins: As mudanças que afetam desenvolvedores de plugins
Se você constrói ou mantém plugins do Claude Code, esta seção importa. Se apenas usa plugins, a versão curta é: as coisas devem quebrar menos e validar melhor. Pode pular para as correções de bash se quiser. Mas eu recomendaria ficar — entender como as ferramentas de plugins funcionam te torna um melhor usuário do ecossistema.
Melhor validação com plugin validate
O comando plugin validate ficou significativamente mais inteligente. Agora verifica o front matter de agentes de skills e comandos, escaneia hooks.json em busca de erros de parse YAML e detecta violações de schema. Anteriormente, você podia publicar um plugin com front matter malformado e não descobrir o problema até um usuário reportar comportamento estranho. A validação agora captura esses problemas antes do deploy.
Tenho rodado o validador atualizado contra meus próprios plugins e ele encontrou dois problemas que eu não sabia que existiam — um campo faltando no front matter de um skill e um hooks.json que tinha um erro sutil de indentação YAML. Ambos estavam funcionando "bem" na prática mas estavam tecnicamente malformados. O tipo de dívida técnica silenciosa que eventualmente causa problemas no pior momento possível.
Mudança de comportamento do agent tool
Esta requer atenção se você trabalha com agent tools programaticamente. O agent tool não aceita mais um parâmetro de retomada. Em vez disso, para continuar um agente parado, você envia uma mensagem com o ID do agente. O agente então auto-retoma em vez de lançar um erro.
O comportamento anterior era frustrante: se um agente parava e você tentava retomá-lo com o formato de parâmetro errado, recebia um erro em vez do agente simplesmente continuar de onde parou. A nova abordagem é mais tolerante e mais intuitiva. Agentes que param podem ser continuados simplesmente se dirigindo a eles, o que combina com como você naturalmente esperaria que a interação funcionasse.
Correção de cache de plugins em monorepos
Para equipes trabalhando em monorepos com múltiplos plugins em diferentes subdiretórios, havia um problema de colisão no cache de plugins. Dois plugins em diretórios irmãos podiam interferir no estado em cache um do outro. Isso agora está corrigido — cada plugin recebe seu próprio escopo de cache independentemente da estrutura de diretórios.
Esta é uma correção de nicho, mas se você foi afetado por ela, conhece a dor. Comportamento intermitente de plugins que depende de qual plugin carregou primeiro, invalidação de cache que cascateia incorretamente — debugar esses problemas é miserável. A correção elimina toda uma categoria de problemas "funciona na minha máquina" em configurações de monorepo.
O ecossistema de plugins está amadurecendo. Melhor validação, comportamento de agentes mais tolerante e isolamento de cache são todos sinais de que as ferramentas estão sendo construídas para uso sério em produção, não apenas demos e experimentos.
Agora vamos falar das correções que vivem mais perto de onde seus dedos encontram o teclado.
Correções de bash e terminal: O negócio sem glamour que mais importa
Vou dedicar mais tempo a esta seção do que você talvez espere, porque comportamento de terminal é onde eu passo minhas horas reais de trabalho. Um modelo pode ser brilhante, mas se a camada de terminal entre mim e o modelo tem fricção, toda interação sofre.
Comandos compostos finalmente funcionam direito
Esta correção aborda algo que vinha me incomodando silenciosamente por semanas. Quando você encadeava comandos — como cd seguido de npm test — o Claude Code às vezes salvava a regra de permissão para a string combinada completa em vez de tratar cada comando independentemente. Isso significava que você aprovava cd /project && npm test uma vez, e depois quando rodava apenas npm test separadamente, a permissão salva não se aplicava porque estava armazenada contra a string composta.
Agora cada comando em uma cadeia é avaliado independentemente. Aprove npm test uma vez, e fica aprovado seja rodando sozinho ou como parte de uma cadeia. Isso combina com como você intuitivamente esperaria que permissões funcionassem e elimina uma fonte de fricção do tipo "por que está me perguntando de novo?".
A eliminação de tarefas em segundo plano de 5 GB
Tarefas bash em segundo plano descontroladas que excedem 5 GB de saída agora são corretamente terminadas. Serei honesto — eu não sabia que isso era um problema até ler o changelog e pensar em uma sessão de duas semanas atrás onde meu terminal ficou irresponsivo durante um processo de build particularmente verboso. Acúmulo de saída em segundo plano provavelmente foi o culpado.
O limite de 5 GB é generoso o suficiente para que nenhum processo legítimo o acione, mas rígido o suficiente para impedir que uma tarefa descontrolada consuma toda a memória disponível. Bom padrão.
Espaços em caminhos de diretórios temporários
Bash não mais reporta erros falsos para comandos bem-sucedidos quando caminhos de diretórios temporários contêm espaços. Este é um clássico tropeço Unix — caminhos com espaços quebram suposições em scripts de shell em todo lugar, e os diretórios temporários internos do Claude Code estavam causando o mesmo problema. Se você já viu uma mensagem de erro depois de um comando que claramente teve sucesso, esta correção pode explicar.
Preservação da colagem
Conteúdo colado agora é preservado quando você começa a digitar imediatamente após colar. Antes desta correção, se você colava um bloco de texto e começava a digitar antes da colagem se registrar completamente, podia perder parte do conteúdo colado. A correção trata do manuseio do buffer de entrada — garantindo que eventos de colagem sejam completados antes que eventos de teclado sejam processados.
Correção pequena. Mas perder conteúdo da área de transferência no meio do fluxo de trabalho é o tipo de coisa que te faz questionar sua própria sanidade antes de questionar a ferramenta.
Correções do modo visual do terminal
Backspace e delete agora funcionam corretamente no modo visual normal (vnormal). A linha de status atualiza corretamente quando o modo visual alterna. Números de listas ordenadas renderizam corretamente. Caracteres CJK não mais sangram em elementos de UI adjacentes na borda direita.
Estas são correções de polimento, mas importam para qualquer pessoa que trabalha primariamente no terminal. A renderização de caracteres CJK, em particular, afeta um número enorme de desenvolvedores globalmente — ter caracteres cortando em elementos de UI vizinhos não é apenas feio, torna a interface mais difícil de analisar visualmente.
Melhorias de tmux e SSH
As correções de tmux merecem destaque porque muitos desenvolvedores — eu incluído — vivem dentro de sessões tmux. Cores de fundo agora renderizam corretamente com a configuração padrão do tmux. Não mais crashes ao selecionar texto dentro do tmux via SSH. Cópia para a área de transferência mostra uma notificação útil sobre se deve colar usando Cmd-Y ou o prefixo do tmux. Integração com IDE se autoconecta quando o Claude Code é lançado dentro do tmux ou screen.
Essa última é particularmente bem-vinda. Eu vinha reconectando manualmente a integração do IDE toda vez que lançava o Claude Code de dentro do tmux. A autoconexão elimina um passo que eu realizava tão habitualmente que tinha parado de notar a fricção — até ela desaparecer.
Integração com IDE: Correções pequenas, grande qualidade de vida
Algumas melhorias de IDE completam a atualização. Títulos das abas de preview de planos agora usam o cabeçalho real do plano em vez de um rótulo genérico "Claude plan". É a mesma filosofia das sessões com nome automático — dar ao usuário informação de relance em vez de fazê-lo clicar para se orientar.
Hyperlinks não mais abrem duas vezes no Cmd-click no VS Code, Cursor e outros terminais baseados em xterm.js. Se você vinha lidando com abas duplicadas do navegador toda vez que clicava em um link no terminal, esse era um bug conhecido, e está corrigido agora.
O rodapé agora linka para a configuração do macOS para forçar seleção com Option-click quando a seleção nativa não é acionada. Um pequeno toque de UX, mas mostra que a equipe está pensando na jornada completa do usuário — incluindo os momentos onde alguém fica confuso com o comportamento de entrada do macOS e precisa encontrar a configuração certa do sistema.
O que acho que a maioria das pessoas vai perder sobre esta atualização
Aqui vai minha opinião honesta após duas semanas de uso diário com essas mudanças.
A maioria da cobertura sobre esta atualização vai focar nos números de tokens. 64K padrão. 128K teto. 1 milhão de contexto. São cifras impressionantes e genuinamente mudam o que é possível. Mas também são as melhorias mais fáceis de entender e as mais difíceis de usar mal — mais tokens é diretamente melhor.
As mudanças que acho que terão o maior impacto a longo prazo são as mais difíceis de colocar em uma manchete.
A correção de segurança importa mais que a expansão de tokens para qualquer pessoa rodando Claude Code em equipe ou ambiente de produção. Bypasses de permissão são o tipo de vulnerabilidade que erode a confiança nas ferramentas, e confiança é a fundação sobre a qual tudo mais é construído. Se você gerencia deploys do Claude Code, audite suas regras de negação e confirme que o patch está aplicado.
As melhorias de gerenciamento de sessão — sessões com nome automático, retomada mais rápida, mensagens de progresso persistentes — se acumulam em uma experiência de trabalho fundamentalmente diferente ao longo de semanas e meses. Elas reduzem o imposto cognitivo de usar a ferramenta, o que significa que mais da sua energia mental vai para o problema real que você está resolvendo em vez de gerenciar a ferramenta em si.
E as correções de bash e terminal representam algo que valorizo profundamente em equipes de engenharia: a disposição de corrigir o chato. Manuseio do buffer de colagem. Espaços em caminhos. Renderização CJK. Armazenamento de regras de permissão para comandos compostos. Nenhum desses vai ser trending no Twitter. Todos eles tornam a ferramenta mais confiável para uso profissional diário.
Como tirar o máximo proveito do Opus 4.6 agora mesmo
Se você tem trabalhado com o Claude Code há um tempo, aqui está o que eu recomendaria fazer esta semana para aproveitar a atualização.
Primeiro, revisite qualquer fluxo de trabalho onde você estava quebrando prompts em pedaços por causa dos limites de saída. Tente rodá-los como prompts únicos agora. Provavelmente vai descobrir que o padrão de 64K lida com operações que você estava dividindo manualmente, e a qualidade da saída melhora por causa do contexto unificado.
Segundo, verifique sua configuração de permissões. Especialmente se está em um ambiente corporativo ou tem regras de negação personalizadas. Confirme que o patch de segurança está aplicado e teste seus limites. A nova configuração de sandbox te dá controle mais granular — use-a para substituir quaisquer regras de permitir/negar excessivamente amplas com escopo preciso.
Terceiro, deixe as sessões com nome automático trabalharem para você. Se vinha organizando sessões manualmente ou dependendo de timestamps para rastrear qual sessão cuida de qual projeto, pare. Deixe a funcionalidade de nome automático cuidar disso e redirecione essa energia organizacional para o trabalho em si.
Quarto, se trabalha no tmux, teste o comportamento de autoconexão. Se vinha reconectando manualmente a integração do IDE, verifique se a conexão automática está funcionando na sua configuração. Diferentes configurações de tmux podem interagir diferentemente com a autoconexão — melhor descobrir qualquer caso extremo agora do que durante um prazo apertado.
Quinto, rode plugin validate contra quaisquer plugins que mantém. A validação expandida detecta problemas que o validador antigo não encontrava. Corrija-os antes que seus usuários os descubram em produção.
A atualização do Opus 4.6 e Sonnet 4.6 não é uma única funcionalidade principal embrulhada em marketing. São cem melhorias de pequenas a médias que, combinadas, tornam o Claude Code uma ferramenta significativamente melhor do que era duas semanas atrás.
E honestamente? As melhorias que mais me empolgam são as que removeram fricção que eu tinha parado de notar. A velocidade de retomada de sessão que eu tinha aceitado como normal. O problema do buffer de colagem que eu tinha culpado o meu teclado. O passo de reconexão do tmux que eu tinha automatizado na minha cabeça. Quando uma ferramenta remove fricção à qual você se adaptou, ela não apenas melhora — ela te faz perceber quanta sobrecarga cognitiva você estava carregando silenciosamente.
Esse é o tipo de atualização que vale a pena documentar.
Qual é a primeira coisa que você vai tentar com 128K tokens de saída? Tenho alguns experimentos na fila que vou compartilhar quando tiver os resultados. Minha aposta é que o ponto ideal para a maioria dos desenvolvedores não é a contagem máxima de tokens — está em algum lugar por volta de 40-50K onde você obtém contexto unificado sem a latência de uma geração verdadeiramente massiva. Mas já estive errado antes, e estou ansioso para descobrir.
Perguntas frequentes
Qual é o limite padrão de tokens de saída para o Claude Opus 4.6?
Claude Opus 4.6 tem como padrão 64.000 tokens de saída por resposta, com um limite superior de 128.000 tokens. Usuários do plano Claude podem acessar até 1 milhão de tokens em contexto. Para uma análise completa de como isso muda os fluxos de trabalho reais, veja a seção de tokens de saída acima.
O Sonnet 4.6 recebe as mesmas melhorias de tokens que o Opus 4.6?
Tanto Sonnet 4.6 quanto Opus 4.6 suportam o limite superior de 128.000 tokens para saída. As melhorias de gerenciamento de sessão, patches de segurança e correções de terminal se aplicam igualmente a ambos os modelos. A diferença primária permanece o desempenho superior do Opus em tarefas de raciocínio complexo.
Quanto mais rápida é a retomada de sessão do Claude Code após esta atualização?
A velocidade de retomada de sessão melhorou em 45%, com até 150 MB menos de uso máximo de memória durante a retomada. As sessões também se auto-nomeiam com base no conteúdo do plano, tornando mais rápido encontrar e retomar a sessão certa.
A vulnerabilidade de segurança nos hooks pre-tool-use é séria?
A vulnerabilidade permitia que hooks pre-tool-use burlassem regras de permissão de negação, incluindo configurações gerenciadas corporativamente. Embora improvável de ser acionada acidentalmente, criava uma superfície de ataque real em ambientes com controles de acesso. O patch deve ser aplicado imediatamente em qualquer deploy de equipe ou produção.
O que mudou com a validação de plugins do Claude Code?
O comando plugin validate agora verifica o front matter de agentes de skills e comandos, hooks.json em busca de erros de parse YAML e violações de schema. Os agent tools também auto-retomam em vez de lançar erros quando continuados. Para as mudanças completas de plugins, veja a seção de ferramentas de plugins acima.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
