Opus 4.6 agora tem contexto de 1M de tokens: meus testes reais

Opus 4.6 agora tem contexto de 1M de tokens: meus testes reais

Eu estava 47 mensagens dentro de uma sessão do Claude Code na terça-feira passada — refatorando um monolito Laravel extenso em serviços de domínio — quando o modelo começou a alucinar nomes de funções que não existiam. Não nomes aleatórios. Nomes que quase correspondiam a funções reais de arquivos que eu tinha alimentado vinte minutos antes. O contexto tinha se degradado. O modelo estava se afogando na própria memória, confundindo o arquivo A com o arquivo B, inventando métodos com nomes plausíveis que não existiam em lugar nenhum da minha base de código.

Limpei o contexto, realimentei os arquivos críticos e comecei de novo. De novo. Pela terceira vez naquele dia.

Se você já usou qualquer modelo de linguagem grande para trabalho sério de programação, conhece exatamente essa dor. Você bate em um muro por volta dos 100K-120K tokens onde o modelo para de ser um colaborador e começa a ser um peso. Todo usuário avançado de Claude Code que conheço desenvolveu a mesma memória muscular: vigie a contagem de tokens, limpe cedo, reprima frequentemente. Funciona. Mas é exaustivo. E significa que você nunca pode realmente entregar ao modelo uma base de código massiva e dizer "entenda tudo isso".

Isso mudou em 13 de março de 2026. A Anthropic silenciosamente disponibilizou janelas de contexto de 1 milhão de tokens tanto para o Opus 4.6 quanto para o Sonnet 4.6 — um salto de 5x em relação ao teto anterior de 200K. E depois de passar três dias levando isso ao limite, posso dizer: esta não é uma melhoria incremental. Este é o maior avanço prático no Claude desde que comecei a usá-lo diariamente.

Mas o número bruto nem é a parte interessante. O interessante é quão pouco o modelo se degrada ao longo desse contexto massivo. E é aí que a história vale a pena ser contada.

O que é degradação de contexto — e por que 1M de tokens sozinho não resolve

Aqui está o segredo sujo que a maioria das empresas de IA não quer falar abertamente: uma janela de contexto maior não significa nada se o modelo não consegue realmente usar a informação que está nas bordas distantes dela.

Esse problema tem um nome. Degradação de contexto (context rot). É o fenômeno onde o desempenho do modelo se degrada — às vezes catastroficamente — conforme o contexto de entrada cresce além de um certo limiar. Pense nisso como ler um romance de 500 páginas de uma vez versus uma novela de 50 páginas. Na página 400, sua lembrança de um detalhe específico da página 12 é... vaga, no melhor dos casos.

Modelos anteriores sofriam muito com isso. Alimente o Opus 4.5 com mais de aproximadamente 100K tokens, e sua capacidade de lembrar detalhes específicos espalhados pela entrada despencava. O modelo tecnicamente aceitava 128K tokens. Mas aceitar tokens e realmente raciocinar sobre eles são coisas muito diferentes.

O Google fez a mesma aposta com o Gemini — janelas de contexto massivas que soavam ótimas em materiais de marketing mas rendiam de forma inconsistente quando você realmente precisava que o modelo encontrasse uma configuração específica enterrada em uma entrada grande. Testei o Gemini 3.1 Pro exatamente nesse tipo de tarefa. Os resultados não inspiraram confiança.

Então quando a Anthropic anunciou 1M de tokens, minha primeira pergunta não foi "quão grande?" Foi "quanto ele esquece?"

A resposta me surpreendeu. E é respaldada por um benchmark específico que acho que todo desenvolvedor deveria entender.

O teste das oito agulhas: por que este benchmark importa

A Anthropic usa um teste chamado avaliação das "oito agulhas". O conceito é direto mas brutal: espalhar oito informações específicas e distintas ao longo de um contexto de entrada massivo. Depois pedir ao modelo que lembre de todas as oito.

É como esconder oito frases específicas dentro de um documento de 3.000 páginas e pedir a alguém que encontre cada uma sem perder nenhuma. Não aproximadamente. Não "encontrei seis de oito". Todas as oito, com detalhes precisos.

Este teste importa porque mede algo que a maioria dos benchmarks ignora — a capacidade de manter uma lembrança granular ao longo de toda a janela de contexto, não apenas do início e do fim. Modelos que pontuam bem nas oito agulhas são modelos nos quais você pode realmente confiar com bases de código grandes, análise de documentos longos e sessões de refatoração multi-arquivo.

