chimera-budget-the-context

Você está rodando um loop que acrescenta a uma lista de mensagens a cada passo — um agente ReAct, um turno de codificação, um assistente que chama tools — e a lista só cresce. Sintomas: o provider levanta erro de tamanho de contexto, ou a execução sobrevive mas passa a trabalhar no arquivo errado depois de um trecho longo.

Não se aplica a uma chamada única (single-shot) cujo prompt você mesmo montou e pode medir uma vez. Não há política de descarte a projetar quando nada acumula.

1. Anote dois números antes de tocar no loop: a janela anunciada pelo modelo, e a fração dela que você vai gastar no prompt. O Chimera gasta 0.6 (DEFAULT_BUDGET_FRACTION em chimera/core/context_budget.py). O restante paga a completion e a diferença entre a sua estimativa de tokens e a contagem real do provider.
2. Dispare a compactação sobre uma fração do orçamento, não da janela — o Chimera dispara em 0.8 do orçamento. A compactação precisa de espaço para onde compactar; um gatilho colocado na janela dispara quando não sobrou nenhum.
3. Meça o piso fixo separadamente da parte que cresce. A system message mais o payload de tools= são reenviados a cada passo, e nenhuma quantidade de compactação de mensagens toca neles. Rode chimera schema-bench (ou conte o JSON você mesmo) antes de supor que o histórico é o que sai caro. Uma importação verbosa de MCP ou OpenAPI pode colocar dezenas de milhares de tokens sob cada passo da execução.
4. Se o piso é o problema, encolha o piso: remova as chaves de schema que são só anotação (examples, title, default, $comment) e corte a prosa dos parâmetros até a primeira frase, mantendo type, properties, required e enum intactos, para que a seleção de tools e a validade dos argumentos não mudem. É o que chimera/tools/schema_compact.py faz. Anuncie menos tools se ainda assim for grande demais.
5. Fixe a ordem de descarte explicitamente: a system message nunca, os turnos recentes na íntegra (o Chimera guarda 6), o trecho mais antigo substituído por um resumo ou uma nota factual. Nunca reescreva a system message — ela é o prefixo estável que serve de chave para o cache de prompt, e editá-la invalida todo turno em cache atrás dela.
6. Depois de compactar, reinjete o que a execução precisa para continuar sendo ela mesma: a tarefa na íntegra, o plano, a lista de tarefas com status, e o arquivo que está sendo editado. Releia o arquivo do disco em vez de restaurar uma cópia lembrada.
7. Quando você mesmo estimar o tamanho em tokens, conte o payload de tool_calls além de content. Os argumentos das tools viajam na mensagem do assistant e não estão em content; uma estimativa de tamanho que lê apenas content subestima exatamente as mensagens que cresceram.

Um orçamento baixo demais compacta execuções que nunca precisaram disso, e toda compactação reescreve o sufixo do prompt e joga fora os acertos de cache atrás dele. Numa sessão longa de codificação isso é uma fatura real, paga para evitar um estouro que não teria acontecido.

A compactação de schema tem sua própria aresta: cortar a descrição de um parâmetro para uma frase é seguro para a validade dos argumentos, mas pode remover justamente a frase que dizia ao modelo quando usar a tool. Isso muda o comportamento de seleção sem mudar nenhum schema que o validador confere, então falha como uma escolha de tool ligeiramente pior, e não como um erro. Meça isso como um A/B; não ligue porque economiza tokens.

E o padrão inteiro não compra nada se a tarefa é genuinamente grande demais para o modelo. Orçar transforma um teto rígido em um teto flexível; não cria espaço que não existe.