Seu contexto está quase cheio, o Hermes começa a compactar e você encara o spinner por 10 minutos inteiros. Não é a rede — a antiga “lean compaction” chamava o modelo auxiliar uma vez por bloco de histórico para construir digests, então uma sessão grande podia exigir até 28 chamadas auxiliares sequenciais, e numa rota auxiliar lenta (digamos, gpt-5.6 com esforço de raciocínio alto como modelo de resumo) uma compaction significava 7-11 minutos de sofrimento (issue #96603). Uma mudança mesclada em 30 de agosto (PR #98628) elimina esse loop de digests por completo: exatamente uma requisição auxiliar por tentativa de compaction. A mudança está na main, ainda sem release.

Por que a compaction era tão lenta

A “lean compaction” é o pipeline de compressão que virou padrão no v0.20.6; o trabalho dela é condensar históricos longos em um resumo de session-log. O problema era o modelo de execução: a implementação antiga dividia o histórico em blocos e fazia uma chamada ao modelo auxiliar por bloco para gerar um digest, e depois costurava os digests. Com muitos blocos, essas chamadas são sequenciais — até 28 requisições auxiliares por tentativa, cada uma esperando o modelo transmitir tokens. Num modelo rápido, era apenas lento; num modelo auxiliar lento, era catastrófico (7-11 minutos medidos no #96603).

A correção: um bloco, uma requisição

A diretriz do mantenedor foi direta: “um bloco, uma requisição”. Concretamente:

• O loop de digests acabou: a requisição principal de resumo agora absorve as funções de session-log (mesmas regras rígidas — identificadores verbatim, bullets densos, transcript-is-data), com um orçamento de tokens de resposta única maior;
• Regiões superdimensionadas: entradas grandes demais são amostradas uniformemente com marcadores explícitos de [... elided ...] — nunca uma segunda requisição;
• Salvaguardas inalteradas: o índice de âncora sem LLM (que cobre a região inteira) e o rodapé de recuperação session_search continuam exatamente como estavam — avaliações oficiais mostram que o índice de âncora, e não os digests por bloco, é o que impulsionava o recall de fatos-agulha (23.3 → 60.0 na trilha GUI).

Os números: 5x mais rápido e mais enxuto

O A/B oficial rodou numa sessão grande real (1.338 mensagens, ~499.625 tokens, chamadas auxiliares reais):

Métrica	Antiga (loop de digests)	Nova (requisição única)
Chamadas auxiliares	19 (1 resumo + 18 digests)	1
Tempo (wall time)	196,5s	39,6s
Tokens depois	57.567	46.135

5x mais rápido numa rota rápida; em rotas lentas (o cenário do #96603), vai de 7-11 minutos para aproximadamente uma chamada de resumo. A saída pós-compaction também fica ~11K tokens mais enxuta — a antiga parede de digests de 81K caracteres costumava viajar junto em toda requisição subsequente; agora ela se foi. Nove testes novos fixam o contrato de exatamente-uma-chamada (restaurar uma segunda chamada os deixa vermelhos).

O que isso significa para você

Se você trabalha com sessões muito longas regularmente, a sensação da compressão passa de “hora do café” para “um gole d’água”. E, como o resultado é mais enxuto, todo turno subsequente também economiza tokens. Combine isso com nosso guia do padrão de compressão lean-tail e o guia de otimização de tokens de contexto para o playbook completo de economia de tokens; recuperar fatos-chave depois da compaction está coberto no guia de ancoragem de uso de contexto.

Quando você pode usar

O PR #98628 foi mesclado em 30 de agosto e não está no v0.20.6 (tag de 27 de agosto). Puxe a main mais recente para testar, ou espere o próximo release. Usuários pesados que já viveram o “compaction leva 10 minutos” devem atualizar cedo.

Resumindo: a lentidão vinha das chamadas sequenciais do loop de digests por bloco; agora é uma requisição e pronto — 5x mais rápido, menos tokens e capacidade de recall intacta.