Aqui estão os números. Olhe-os com atenção:

Leia isso de novo. O Opus 4.5 pontuou 27,1 com aproximadamente 128K tokens. O Opus 4.6 pontuou 78,3 com um milhão de tokens. Isso não é apenas uma janela maior — é quase o triplo de efetividade de lembrança em quase oito vezes o comprimento de contexto. O modelo não está apenas aceitando mais tokens. Ele está realmente raciocinando sobre eles de uma maneira que a geração anterior não conseguia tocar.

E sim — o GPT 5.4 atinge aproximadamente a mesma pontuação nas oito agulhas. Crédito onde é devido. Mas o GPT 5.4 não publicou uma janela de contexto máxima clara, e nos meus testes, seu desempenho prático em sessões de programação muito longas não iguala exatamente os números dos benchmarks sintéticos. Mais sobre isso quando eu chegar aos resultados do mundo real.

Os números do Gemini 3.1 Pro também merecem destaque. O modelo do Google pontuou 26,0 — essencialmente empatado com a geração anterior Opus 4.5, apesar do Google promover a janela de contexto do Gemini como um diferencial chave. Janelas grandes, lembrança medíocre. Esse é o padrão que a Anthropic acabou de quebrar.

Aqui está a tradução prática: ao longo de 1 milhão de tokens, o Opus 4.6 mostra apenas uma queda de aproximadamente 14% em efetividade comparado com seu desempenho em 256 tokens. Pense nisso. Você pode alimentá-lo com quase mil páginas de código, documentação e histórico de conversa, e ele retém 86% de sua capacidade com contexto curto. Isso não é perfeito. Mas é utilizável de uma maneira que nenhum modelo anterior foi.

A regra dos 2%: uma heurística prática para gestão de tokens

Depois de rodar meus próprios testes junto com os benchmarks publicados, cheguei a uma heurística aproximada que tem sido precisa o suficiente para planejar: espere aproximadamente uma queda de 2% na efetividade para cada 100K tokens adicionais de contexto.

Em 100K tokens: ~2% de degradação. Quase imperceptível. Em 200K tokens: ~4% de degradação. Ainda extremamente sólido. Em 500K tokens: ~10% de degradação. Ocasionalmente você notará uma lembrança ligeiramente menos precisa. Em 1M de tokens: ~14% de degradação. Trabalhando mais, mas ainda funcional.

Isso é uma diretriz, não uma lei. A degradação real depende do que está no seu contexto — código homogêneo em uma linguagem se degrada diferentemente de uma mistura de documentação, código, configs e histórico de conversa. Mas como ferramenta de planejamento, a regra dos 2% se sustentou bem nos meus três dias de testes.

O que isso significa na prática: o conselho antigo de "limpe seu contexto em 100K-120K tokens" não é mais uma regra rígida. Você pode ir muito além agora. Deveria sempre chegar a 1M? Provavelmente não — e vou explicar por que na seção de implementação. Mas o teto operacional se moveu dramaticamente para cima.

A melhor prática anterior estava enraizada em dor real. Além de 120K tokens no Opus 4.5, você começava a ver o modelo confundir nomes de variáveis semelhantes, fundir detalhes de arquivos diferentes, ou "esquecer" restrições que você tinha definido no início da conversa. Esses problemas não desaparecem em 1M de tokens — mas foram empurrados tão longe que a maioria das sessões do mundo real nunca os encontrará.

Essa mudança transforma como eu estruturo todo o meu fluxo de trabalho. E provavelmente deveria transformar o seu também.

Como eu realmente uso isso no Claude Code diariamente

Teoria é legal. Como 1M de tokens se sente quando você está entregando código?

Passo entre quatro e dez horas por dia dentro do Claude Code. É meu ambiente de desenvolvimento principal — não um assistente que consulto ocasionalmente. Uso para tudo, desde escrever novas funcionalidades até depurar problemas em produção e refatorar estruturas inteiras de módulos. Antes da atualização de 1M de contexto, meu fluxo de trabalho era assim:

1. Inicio uma sessão com o prompt do sistema e arquivos chave (~15K tokens)
2. Trabalho nas tarefas, alimentando arquivos e recebendo saídas
3. Vigio o contador de tokens nervosamente
4. Por volta de 100K-120K tokens, noto os primeiros sinais de desvio — sugestões repetidas, nomes de variáveis ligeiramente errados, restrições esquecidas
5. Limpo o contexto, realimento arquivos críticos, perco o fio da conversa
6. Repito os passos 2-5 duas ou três vezes por tarefa principal

