A Compactação Ociosa do Claude Code Preserva o Cache, mas Retoma a Partir de um Resumo
A compactação ociosa do Claude Code agora pode resumir uma sessão grande antes que seu cache de prompt expire, mesmo quando a janela de contexto não está cheia. O recurso tem como alvo sessões que contêm pelo menos 200.000 tokens por padrão. Sua principal contrapartida é clara: Claude retorna a um contexto mais barato e curto, mas continua a partir de um resumo gerado, em vez de cada interação original.
A engenheira da Anthropic Lydia Hallie descreveu o comportamento em uma publicação sobre compactação ociosa de outubro de 2026. Os usuários podem desativar o recurso adicionando "idleCompaction": false a um arquivo de configurações do Claude Code. Eles também podem alterar o limite mínimo de contexto com CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.
Esse controle chegou depois que desenvolvedores relataram compactações inesperadas em sessões de longa duração. A preocupação não era a existência da compactação. O Claude Code já resumia conversas próximas dos limites de contexto. O conflito era se um temporizador de inatividade deveria substituir uma transcrição ainda utilizável para reduzir o custo de retornar após a expiração do cache.
A Compactação Ociosa do Claude Code Muda o Significado de Retomar
Uma sessão retomada pode manter sua identidade enquanto perde o histórico literal que originalmente a estabeleceu.
O Claude Code armazena mensagens de sessão localmente e permite reabri-las com --continue ou --resume. Essa persistência pode fazer uma sessão parecer um espaço de trabalho duradouro. No entanto, o modelo só raciocina sobre o contexto enviado em sua solicitação atual, e não sobre cada artefato armazenado no disco.
O guia sobre janela de contexto da Anthropic explica que o contexto ativo contém histórico de conversa, conteúdo de arquivos, saída de comandos, instruções de projeto, memórias, habilidades e instruções do sistema. À medida que esses materiais se acumulam, o Claude Code limpa saídas mais antigas de ferramentas e, eventualmente, resume a conversa.
Compactação é o ato de substituir materiais conversacionais mais antigos por um resumo mais curto. A sessão continua disponível, e Claude pode seguir trabalhando. Ainda assim, o modelo deixa de receber cada interação substituída palavra por palavra.
O novo caminho ocioso muda quando essa substituição pode ocorrer. A compactação automática tradicional responde a um orçamento de contexto cada vez menor. A compactação ociosa, por outro lado, responde à inatividade e ao tempo do cache de prompt, desde que a sessão seja grande o suficiente.
Os usuários começaram a relatar a mensagem “Compacted while idle, before the prompt cache expired” depois de deixar sessões sem supervisão. Os relatos associaram a implementação ao Claude Code 2.1.286, embora o comportamento fosse controlado em parte por uma ativação no servidor. Isso significa que instalar uma versão específica do cliente, por si só, não revelava necessariamente o estado completo da implementação.
O mínimo padrão relatado por Hallie e discutido no repositório público da Anthropic é de 200.000 tokens. Esse número é um limite de qualificação, não uma promessa de que a compactação ocorra precisamente quando a conversa alcançar 200.000 tokens.
Uma sessão qualificada também precisa das condições de cache relevantes e de tempo ocioso suficiente. A investigação da comunidade na issue sobre compactação ociosa constatou que o temporizador se aproximava do fim de um período de cache de prompt de uma hora. Os usuários observaram o evento visível cerca de 54 a 56 minutos após a última atividade.
Esses detalhes de tempo vieram de participantes da issue que examinaram o comportamento do cliente e executaram testes locais. A documentação pública do Claude Code da Anthropic não forneceu inicialmente uma especificação completa da compactação ociosa. Portanto, os leitores devem distinguir três níveis de evidência: a descrição da Anthropic sobre compactação, o anúncio da engenheira e a análise da comunidade sobre detalhes de implementação.
A consequência verificada para o produto continua clara em todas essas fontes. Após a compactação ociosa, Claude retoma a partir de um estado conversacional comprimido. A transcrição original ainda pode existir localmente, mas seu conteúdo completo deixa de estar automaticamente presente no contexto de trabalho do modelo.
Essa distinção importa porque a persistência local e a atenção do modelo resolvem problemas diferentes. Uma transcrição armazenada apoia auditoria e recuperação. O contexto ativo determina o que Claude pode considerar durante sua próxima resposta.
O Recurso Troca Fidelidade de Contexto por Eficiência de Cache
A compactação ociosa desloca o trabalho de um retorno potencialmente sem cache para uma janela final de cache aquecido, aceitando a perda do resumo para reduzir o processamento repetido de contexto.
O cache de prompt permite que solicitações repetidas reutilizem prefixos de entrada correspondentes. Um acerto de cache geralmente exige menos processamento de entrada do que reconstruir o mesmo prefixo grande após a expiração de sua entrada no cache. Sessões longas do Claude Code criam prefixos reutilizáveis excepcionalmente grandes porque cada interação pode incluir mensagens anteriores, atividade de ferramentas e material do projeto.
A documentação de cache de prompt da Anthropic descreve a duração do cache e o tratamento diferente de gravações e leituras de cache. Uma sessão longa que fica sem cache pode exigir que o Claude Code processe novamente um prefixo substancial quando o usuário retorna.
A compactação ociosa tenta intervir antes desse ponto. Enquanto o prefixo grande permanece em cache, o Claude Code pode pedir ao modelo que o resuma. Uma solicitação posterior começa com o resumo mais curto e quaisquer instruções ou materiais de projeto que o Claude Code restaure.
Esse mecanismo favorece a eficiência quando um usuário pretende retomar uma sessão grande após uma pausa. Em vez de retornar com todo o contexto antigo, o usuário retorna com uma representação comprimida que exige menos tokens para processar.
O custo é a fidelidade da informação. Resumos preservam fatos e decisões selecionados, mas não garantem a retenção exata de cada restrição, opção descartada, observação de teste ou correção conversacional.
A Anthropic reconhece a limitação geral em sua documentação sobre contexto. Ela afirma que solicitações e trechos importantes de código são preservados durante a compactação, enquanto instruções detalhadas de conversas anteriores podem se perder.
Esse aviso se torna mais relevante em uma sessão de programação agêntica. Uma instrução sutil pode definir qual caminho de migração é permitido. Uma hipótese rejeitada pode impedir Claude de repetir uma investigação cara. Uma pequena anomalia de teste pode explicar por que uma correção aparentemente óbvia não é segura.
Esses detalhes podem parecer secundários para um resumidor, mas continuar decisivos para a próxima etapa de programação. Um resumo pode descrever com precisão o objetivo amplo do projeto e ainda omitir as evidências que restringiam sua implementação.
O risco cresce em sessões longas e exploratórias. Um desenvolvedor pode pedir a Claude que inspecione vários módulos, compare projetos concorrentes, execute testes e abandone duas abordagens. A direção final pode depender de resultados negativos espalhados por saídas de comandos e correções breves.
Após a compactação, Claude pode se lembrar de que uma abordagem foi escolhida sem reter todos os motivos pelos quais as alternativas falharam. Então, pode reconstruir uma explicação plausível que difere da investigação real.
Isso não torna a compactação inerentemente defeituosa. Nenhum sistema finito de gerenciamento de contexto pode reter um histórico ilimitado literalmente. A disputa diz respeito ao momento e à intenção do usuário.
Perto de um limite rígido de contexto, a sumarização impede que a sessão pare. Antes da expiração do cache, o produto está escolhendo eficiência mesmo que a sessão ainda possa ter uma capacidade de contexto restante substancial.
Esse é o principal antagonista desta história: eficiência de cache versus fidelidade de contexto. Não se trata de Claude Code contra outro assistente de programação. Todo agente de longa duração precisa, em algum momento, gerenciar contexto finito, mas o gatilho ocioso torna o equilíbrio escolhido pela Anthropic especialmente visível.
Por Que os Desenvolvedores Se Oposeram a um Resumo Automático
A reação negativa se concentrou em uma mudança de estado não anunciada, não na existência da própria compressão de contexto.
Um desenvolvedor que digita manualmente /compact sabe que Claude resumirá a conversa anterior. O comando pode incluir um foco, como preservar decisões de API ou falhas de teste não resolvidas. Esse momento cria uma fronteira natural de revisão.
A compactação ociosa elimina essa escolha imediata. Um usuário pode sair para almoçar, participar de uma reunião ou esperar por feedback externo e então retornar a uma sessão cujo histórico ativo mudou.
O relato original no GitHub descreveu várias sessões de trabalho sendo compactadas enquanto estavam ociosas. O autor disse que os resumos omitiram instruções exatas, a lógica das decisões e métodos previamente acordados. Outros usuários relataram ver a mesma notificação apesar de não estarem perto do limite de contexto configurado.
São relatos de usuários, não medições controladas da precisão dos resumos. Ainda assim, eles identificam um risco de produto crível porque a documentação da Anthropic já afirma que detalhes iniciais podem se perder durante a compactação.
A implementação inicial também complicou o monitoramento. Segundo testes documentados na issue, as primeiras compactações ociosas apareciam nos metadados de hooks como manual, apesar de nenhum usuário ter digitado /compact.
Os hooks do Claude Code permitem que equipes executem automação antes ou depois de eventos definidos. Um rótulo de gatilho enganoso dificulta distinguir uma ação deliberada do usuário de uma transição acionada por temporizador.
O Claude Code 2.1.290 alterou esse gatilho para auto, segundo um colaborador da Anthropic no repositório. Isso separa a compactação ociosa do /compact explicitamente invocado, mas não distingue completamente a compactação ociosa da compactação automática comum baseada em limite.
Essa ambiguidade importa para equipes que usam hooks para preservar o estado de trabalho. Um hook pode querer uma política antes de uma compactação emergencial por limite de contexto e outra antes de uma compactação ociosa orientada por cache.
A discussão da issue solicitou um gatilho distinto, idle. Conforme o comportamento relatado na versão 2.1.290, tanto os eventos ociosos quanto os de limite de contexto poderiam aparecer como auto. A notificação no terminal identificava o evento ocioso para a pessoa, mas esse aviso não era necessariamente incluído na entrada do hook.
A lição mais ampla para o produto diz respeito à otimização invisível. Desenvolvedores geralmente aceitam uma otimização quando ela altera a latência ou o uso de recursos sem mudar a semântica. A sumarização pode mudar a semântica porque a próxima solicitação do modelo recebe evidências diferentes.
Isso torna a compactação ociosa mais semelhante a uma migração automática de estado do que a uma tarefa de limpeza em segundo plano. O identificador da sessão permanece estável, enquanto o substrato de raciocínio muda.
Equipes que executam migrações de alto risco, resposta a incidentes ou revisões extensas de código têm motivos para tratar essa transição com cautela. Suas sessões geralmente acumulam restrições que são individualmente pequenas, mas coletivamente importantes.
Sessões mais curtas enfrentam menos exposição porque permanecem abaixo do limite mínimo. Fluxos de trabalho já estruturados em torno de transferências explícitas também reduzem o custo, porque o estado crítico existe fora da transcrição do chat.
A pressão, portanto, recai mais fortemente sobre desenvolvedores que tratam uma única sessão longa do Claude Code como um parceiro persistente de projeto. Eles obtêm o maior benefício da continuidade, mas também perdem mais quando a continuidade passa a depender de resumos sem uma fronteira intencional.
A Configuração idleCompaction Separa Duas Proteções Diferentes
Os usuários podem desativar a compactação ociosa sem desativar a compactação automática que protege sessões próximas de seu limite de contexto.
O Claude Code 2.1.290 introduziu uma configuração dedicada, segundo um colaborador da Anthropic respondendo na issue pública. Um usuário posteriormente confirmou que a opção funcionava na versão 2.1.291.
A configuração básica é:
Claude Code oferece suporte a configurações em vários escopos, incluindo níveis de usuário, projeto, projeto local e política gerenciada. A referência de configurações da Anthropic explica suas localizações e precedência.
Uma preferência para todo o usuário pode ser incluída no arquivo de configurações pessoais. Uma equipe de repositório pode colocar as configurações do projeto sob controle de versão quando todos devem compartilhar o mesmo comportamento. Uma configuração de projeto local pode substituir comportamentos sem alterar a configuração compartilhada do repositório.
A distinção importante está entre idleCompaction e autoCompactEnabled. O primeiro visa ao novo caminho baseado em temporizador. O segundo controla o comportamento mais amplo de compactação automática.
Desativar "idleCompaction": false preserva a compactação normal por limite, com base no comportamento descrito para a versão 2.1.290. Isso é útil para desenvolvedores que querem proteção perto de uma janela de contexto cheia, mas rejeitam a sumarização orientada por cache durante pausas.
Essa separação respondeu diretamente à principal solicitação dos usuários. Antes de surgir a opção dedicada, desativar a compactação automática de forma mais ampla também poderia remover a proteção que impede uma sessão de atingir seu limite de contexto.
Os usuários devem verificar a versão instalada antes de presumir que a chave funciona. Execute:
A issue pública situa a configuração na versão 2.1.290, enquanto um usuário confirmou explicitamente seu funcionamento na 2.1.291. Organizações com instalações gerenciadas também podem receber atualizações em um cronograma controlado.
A ativação do recurso no lado do servidor acrescenta outro motivo para cautela. Definir idleCompaction como true não força necessariamente a Anthropic a habilitar o recurso para todas as contas ou ambientes. Isso permite o comportamento do cliente quando outras condições de elegibilidade se aplicam.
Defini-la como false é o controle relevante para usuários que precisam optar por não participar. As equipes ainda devem testar o comportamento em sua própria instalação, tipo de conta e hierarquia de políticas.
Uma configuração gerenciada pode ter precedência sobre a escolha de um usuário. Isso é apropriado para organizações com configuração centralizada, mas significa que editar um arquivo local pode não produzir o resultado esperado.
O método de verificação mais seguro é comportamental. Confirme a versão do cliente, inspecione as configurações efetivas e teste com uma sessão não crítica antes de depender da opção durante trabalhos importantes.
Os usuários também devem preservar instruções duráveis fora do histórico da conversa. A Anthropic recomenda colocar regras persistentes em CLAUDE.md, que o Claude Code carrega como contexto do projeto. Esse conselho se aplica quando a compactação ociosa está ativada ou desativada, pois a compactação comum próxima ao limite ainda pode ocorrer.
Uma base de conhecimento de engenharia pesquisável pode servir a um propósito relacionado para equipes humanas. Decisões, restrições e resultados de investigação se tornam artefatos recuperáveis, em vez de dependerem inteiramente de uma única sessão de agente.
O Limite de 200K É Ajustável, mas Não É um Limite de Contexto
`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` altera quando uma sessão se qualifica para a compactação ociosa, não o tamanho da janela de contexto do modelo.
Hallie afirmou que o mínimo padrão é de 200.000 tokens. Os usuários podem fornecer um valor inteiro diferente por meio da configuração de ambiente nas configurações do Claude Code.
Por exemplo:
Este exemplo eleva o limite de elegibilidade para 400.000 tokens. Ele não concede uma janela de contexto maior, não reserva 400.000 tokens para o histórico da conversa nem garante que a compactação seja acionada imediatamente nesse ponto.
A análise da issue pública relatou um limite inferior de 100.000 tokens. Valores abaixo desse piso foram descritos como sendo elevados para 100.000. A Anthropic não havia documentado completamente a variável de ambiente na referência pública de configurações quando a discussão ocorreu; portanto, os usuários devem tratar os detalhes de implementação como sensíveis à versão.
Elevar o limite favorece a fidelidade. Mais sessões extensas podem permanecer ociosas sem serem resumidas, embora retornar após a expiração do cache possa exigir mais processamento de entrada.
Reduzir o limite favorece a eficiência do cache. Mais sessões se tornam elegíveis para compactação antes da expiração, aumentando a chance de os usuários retornarem a resumos em vez de ao histórico completo da conversa.
O valor adequado depende da forma do fluxo de trabalho, não apenas da capacidade do modelo. Uma sessão longa com saída repetitiva de ferramentas pode ser resumida de forma limpa. Uma discussão mais curta sobre arquitetura pode conter decisões densas e interdependentes que resistem à compressão.
A contagem de tokens mede tamanho, não importância semântica. Uma sessão de depuração de 300.000 tokens pode incluir milhares de linhas de log descartáveis. Uma revisão de segurança de 120.000 tokens pode conter numerosas suposições precisas sobre ameaças que devem permanecer literais.
É por isso que um mínimo configurável ajuda sem resolver a tensão central. Ele permite que as equipes escolham onde a troca começa, mas um limite numérico não consegue reconhecer se a conversa atual é segura para resumir.
Os desenvolvedores podem reduzir o risco criando pontos de verificação explícitos antes de deixar uma sessão. Peça ao Claude para registrar a meta ativa, descobertas confirmadas, abordagens rejeitadas, arquivos alterados, status dos testes e o próximo comando em uma nota do repositório.
Essa nota não deve apenas reafirmar a tarefa. Ela deve capturar as evidências necessárias para retomar o trabalho sem reconstruir toda a conversa.
Restrições persistentes pertencem a CLAUDE.md ou a outro arquivo de projeto autoritativo. Descobertas temporárias pertencem a uma issue, registro de trabalho ou documento de transição. Resumos gerados podem então apoiar a continuidade sem se tornarem o único registro.
As equipes também podem usar /context para inspecionar o que está consumindo a janela ativa. Se uma saída volumosa de comandos predomina, limpar ou reestruturar esse material pode ser mais seguro do que permitir que um resumo geral decida o que importa.
A execução manual de /compact continua útil em limites naturais. A Anthropic afirma que os usuários podem adicionar instruções de foco, o que dá ao sumarizador um alvo de preservação melhor do que um evento ocioso sem supervisão.
O princípio maior é simples: escolha a compactação em torno dos limites das tarefas sempre que possível. Limites de tokens evitam falhas, mas limites definidos por humanos refletem melhor a estrutura do trabalho de engenharia.
O Que a Compactação do Claude Code Preserva e o Que Ela Não Pode Prometer
A compactação preserva uma representação de trabalho da sessão, não uma cópia sem perdas de seu histórico de raciocínio.
A documentação da Claude Platform da Anthropic define compactação como a substituição de turnos mais antigos da conversa por um resumo escrito por modelo. Sua visão geral de compactação explica que os aplicativos continuam inserindo o bloco compactado retornado onde as mensagens resumidas apareciam anteriormente.
O Claude Code administra esse fluxo de trabalho dentro do produto. A implementação precisa difere de um aplicativo que usa diretamente a API do Claude, mas o resultado conceitual é semelhante: entradas mais antigas são representadas por texto gerado.
Um bom resumo pode reter a solicitação do usuário, o estado atual da implementação, caminhos de arquivo importantes, resultados de testes e tarefas restantes. Ele pode reduzir drasticamente a quantidade de material anterior enviada em turnos posteriores.
Ele não pode garantir a retenção literal de cada troca. O sumarizador precisa selecionar informações, organizá-las e expressá-las dentro de um orçamento menor de tokens.
O histórico de raciocínio apresenta um desafio específico. Uma sessão de programação frequentemente contém uma cadeia de eliminações. Claude examina um arquivo, formula uma hipótese, vê uma saída contraditória e muda de direção.
O resumo final pode registrar a explicação aceita enquanto comprime o caminho que a validou. Isso costuma ser suficiente, mas enfraquece a capacidade do próximo modelo de auditar a conclusão.
A saída de ferramentas cria outro problema. Logs, erros de compilador, planos de banco de dados e rastros de testes podem conter pequenos detalhes cuja importância só se torna evidente mais tarde. Um resumo produzido antes dessa descoberta posterior não pode saber qual linha será importante.
Correções do usuário também podem perder força. “Não altere o esquema” pode aparecer uma vez, seguido por centenas de turnos. Se isso não for promovido a instruções persistentes, a compactação pode reduzir ou omitir sua relevância.
A documentação do Claude Code recomenda explicitamente CLAUDE.md para regras que precisam sobreviver. Ela também oferece suporte a uma seção “Compact Instructions”, que informa ao sumarizador o que reter durante a compactação.
Esses mecanismos reduzem o risco, mas não tornam os resumos livres de perdas. Uma instrução de compactação ainda é orientação para um modelo que realiza seleção. Um arquivo de instruções do projeto é mais forte porque o Claude Code pode carregá-lo novamente como contexto autoritativo.
Portanto, os desenvolvedores devem dividir o conhecimento da sessão em três classes. Regras operacionais permanentes pertencem às instruções do projeto. O estado de engenharia verificado pertence a arquivos ou registros de trabalho rastreados. A exploração conversacional pode permanecer na transcrição e aceitar compressão eventual.
Essa abordagem também melhora a colaboração. Outro engenheiro não pode herdar de forma confiável a nuance não documentada de uma conversa privada com um agente. Um arquivo de transição conciso oferece a humanos e agentes um ponto compartilhado de recuperação.
A questão prática não é se os resumos são bons ou ruins. É se um fato específico pode existir com segurança apenas dentro de um resumo.
Se perder um detalhe causaria uma migração insegura, um incidente repetido ou um resultado inválido, registre-o fora da conversa antes de deixar a sessão.
Três Sinais Mostrarão se a Compactação Ociosa Merece Confiança
O próximo teste é saber se a Anthropic consegue tornar o benefício de eficiência observável sem tornar a continuidade da sessão imprevisível.
O primeiro sinal é a documentação oficial. Os usuários precisam de uma descrição estável de elegibilidade, momento de execução, versões compatíveis, limites de limiar, precedência de configurações e interações com políticas de cache de prompts.
A documentação também esclareceria se o padrão de 200.000 tokens se aplica de forma consistente entre modelos e contas. Se a Anthropic documentar a variável de ambiente e seu limite inferior, as equipes poderão configurá-la sem depender de arqueologia de issues.
Esse resultado fortaleceria a confiança no recurso. A dependência contínua de publicações sociais e inspeção de binários a enfraqueceria, pois controles não documentados podem mudar sem um caminho óbvio de migração.
O segundo sinal são metadados distintos de gancho. Um gatilho idle dedicado permitiria que as equipes tratassem a compactação orientada por temporizador de modo diferente tanto dos comandos manuais /compact quanto da compactação automática próxima ao limite.
As organizações poderiam capturar o estado antes de um evento ocioso, anexar instruções de compactação personalizadas ou registrar telemetria sobre a frequência de ativação do recurso. Uma identidade clara do evento também facilitaria a investigação de incidentes.
Se a Anthropic mantiver ambos os caminhos automáticos sob o mesmo rótulo auto, os administradores terão visibilidade limitada sobre por que uma sessão mudou. Isso preservaria uma lacuna entre a experiência no terminal e as interfaces de automação.
O terceiro sinal é evidência sobre a qualidade dos resumos em sessões longas de programação. Relatos de usuários identificam nuances ausentes, mas a discussão pública não estabelece uma taxa geral de falhas.
Uma avaliação útil mediria se os resumos retêm restrições explícitas, hipóteses rejeitadas, tarefas pendentes, falhas de testes, referências a arquivos e regras de segurança. Ela também deveria testar a compactação repetida, pois erros podem se acumular quando um estado comprimido se torna entrada para outro.
Um resultado positivo sustentaria o argumento de eficiência da Anthropic. Ele mostraria que a maioria das sessões qualificadas é retomada com precisão suficiente para justificar a compressão automática antes da expiração do cache.
Um resultado negativo reforçaria o argumento por um comportamento de adesão voluntária ou limites padrão mais altos. Também poderia levar o Claude Code a uma compactação parcial que mantém os turnos recentes literalmente, enquanto resume o material mais antigo.
Por enquanto, os desenvolvedores têm uma escolha viável. Mantenha a compactação por inatividade do Claude Code ativada quando uma menor sobrecarga de retomada for mais importante do que a continuidade literal. Aumente o limite de tokens quando apenas sessões muito grandes justificarem essa troca.
Desative-a com "idleCompaction": false quando uma sessão pausada precisar retornar com seu histórico ativo existente intacto. A compactação normal por limite de contexto pode permanecer ativada como uma proteção separada.
Seja qual for a política escolhida, não faça de um chat longo o único registro de um estado crítico de engenharia. Registre restrições duráveis nas instruções do projeto, preserve descobertas verificadas em arquivos e crie uma passagem de contexto antes de se afastar.
A compactação por inatividade do Claude Code expõe uma verdade básica sobre agentes de programação: a continuidade da sessão não é o mesmo que memória perfeita. Antes da sua próxima pausa longa, decida qual delas o seu fluxo de trabalho realmente exige.
