> ## Documentation Index
> Fetch the complete documentation index at: https://chatcli.edilsonfreitas.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Recuperação de Contexto
> Recuperação automatica em 3 niveis contra overflow de contexto, limites de proxy corporativo e escalação de max output tokens
O ChatCLI implementa um sistema de **recuperação automatica de contexto** que lida com três tipos de falha comuns em sessões longas: overflow da janela de contexto do modelo ("prompt too long"), limites de payload de proxy/gateway corporativo (413/WAF 403/EOF silencioso), e limite de tokens de saída. Quando a API rejeita uma requisição por qualquer um desses motivos, o sistema aplica estratégias progressivamente mais agressivas para recuperar a sessão sem perder a conversa.
***
## Recuperação de Context Overflow
Quando a API retorna um erro de "context too long", o ChatCLI aplica até 3 niveis de recuperação antes de desistir. Todo loop recupera, não só o agent/coder: o REPL de chat (o prefixo e a mensagem de contexto do turno são reconstruídos sobre o histórico recuperado), o chat RPC atrás de MCP/ACP/gateway, o one-shot (`-p`, aviso no stderr para o stdout continuar "pipeável") e cada participante do MoA (a própria thread é compactada; o painel não falha mais por um overflow). O helper compartilhado é limitado (`CHATCLI_MAX_RECOVERY_ATTEMPTS`, padrão 3) e dá as mesmas garantias de uma compactação planejada: memória descarregada antes, hooks avisados com o gatilho `recovery`, mensagens descartadas arquivadas no CCR, rebuild de cache contabilizado.
O classificador que decide "isto é overflow" é compartilhado por todos os loops e pela cadeia de fallback de provedores, e cobre a frase de cada provedor — OpenAI chat e Responses ("context window", `context_length_exceeded`), Anthropic ("prompt is too long"), Gemini ("input token count … exceeds"), xAI ("maximum prompt length"), Mistral, Groq, Bedrock — mais uma checagem por status em 400/413 cujo corpo combina uma palavra de token/tamanho com uma de excesso.
**Primeira tentativa**: reduz os limites de orcamento pela metade e limpa desalinhamentos.
Acoes:
* Repara pareamento de tool results (remove orfaos, injeta sinteticos)
* Aplica 50% de `DefaultTurnBudgetChars` e `DefaultPerResultMaxChars` **só para esta sessão** — os defaults do processo nunca são mutados, então outras sessões de um gateway ou `rpcserve` nunca veem limites pela metade
* Aplica enforcement de orcamento com limites reduzidos
* Trunca mensagens longas do assistente para 5.000 chars
Os limites originais sao restaurados após a aplicacao. Apenas o histórico atual e afetado pela reducao.
**Segunda tentativa**: mantem apenas mensagens do sistema e as ultimas N mensagens.
Acoes:
* Preserva todas as mensagens de sistema (system prompt, bootstrap, contextos)
* Mantem as ultimas 10 mensagens não-sistema (configurável)
* Garante que o histórico comeca com uma mensagem `user` (requisito da API)
* Valida pareamento de tool results no histórico truncado
**Terceira tentativa**: mantem apenas o mínimo para continuar.
Acoes:
* Preserva mensagens de sistema
* Mantem apenas as ultimas 4 mensagens (2 trocas user/assistant)
* Injeta mensagem de aviso explicando que o contexto foi compactado
```text theme={"system"}
[Context was automatically compacted due to size limits.
Previous conversation history has been summarized.
Continue from where you left off.]
```
### Detecção de Erro — overflow do modelo
O sistema reconhece múltiplas formas de erro de overflow:
| Mensagem de Erro | Provedor |
| :- | :- |
| `context length exceeded` | Anthropic |
| `prompt is too long` | OpenAI |
| `request too large` | Varios |
| `max_tokens exceed` | Varios |
| `input too long` | Google |
| `token limit` | Genérico |
***
## Recuperação de proxy/gateway corporativo
Ambientes corporativos frequentemente rodam atrás de proxies ou gateways que impõem **um teto de body size para POSTs** — tipicamente 1-5 MB, totalmente independente da janela de contexto do modelo. Você pode estar dentro do limite do Anthropic (200K tokens / \~800 KB) e mesmo assim tomar uma rejeição misteriosa do proxy. Pior: muitos proxies não retornam um 413 limpo — alguns mandam 403 do WAF (Cloudflare, Akamai, mod\_security), 431 (header too large), ou simplesmente dropam a conexão TCP no meio do POST, emergindo como `EOF` / `connection reset` no cliente.
O ChatCLI detecta esses três padrões e aplica o mesmo fluxo de recuperação do context overflow.
### Detecção de Erro — proxy/gateway
| Padrão detectado | Exemplo | Função |
| :- | :- | :- |
| HTTP 413 + variantes | `413 Payload Too Large`, `request entity too large`, `body too large`, `maximum request size`, `431 Request Header Fields Too Large` | `IsPayloadTooLargeError` |
| 403 com sinais de WAF/firewall | 403 com `firewall`, `waf`, `security policy`, `blocked by`, `cloudflare`, `cf-ray`, `mod_security`, `akamai`, `proxy denied`, `policy violation` | `IsProxyWAFRejection` |
| 403 com corpo HTML (Bedrock/AWS SDK) | `StatusCode: 403 ... deserialization failed ... invalid character '<' looking for beginning of value` (SDK tentando decodar uma página de bloqueio HTML do proxy como JSON) | `IsProxyWAFRejection` |
| EOF / reset com histórico grande | `unexpected eof`, `connection reset`, `broken pipe`, `stream error` **e** histórico > 500 KB | `IsLikelyPayloadProblem` (heurístico) |
A detecção de WAF é **conservadora** — um 403 sem sinais de firewall continua sendo tratado como erro de autenticação (refresh OAuth + retry). Só quando o 403 carrega sinais específicos do proxy/WAF é que ele é reclassificado como falha recuperável de payload. Isso evita invalidar credenciais OAuth válidas quando o problema real está na rede.
**O caso Bedrock corporativo:** quando o proxy/WAF intercepta a requisição POST ao Bedrock Runtime e devolve uma página HTML de bloqueio com status 403, o AWS SDK tenta fazer parse do body como JSON e falha com `"invalid character '<' looking for beginning of value"` e `RequestID` vazio. Esse padrão é um fingerprint inequívoco de middlebox (um 403 real da AWS retorna JSON bem-formado) — o ChatCLI reclassifica para falha recuperável de payload e dispara a mesma ladder de recovery.
A detecção de EOF/connection-reset aplica um **limiar de tamanho do histórico (500 KB)** antes de suspeitar de payload. Requisições pequenas que sofrem EOF continuam sendo tratadas como falhas transitórias de rede (retry normal). Só quando o histórico já está suspeitosamente grande é que o EOF é reclassificado como possível body cap.
### Pre-flight check
A cada turno do agente, o histórico é medido antes do request sair. Dois caminhos:
**Com `CHATCLI_MAX_PAYLOAD` configurado:**
Se o histórico passa de 85% do cap, o `BudgetRatio` é forçado para `0.40` antes de qualquer coisa — compactação agressiva preventiva. O usuário vê:
```text theme={"system"}
ℹ pre-flight: history 4.2 MB ≈ 86% do cap configurado (5.0 MB) — compactando
```
**Sem cap configurado:**
Se o histórico passa de 2.5 MB, um aviso **one-shot por sessão** é emitido sugerindo configurar a env var. Não dispara de novo no mesmo run para evitar barulho.
```text theme={"system"}
ℹ history 2.8 MB — se seu ambiente tem proxy/gateway, export CHATCLI_MAX_PAYLOAD=5MB (ajuste p/ limite do proxy)
```
### Cap adaptativo aprendido
Os providers Bedrock anotam cada erro de transporte com o **tamanho exato da requisição que o middlebox rejeitou**. Quando uma rejeição de payload acontece, o ChatCLI deriva o limite da sessão diretamente dessa observação — **¾ do tamanho rejeitado** — em vez de chutar:
```text theme={"system"}
⚠ Falha recuperável (rejeição do proxy/WAF (403 + sinais de segurança)) — compactando e tentando novamente
ℹ Gateway rejeitou uma requisição de 126.4 KB — limite de payload ajustado para 94.8 KB nesta sessão (exporte CHATCLI_MAX_PAYLOAD para sobrepor)
```
Na prática isso muda tudo: gateways corporativos reais frequentemente limitam o corpo em torno de **128 KB**, onde um chute de vários megabytes não mudaria nada. O cap aprendido só **aperta** — se `CHATCLI_MAX_PAYLOAD` já estiver abaixo dele, seu valor vence; uma rejeição menor posterior aperta ainda mais.
Quando o tamanho rejeitado é *desconhecido* (providers sem anotação de tamanho), vale o comportamento anterior como fallback: assumir **4 MB** para o resto da sessão.
```text theme={"system"}
ℹ Assumindo limite de 4 MB/payload — exporte CHATCLI_MAX_PAYLOAD (ex.: 5MB, 512KB) para ajustar
```
### Diagnóstico de piso — quando compactar não resolve
O system prompt (charter do agente, personas, skills, docs de ferramentas MCP) **nunca é compactado**. Quando ele sozinho atinge o tamanho que o gateway acabou de rejeitar, nenhuma compactação de histórico produz uma requisição aceitável — repetir payloads idênticos só queimaria tentativas de recovery. O ChatCLI detecta isso e **falha rápido com uma mensagem acionável**:
```text theme={"system"}
✖ A base não-compactável da requisição (system prompt: 131.2 KB — personas, skills,
docs de ferramentas MCP) atinge ou excede o tamanho rejeitado pelo gateway (126.4 KB).
Compactar histórico não resolve — reduza servidores MCP, skills ou personas,
ou aumente o limite de corpo do proxy/WAF
```
A **¾ do tamanho rejeitado** dispara um aviso — a sessão continua, mas você está perto da borda:
```text theme={"system"}
⚠ O system prompt sozinho tem 96.1 KB — próximo do limite de rejeição do gateway;
considere reduzir servidores MCP, skills ou personas
```
Três features estruturais encolhem esse piso: as descrições de ferramentas MCP são limitadas a uma linha no índice do system prompt (schema completo via `@tools describe`), os corpos de skills injetadas respeitam [`CHATCLI_SKILL_INJECT_BUDGET`](/pt/extensions/skill-registry#budget-de-injeção-de-skills) mais seu cap de 2× por execução, e blocos de skill mid-loop envelhecem para stubs após `CHATCLI_SKILL_AGE_TURNS` turnos (recuperáveis via `@recall`). Veja [Integração MCP](/pt/extensions/mcp-integration) e [Skill Registry](/pt/extensions/skill-registry).
### Encolhimento de conteúdo — o Nível 3 que funciona de verdade
Dropar mensagens inteiras é no-op quando o histórico é curto — sessões de agente frequentemente têm só o system prompt e um punhado de tool results gigantes, e o `MinKeepRecent` mantém exatamente as mensagens que carregam o volume. A truncagem de emergência ganhou por isso um passe final: **encolhe o conteúdo das mensagens não-system, da maior para a menor**, até caber no budget de payload. Mensagens system nunca são tocadas.
Com a [camada de compressão](/pt/context/context-compression) ativa, cada mensagem é **arquivada verbatim no store CCR antes do primeiro corte** e o conteúdo encolhido carrega um marcador `<>` — o modelo recupera o original a qualquer momento com `@recall`. A truncagem nuclear (nível 3 da escada de recovery) adicionalmente limita cada mensagem não-system mantida a 4.000 chars.
### O que cada nível garante
As mesmas garantias valem em qualquer loop que compacte (chat, agent/coder, one-shot, `/compact`) e no recovery de overflow:
* **Nada que o modelo pediu para manter é tocado.** Mensagens marcadas `PreserveVerbatim` (um resultado de `@recall` que o modelo pediu explicitamente por inteiro) ficam fora do segmento sumarizado e são reanexadas logo após o resumo no Nível 2, mantidas inteiras no Nível 3 e ignoradas pelo encolhimento de conteúdo. Um tool result nativo verbatim reanexado sem a tool call dona vira mensagem de usuário, então o reparo de pareamento nunca o apaga. Mensagens verbatim ocupam no máximo um quarto do budget: além disso, as mais antigas são arquivadas de novo no CCR, viram stub com marcador `@recall` e perdem a flag, então a compactação sempre converge.
* **Compactação que não muda nada não é compactação.** Um no-op, um resumo rejeitado ou uma falha descarta o snapshot de undo (então `/rewind compact` nunca "restaura" um histórico idêntico) e dispara o `PostCompact` par com `outcome=skipped`; restaurar um checkpoint do `/rewind` usa a mesma contabilidade do `/rewind compact` (reescrita no journal, rebuild de cache esperado, pilha de undo limpa).
* **O Nível 3 deixou de ser lossy.** As mensagens que ele descarta são arquivadas no store CCR antes, e o aviso de truncagem carrega um marcador `@recall` para o segmento inteiro — a mesma recuperabilidade que os Níveis 1 e 2 já tinham. O recovery de overflow descarrega a memória pendente, arquiva as mensagens que remove e anexa o marcador ao histórico recuperado.
* **Um resumo ruim nunca substitui o segmento.** Um gate de qualidade rejeita recusas e respostas curtas demais para o segmento (piso proporcional ao tamanho, teto de 80 caracteres); o sumarizador é tentado mais uma vez e, se falhar, o pipeline cai para o Nível 3 com seu arquivo.
* **O sumarizador não é pago à toa.** Quando um resumo não traz o histórico para dentro do budget, as duas compactações seguintes pulam o Nível 2 e vão direto ao Nível 3 em vez de pagar uma chamada de sumarização por turno.
* **Hooks veem toda compactação.** `PreCompact`/`PostCompact` disparam com `trigger` `auto`, `manual` ou `recovery` ([hooks](/pt/extensions/hooks-system#eventos-disponíveis)).
* **É contabilizado.** `/cost` mostra o número de compactações, quantas caíram no Nível 3 e quanto o sumarizador custou; os contadores persistem com a sessão ([cost tracking](/pt/providers/cost-tracking)).
O `/compact ` guiado segue as mesmas regras: usa a rota de sumarizador configurada (`CHATCLI_COMPACT_MODEL`) quando existe, dá ao resumo sua própria janela de 10 minutos em vez do antigo prazo de 60 segundos do comando, mantém mensagens `PreserveVerbatim`, arquiva o segmento e roda o gate de qualidade.
### System notice injetado na história
Após um recovery disparado por payload limit, o ChatCLI injeta uma mensagem `user` antes do retry instruindo o modelo a fazer leituras menores no futuro. Isso quebra o loop do modelo de tentar re-ler o mesmo arquivo gigante que causou o 413 originalmente. O notice é injetado **no máximo uma vez por sessão** — o recovery detecta uma cópia existente em qualquer lugar do histórico (mesmo dobrada num summary de compactação) e nunca empilha uma segunda, já que cada byte extra trabalha contra o próprio limite sendo recuperado:
```text theme={"system"}
[SYSTEM NOTICE — PAYLOAD LIMIT HIT] A proxy/gateway rejected the previous
request due to body size. History was compacted to recover. Going forward:
(1) When reading files, prefer targeted reads with line ranges
(e.g. sed -n '100,200p' file, or read_file with offset+limit) instead
of reading entire files.
(2) Prefer grep/ripgrep with specific patterns over full-file reads.
(3) If you previously read a large file, its full content is persisted at
the path shown in the tool-result preview — re-read specific ranges
from that file rather than repeating the original read.
(4) Summarize findings incrementally rather than accumulating raw tool output.
```
Este hint é injetado **em inglês** intencionalmente. A IA segue instruções em inglês com muito mais fidelidade mesmo quando o usuário está em pt-BR, e esta mensagem não é visível ao usuário — ela só entra no histórico enviado ao modelo.
***
## Escalação de Max Output Tokens
Quando o modelo para de gerar por atingir o limite de `max_tokens`, o ChatCLI pode escalar automaticamente:
| Tentativa | Acao |
| :- | :- |
| 1a | Dobra o `max_tokens` atual (até o cap do provedor) |
| 2a | Dobra novamente (até o cap do provedor) |
| 3a+ | Para de escalar, retorna conteúdo parcial |
### Mensagem de Continuacao
Quando o modelo e interrompido por limite de tokens, o ChatCLI injeta uma mensagem de continuacao:
```text theme={"system"}
Your response was cut off at the token limit.
Resume DIRECTLY from where you stopped — do not repeat any content.
Continue the implementation or explanation from the exact point of interruption.
```
A mensagem instrui o modelo a continuar de onde parou, evitando repeticao de conteúdo já gerado.
***
## Configuração
| Variável de Ambiente | Descrição | Default |
| :- | :- | :- |
| `CHATCLI_CONTEXT_WINDOW` | Override **global** da janela de contexto (em tokens), para qualquer provider/modelo. Tem precedência sobre o catálogo. Use quando a janela real do seu gateway/agente difere da assumida pelo ChatCLI — o orçamento de compactação deriva desse valor. | *(auto via catálogo)* |
| `CHATCLI_MAX_RECOVERY_ATTEMPTS` | Tentativas máximas de recuperação de contexto | `3` |
| `CHATCLI_MAX_TOKEN_ESCALATIONS` | Escalações máximas de max\_tokens | `2` |
| `CHATCLI_EMERGENCY_KEEP_MESSAGES` | Mensagens mantidas no truncamento de emergência | `10` |
| `CHATCLI_MAX_PAYLOAD` | Teto **human-friendly** para o body size do POST (ex.: `5MB`, `512KB`, `2.5MB`, `5`=5MB). Quando setado, o compactor respeita esse teto como limite adicional à janela de contexto do modelo, e o pre-flight força compactação ao cruzar 85% do cap. | *(não setado — sem teto)* |
### Feedback visual durante a compactação
Desde esta versão, o histórico nunca mais "congela" o terminal durante uma compactação longa. O `HistoryCompactor` emite status em cada fase do pipeline via `SetStatusCallback`:
```text theme={"system"}
│ 📦 Compactando histórico (23 msgs, 4.2 MB → alvo 2.9 MB)
│ 🧹 Trim: removendo reasoning/dedup (sem LLM)…
│ 🧠 Resumindo mensagens antigas via LLM (pode levar 30-90s — ESC cancela)…
│ ✓ Resumo aplicado (23 → 9 msgs, 4.2 MB → 1.8 MB)
```
**Cancelamento**: a chamada LLM de summarização agora deriva do context do turno — `Ctrl+C` / `ESC` propaga corretamente e aborta a compactação sem corromper o histórico (retorna `ctx.Err()` em vez de cair para truncamento de emergência cego).
### Flush de memória antes da compactação
O worker de memória destila fatos do histórico vivo alguns turnos atrás da conversa; a compactação substitui o meio desse histórico por um resumo, então o que o worker ainda não tinha alcançado era destilado, no melhor caso, a partir do resumo. Todo ponto de compactação (auto-compact no chat, agent e coder, `/compact` explícito e guiado, one-shot) agora entrega o segmento ainda não extraído à fila durável do worker **antes** da reescrita, para que as mensagens originais cheguem à memória de longo prazo intactas, independentemente do que o resumo mantém.
### Leituras repetidas (pré-budget)
No mesmo limite de turno, `DedupRepeatedReads` remove as cópias que uma sessão de coder acumula ao ler o mesmo arquivo repetidas vezes: quando um `@coder read` posterior do mesmo caminho cobre a mesma faixa de linhas ou uma mais ampla, toda leitura anterior daquele caminho vira um stub de uma linha (arquivado antes no CCR, então `@recall` restaura) e a leitura mais nova fica intacta. Leituras posteriores mais estreitas nunca substituem uma anterior mais ampla, a saída de `@recall` nunca é tocada, e cada passagem é reportada na linha do turno. O modelo mantém exatamente uma visão atual por arquivo em vez de cinco.
### Microcompact (pré-budget)
A checagem de budget em si é **honesta com o payload**: pesa o texto das mensagens mais argumentos de tool calls nativas, payloads de imagem e excesso de system-parts, então históricos pesados em tools ou visão cruzam o limiar quando a requisição real cruza — não depois de um proxy já ter rejeitado. Antes do `NeedsCompaction` checar se o histórico excede o budget, o agent loop aplica `ApplyMicrocompact` — uma passada **pure-Go, sem LLM, sem rede** que progressivamente trunca/resume tool results antigos (2+ turnos atrás → head+tail preview; 4+ turnos atrás → one-line summary). Na maioria dos casos isso mantém o histórico dentro do budget sem disparar o Level 2 (caro).
A **entrada do sumarizador é orçada** contra a janela do próprio modelo sumarizador (metade dela, piso de 20K chars) em vez de um corte fixo cabeça/cauda por mensagem: cada mensagem do segmento recebe uma cota justa, uma mensagem já dobrada num stub `<>` é **restaurada do arquivo CCR** quando o original cabe, mensagens longas mantêm cabeça e cauda na proporção 3:1, e tool calls nativas são nomeadas para o resumo listar os comandos executados. A mesma renderização serve o `/compact `.
Com a [camada de compressão](/pt/context/context-compression) ativa, o microcompact é **sem perda**: o tool result original é arquivado no store CCR antes do corte e o stub de preview/summary embute um marcador `<>`. Os marcadores sobrevivem entre níveis — quando um preview truncado depois vira um summary de uma linha, o marcador permanece no summary — então o modelo sempre pode expandir o original com `@recall`.
```text theme={"system"}
🗜 microcompact: 3 truncados, 2 resumidos, 1.7 MB liberados
```
Configurável via env:
| Variável de Ambiente | Descrição | Default |
| :- | :- | :- |
| `CHATCLI_MICROCOMPACT_TRUNCATE_TURNS` | Turnos de idade para começar a truncar tool results | `2` |
| `CHATCLI_MICROCOMPACT_SUMMARIZE_TURNS` | Turnos de idade para substituir por summary de uma linha | `4` |
| `CHATCLI_COMPACT_MODEL` | `PROVIDER:modelo` dedicado ao resumo estruturado de Nível 2 (mais barato/rápido que o modelo da sessão) | *(cliente da sessão)* |
### Ratio de Orcamento Agressivo
No nivel 1, os limites de orcamento de tool results sao multiplicados por `0.5` (50%). Isso significa:
| Parâmetro | Normal | Nivel 1 Recuperação |
| :- | :- | :- |
| Budget por turno | 200.000 chars | 100.000 chars |
| Max por resultado | 20.000 chars | 10.000 chars |
***
## Fluxo de Recuperação
```text theme={"system"}
API retorna erro recuperável (context overflow | 413 | WAF 403 | EOF c/ histórico grande)
│
├─ Payload-related: cap aprendido do tamanho rejeitado (¾) ────────────┐
│ ├─ System prompt ≥ tamanho rejeitado → FALHA RÁPIDA c/ diagnóstico │
│ └─ System notice injetado no histórico (uma vez por sessão) │
│ │
├─ Tentativa 1: Orçamento agressivo (50%) + pairing cleanup │
│ └─ Reenvia para API │
│ ├─ Sucesso → continua normalmente │
│ └─ Falha → próxima tentativa │
│ │
├─ Tentativa 2: Emergency truncate (system + últimas 10 msgs) │
│ └─ Reenvia para API │
│ ├─ Sucesso → continua com histórico reduzido │
│ └─ Falha → próxima tentativa │
│ │
└─ Tentativa 3: Nuclear truncate (system + últimas 4 msgs, │
cada uma limitada a 4.000 chars, arquivada no CCR antes) │
└─ Reenvia para API │
├─ Sucesso → continua com histórico mínimo │
└─ Falha → erro reportado ao usuário │
│
Tamanho rejeitado desconhecido: CHATCLI_MAX_PAYLOAD auto-setado ◄──────┘
para 4MB se não configurado
```
Após o truncamento nuclear (nível 3), o contexto de trabalho do modelo cai para as últimas 2 trocas. Com a [camada de compressão](/pt/context/context-compression) ativa o conteúdo dropado permanece recuperável — os stubs carregam marcadores `<>` que o modelo expande com `@recall` — mas o `/compact` proativo continua sendo a melhor experiência: um summary estruturado vale mais que uma pilha de marcadores de recall.
***
## Interação com Outros Sistemas
A recuperação de contexto trabalha em conjunto com:
O orcamento de resultados e a primeira linha de defesa. A recuperação ativa quando o orcamento não foi suficiente.
A compactação progressiva reduz o crescimento do contexto ao longo do tempo.
O comando `/compact` e a forma proativa de prevenir overflow.
Monitore o uso de contexto para antecipar quando /compact sera necessário.
## Motor de contexto externo (MCP)
`CHATCLI_CONTEXT_ENGINE=mcp:` entrega o resumo de Nível 2 a um servidor MCP configurado que expõe `context_compact(segment, budget_chars, instruction)`: o segmento renderizado da conversa (a mesma renderização orçada que o sumarizador embutido recebe), o orçamento em chars e, no `/compact ` guiado, a instrução do usuário. A resposta substitui o segmento; o arquivo CCR, os checkpoints e o `@recall` seguem funcionando exatamente como antes. Erro, timeout (3 min) ou resposta vazia caem no sumarizador embutido naquela compactação. Aparece em `/config compression`.
`CHATCLI_CONTEXT_ENGINE=provider` soma a edição de contexto server-side do próprio modelo ao pipeline local. Na Anthropic (API key ou OAuth) toda requisição do loop de tools carrega o beta `context-management-2025-06-27` e um bloco `context_management` com uma edição `clear_tool_uses_20250919`: quando o prompt passa de 100 K tokens de entrada, a própria API limpa os tool results mais antigos, mantendo os cinco tool uses mais recentes e liberando pelo menos 20 K tokens por edição, antes de esses tokens serem cobrados. As edições aplicadas voltam na resposta e são espelhadas localmente: os tool results mais antigos que o servidor limpou viram stubs no histórico local (os originais arquivados no CCR, recuperáveis com `@recall`), a calibração chars/token pula aquele turno, a próxima escrita de cache é contabilizada como rebuild esperado e o `/context status` mostra quantas edições, tool results e tokens o provedor limpou. A compactação local, o arquivo CCR e o `/rewind compact` seguem iguais, então nada se perde que já não fosse recuperável. Provedores sem equivalente server-side documentado ignoram a opção.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.