Agora? Inicio uma sessão e simplesmente... trabalho. Por horas. Sem a sobrecarga mental constante da gestão de contexto. A redução de carga cognitiva é difícil de exagerar. É como a diferença entre dirigir com um indicador de combustível sempre perto do vazio versus ter um tanque cheio. Você para de se preocupar com o recurso e começa a focar na estrada.

Aqui está um exemplo específico desta semana. Eu estava migrando uma aplicação SaaS multi-tenant de uma arquitetura de banco de dados compartilhado para um modelo de banco de dados por tenant. Isso envolveu mexer em 23 arquivos: models, migrations, middleware, arquivos de configuração, suítes de teste e scripts de deploy. Com a janela de contexto antiga, eu teria precisado de pelo menos três sessões separadas, cada vez reestabelecendo quais arquivos tinham sido modificados e qual era a estratégia geral de migração.

Com a janela de contexto de 1M, carreguei todos os 23 arquivos de uma vez (~85K tokens), mais a documentação de migração existente (~12K tokens), mais minhas notas de arquitetura (~8K tokens). Isso é aproximadamente 105K tokens só para o contexto inicial — já passando a antiga "zona de perigo". Depois trabalhei pela migração arquivo por arquivo, com o modelo mantendo perfeita consciência de cada mudança que tínhamos feito ao longo de toda a sessão. A sessão chegou a aproximadamente 340K tokens antes de eu terminar.

Nenhuma vez precisei limpar. Nenhuma vez o modelo confundiu uma query com escopo de tenant com uma global. Nenhuma vez tive que dizer "lembre-se, já mudamos o middleware no passo 4".

Essa sessão teria me tomado um dia inteiro com os limites de contexto antigos, entre a repreparação e a reexplicação e a correção de erros causados pela perda de contexto. Levou quatro horas.

Uma nota sobre o buffer de autocompactação do Claude Code

Uma coisa que me confundiu inicialmente: o Claude Code ainda usa um buffer de autocompactação de 33K tokens. Esta é a janela rolante de conversa recente que o modelo mantém na memória de trabalho ativa, separada do contexto mais amplo.

A janela de contexto de 1M não muda o tamanho deste buffer. O que ela muda é o contexto total que o modelo pode referenciar — seus arquivos, seu prompt do sistema, o histórico completo de conversa e o buffer de autocompactação combinados. O buffer ainda é 33K tokens de memória "quente", mas agora a memória "morna" se estende a 1M de tokens ao invés de 200K.

Na prática, isso significa que o modelo ainda é mais forte nas suas trocas mais recentes (o buffer) mas agora pode alcançar muito mais para trás no histórico de conversa e arquivos carregados sem perder o fio. A combinação funciona bem. Não senti necessidade de um buffer maior — a janela ativa de 33K lida com o vai e vem imediato, e o contexto expandido lida com todo o resto.

E o custo? A Anthropic tomou uma decisão inteligente

Aqui está algo que quase ficou enterrado no anúncio mas importa enormemente para quem roda sessões sérias de Claude Code: a Anthropic removeu o multiplicador de custo para contexto além de 200K tokens.

Anteriormente, usar contexto além da janela padrão vinha com uma penalidade de preço. O multiplicador exato variava, mas significava que uma sessão de 400K tokens custava significativamente mais por token do que uma sessão de 100K tokens. Isso criava um incentivo perverso — você era financeiramente penalizado por usar a capacidade total do modelo.

Agora? Preço fixo. Se sua sessão usa 9K tokens ou 900K tokens, o custo por token é o mesmo. Você paga pelo que consome, sem pagar premium por consumir muito.

Isso está disponível no plano Max do Claude Code, Teams e Enterprise. Se você está em algum desses planos — e se está lendo este blog, provavelmente deveria estar — a janela de contexto de 1M já está ativa. Sem feature flag. Sem lista de espera. Simplesmente está lá.

A mudança de preço importa porque remove a última barreira prática para realmente usar o contexto expandido. Antes, às vezes eu limpava o contexto cedo não porque o modelo estava se degradando, mas porque estava de olho na minha conta de API subindo. Esse cálculo acabou. Agora posso tomar decisões de gestão de contexto baseado puramente em qualidade, não em custo.

Se você prefere que alguém configure e otimize workflows do Claude Code para as necessidades específicas da sua equipe, aceito exatamente esse tipo de projeto. Você pode ver o que já construí em fiverr.com/s/EgxYmWD.

Minha estratégia de contexto recomendada para março de 2026

Tudo bem, você tem 1M de tokens disponíveis. Deveria usar todos eles, o tempo todo? Não. Aqui está a estratégia que adotei depois de três dias de testes deliberados.

Passo 1: Carregue seu contexto crítico logo de início

No começo de cada sessão, carregue os arquivos e a documentação que mais importam. Não vá dosificando — dê ao modelo a imagem completa de cara. Isso aproveita a zona de lembrança mais forte do modelo (o início do contexto) para sua informação mais importante.

Para uma sessão de programação típica, minha carga inicial fica assim:

- System prompt and project conventions (~5K tokens)
- Architecture documentation (~8-15K tokens)
- All files I expect to modify (~40-100K tokens)
- Related test files (~20-40K tokens)
- Recent git diff for context on what's changed (~5-10K tokens)

Isso é entre 80K e 170K tokens antes da primeira mensagem. Com o modelo anterior, isso me deixaria quase sem espaço para trabalhar. Agora é menos de 20% do meu contexto disponível.

Passo 2: Defina seu limiar pessoal de degradação

Baseando-se na heurística de 2% por cada 100K, decida quanta degradação é aceitável para você:

• Conservador (minimizar degradação): Limpe ou compacte por volta de 200K tokens. Você experimentará ~4% de degradação — essencialmente imperceptível no trabalho diário. Isso é o que eu recomendaria para refatorações críticas de produção onde a precisão não é negociável.

• Equilibrado (meu padrão): Trabalhe até 400K-500K tokens antes de considerar limpar. Com ~10% de degradação, o modelo ainda é altamente capaz, e você evita a perda de produtividade de repreparar. É onde eu opero para a maioria das sessões de programação.

• Estendido (máxima continuidade): Chegue a 700K-1M de tokens para sessões onde manter o fio completo da conversa importa mais que a lembrança máxima — como discussões exploratórias de arquitetura ou sessões longas de depuração onde cada tentativa anterior é contexto relevante.

Passo 3: Fique atento a sinais específicos de degradação

Mesmo com o manuseio de contexto melhorado, a degradação eventualmente aparece. Aqui está o que observar:

• Confusão de nomes de variáveis: O modelo começa a misturar variáveis com nomes semelhantes de arquivos diferentes. Esse geralmente é o primeiro sinal.
• Desvio de restrições: Instruções do início da sessão começam a ser parcialmente ignoradas. Você nota o modelo não seguindo uma regra de formatação ou pulando um passo que você tinha especificado.
• Fabricação confiante: O modelo afirma algo sobre seu código com confiança, mas está sutilmente errado — uma assinatura de função com a ordem errada de parâmetros, ou um método que existe em uma classe diferente da declarada.
• Sugestões repetitivas: Você pede uma abordagem nova e recebe algo muito parecido com o que ele já tentou. O modelo está perdendo o rastro do que já foi tentado.

Quando você detectar duas ou mais dessas em rápida sucessão, esse é seu sinal. Não espere piorar. Limpe o contexto, reprima com seus arquivos críticos e continue.

Passo 4: Use marcadores intencionais

Esta é uma técnica que desenvolvi especificamente para sessões longas. A cada 150K-200K tokens, deixo uma mensagem "marcador":

Quick checkpoint: we've completed [X, Y, Z]. Current state:
- File A: modified (added tenant scoping)
- File B: not yet touched
- File C: needs migration update
Next: work on File B's query layer.

Isso serve a dois propósitos. Primeiro, me força a organizar meu próprio pensamento sobre onde a sessão está. Segundo, dá ao modelo um resumo limpo e recente do estado do projeto que cai dentro do seu buffer de autocompactação. Mesmo que a lembrança de detalhes do início da sessão tenha se degradado ligeiramente, o marcador fornece um novo ponto de ancoragem.

Descobri que essa única técnica vale mais do que qualquer quantidade de contagem de tokens. Um marcador bem colocado em 300K tokens mantém o modelo mais afiado do que nenhum marcador em 200K tokens.

Por que acho que isso importa mais do que Loops ou Beat

Quero colocar isso em perspectiva. Nos últimos seis meses, a Anthropic lançou muitas funcionalidades para o Claude Code. Loops (a capacidade do modelo de executar e testar código iterativamente). Beat (a capacidade de lidar com tarefas em segundo plano). Melhorias no pensamento estendido. Refinamentos no uso de ferramentas. Tudo bom. Tudo coisas que uso diariamente.

Mas a janela de contexto de 1M é diferente em tipo, não apenas em grau. Eis por quê.

Cada outra funcionalidade melhora o que o modelo pode fazer dentro de uma única interação. Loops o torna melhor em iterar. Beat o torna melhor em multitarefa. Thinking o torna melhor em raciocinar. Todas tratam de capacidade em um ponto no tempo.

A expansão da janela de contexto melhora o que o modelo pode saber durante uma sessão. É sobre memória, não habilidade. E a memória se revela o gargalo que estava silenciosamente limitando tudo o mais.

Um modelo com capacidade perfeita de programação mas amnésia depois de 100K tokens é um modelo que só pode trabalhar em problemas pequenos — ou trabalhar em problemas grandes em pedaços pequenos e desconectados. Um modelo com a mesma capacidade de programação e 1M de tokens de memória confiável pode enfrentar projetos que antes estavam fora do alcance do desenvolvimento assistido por IA.

Estou falando de refatorações de aplicações inteiras. Mudanças de arquitetura multi-serviço. Migrações de padrões em toda a base de código. Auditorias de segurança que precisam cruzar cada endpoint de autenticação com cada verificação de autorização. Essas são as tarefas onde desenvolvedores humanos passam semanas e ainda perdem coisas. Também são as tarefas onde uma IA com contexto suficiente poderia encontrar padrões e inconsistências que nenhum humano pegaria.

Não estamos totalmente lá ainda. A degradação de 14% em 1M de tokens significa que você ainda precisa ser cuidadoso sobre como usa o contexto. Mas estamos perto o suficiente para eu ter começado a enfrentar tarefas com o Claude Code que eu teria considerado impossíveis três meses atrás.

O cenário competitivo torna isso ainda mais interessante. O GPT 5.4 está pescoço a pescoço no benchmark das oito agulhas com ~78 versus 78,3 do Opus 4.6 — uma diferença estatisticamente insignificante. Mas o modelo de preço fixo da Anthropic e a integração com o Claude Code dão uma vantagem prática para desenvolvedores que vivem no terminal. Usei ambos extensivamente. Em lembrança pura, são pares. Em integração de workflow para tarefas de programação, a implementação do Claude Code é mais fluida.

O Gemini 3.1 Pro, apesar do investimento massivo do Google em pesquisa de contexto longo, está uma geração completa atrás em qualidade de lembrança. Uma pontuação de 26,0 no teste das oito agulhas — quase idêntica à geração anterior Opus 4.5 — sugere que o Google resolveu o problema do tamanho da janela de contexto sem resolver o problema da qualidade de contexto. Janela grande, memória com furos. Essa não é uma combinação na qual eu confiaria para uma sessão de refatoração de 20 arquivos.

As limitações honestas — o que isso não resolve

Estaria mentindo se dissesse que a janela de contexto de 1M é só vantagem. Existem compromissos e limitações reais que você deveria conhecer antes de mudar seu fluxo de trabalho.

A latência aumenta com o tamanho do contexto. Mais tokens significa mais para processar em cada turno. Notei tempos de resposta praticamente dobrando entre 100K e 500K tokens de contexto. Em 800K+, há um atraso perceptível antes do modelo começar a gerar. Não é terrível — estamos falando de segundos, não minutos — mas se você está acostumado a respostas quase instantâneas com contextos curtos, o lag se nota.

Nem toda degradação é igual. A degradação média de 14% mascara uma variância significativa dependendo do que você está pedindo ao modelo para lembrar. Valores numéricos específicos (como números de porta ou strings de versão) enterrados fundo no contexto se degradam mais rápido que padrões estruturais (como "este módulo lida com autenticação"). Se seu trabalho depende de lembrança precisa de detalhes do contexto inicial, a degradação efetiva para seu caso de uso pode ser maior que 14%.

O buffer de autocompactação ainda é 33K. Isso significa que a memória de trabalho ativa do modelo não mudou. Se você está fazendo um vai e vem rápido sobre um problema específico, o buffer de 33K é sua restrição real, não a janela de contexto de 1M. O contexto expandido ajuda com a lembrança "fria" — alcançar algo de antes na sessão — mas não torna o modelo melhor em lidar com múltiplos fios ativos na conversa imediata.

Você ainda pode ultrapassá-lo. Consegui deixar o modelo genuinamente confuso durante uma sessão onde estava modificando simultaneamente arquivos interdependentes em três microsserviços. Por volta de 600K tokens, ele começou a sugerir mudanças no Serviço A que conflitavam com mudanças que já tínhamos feito no Serviço B vinte minutos antes. A técnica de marcadores ajudou, mas não eliminou o problema completamente.

Esses não são impedimentos insuperáveis. São o tipo de limitação que você aprende a contornar uma vez que as entende. Mas prefiro que você ouça de mim do que descubra durante um deploy crítico.

O que isso significa para os próximos seis meses

Venho construindo com ferramentas de programação com IA desde que o GPT-3.5 as tornou viáveis. Ao longo de todo esse arco, um padrão tem sido constante: os maiores saltos para frente sempre vêm de expandir o que o modelo pode manter em contexto, não de torná-lo marginalmente mais inteligente em uma tarefa única.

O salto de 4K para 32K tokens tornou a programação assistida por IA possível. O salto de 32K para 128K a tornou prática para projetos reais. O salto de 200K para 1M a torna viável para bases de código inteiras.

Estamos nos aproximando de um limiar onde um modelo pode manter sua aplicação inteira — cada arquivo, cada teste, cada config — em uma única janela de contexto. Para uma aplicação típica de médio porte (200-500 arquivos), já chegamos lá. Para grandes bases de código empresariais, estamos talvez a uma geração de distância.

Quando isso acontecer, a mudança no fluxo de trabalho é fundamental. Você para de pensar em "quais arquivos a IA precisa ver?" e começa a pensar em "o que devo pedir para a IA fazer em toda a minha base de código?" Isso é um tipo qualitativamente diferente de assistência ao desenvolvimento. É a diferença entre uma IA que te ajuda a editar um arquivo e uma IA que entende seu sistema.

Acho que vamos olhar para trás em março de 2026 como o mês em que essa transição começou para valer. Não porque 1M de tokens é o número final — não é. Mas porque é a primeira vez que o contexto foi grande o suficiente e a lembrança foi confiável o suficiente para fazer a assistência de IA em toda a base de código realmente funcionar.

Pela primeira vez na minha experiência, a janela de contexto não é o gargalo. E isso significa que o gargalo agora somos... nós. Nossa capacidade de fazer as perguntas certas, estruturar os prompts certos e projetar workflows que aproveitem o que de repente é possível.

Eu aceito esse compromisso. Sempre.

Perguntas frequentes

Como ativo a janela de contexto de 1M para o Claude Opus 4.6?

Nenhuma configuração necessária. A janela de contexto de 1M está automaticamente disponível no plano Max do Claude Code, Teams e Enterprise a partir de março de 2026. Se você está em algum desses planos, já está ativa.

Devo limpar o contexto em 200K tokens ou ir até 1M?

Para trabalho crítico de precisão como refatoração de produção, limpe por volta de 200K tokens. Para sessões exploratórias ou depuração longa, vá confortavelmente até 400K-500K. A heurística de 2% de degradação por cada 100K tokens ajuda a decidir. Para uma análise mais detalhada, veja Minha Estratégia de Contexto Recomendada acima.

A janela de contexto de 1M custa mais que a padrão de 200K?

Não. A Anthropic removeu o multiplicador de custo para contexto além de 200K tokens. O preço é fixo independente de sua sessão usar 9K ou 900K tokens. Veja E o Custo? acima para detalhes.

Como o Opus 4.6 se compara ao GPT 5.4 em tarefas de contexto longo?

Ambos os modelos pontuam aproximadamente 78 no benchmark das oito agulhas — estatisticamente empatados em lembrança pura. O Opus 4.6 tem uma ligeira vantagem na integração com o workflow do Claude Code e no preço fixo. Veja a tabela comparativa de benchmarks na seção do Teste das Oito Agulhas.

O que é o buffer de autocompactação do Claude Code e o 1M o muda?

O buffer de autocompactação do Claude Code permanece em 33K tokens — esta é a memória de trabalho "quente" para o vai e vem imediato. A expansão de 1M aumenta o contexto total referenciável, não o buffer ativo. Veja Uma Nota sobre o Buffer de Autocompactação do Claude Code para como os dois interagem.

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