Desenvolvedor tira agente do OpenWebUI após requisição de 1,67 milhão de tokens

Se o seu agente lê um arquivo grande, o conteúdo pode ser enviado novamente ao modelo a cada mensagem seguinte. Foi exatamente assim que o assistente interno de uma pequena equipe, baseado no OpenWebUI, chegou a uma requisição de 1.674.813 tokens e à rejeição pela API. O autor de uma análise publicada no Habr primeiro limpou o histórico com um filtro e depois transferiu a execução de tarefas para um serviço separado. A lição prática: antes de ampliar a janela de contexto, descubra quais dados são reenviados ao modelo e qual componente armazena o estado da conversa.

Um arquivo permanece na conversa por muito tempo

Segundo o autor, uma única chamada a read_file retornou 66.871 caracteres. Onze chamadas de ferramentas produziram quase 130 mil caracteres — cerca de 32 mil tokens, pela estimativa dele. Esses resultados continuavam acompanhando o histórico. O agente solicitava novas verificações, o contexto crescia e o usuário acabava cancelando a tarefa.

Imagine um pedido para corrigir a configuração de um serviço. O agente lê o arquivo, altera algumas linhas e executa uma verificação. Na etapa seguinte, talvez precise do resultado dessa verificação e de um pequeno trecho da configuração. Mas o chat volta a anexar o arquivo antigo completo, os comandos anteriores e suas saídas. Alguns ciclos assim transformam uma conversa de trabalho em um depósito de dados repetidos.

O primeiro filtro removia os resultados de ferramentas dos turnos anteriores, mantendo o turno atual intacto. Esse limite é importante: se o resultado de uma ferramenta recém-executada for removido, o modelo perderá os dados necessários para continuar a tarefa. Depois, o autor adicionou um resumo da conversa antiga, preservando as mensagens mais recentes.

O teste sintético parecia convincente: o tamanho estimado caiu de 3637 para 103 tokens. Mas os logs de um dia mostraram outra realidade: em 128 acionamentos, o filtro removeu apenas duas mensagens com o papel tool. Boa parte do conteúdo desnecessário permanecia no texto normal das respostas de assistant, incluindo blocos de exibição de ferramentas. Foi preciso limpá-los também.

A memória do agente foi para um serviço separado

A sumarização também esbarrou no tamanho da entrada. Segundo o relato do autor, as requisições de compactação chegavam a 161–170 mil tokens, enquanto o modelo escolhido tinha um limite de 128 mil. O mecanismo falhava nas conversas mais longas, justamente onde era mais necessário.

Também houve um timeout quando o filtro chamou a própria API do OpenWebUI em uma configuração com um único worker. O autor associou o problema ao processamento de uma requisição aninhada e substituiu esse caminho por uma chamada direta ao gateway. Trata-se de uma observação de uma instalação específica; não convém estender essa explicação a toda configuração com um único worker sem diagnóstico.

Até julho, o autor havia alterado a arquitetura. O OpenWebUI manteve a gestão de usuários, o upload de arquivos e a exibição das respostas. Uma função Pipe passou a encaminhar a última mensagem, as regras do sistema e os anexos para um Agent Runtime externo. Agora, o próprio serviço de execução, que usa Agents SDK ou Codex SDK, armazena o estado da conversa.

Para a equipe, o importante é ter responsabilidades claras. No modo de engenharia, um único serviço gerencia o histórico, as ferramentas e a continuidade da tarefa. Ele deixa de precisar reconstruir a memória de trabalho a partir da conversa na interface. Ainda assim, um Runtime separado não garante, por si só, um contexto curto: regras de armazenamento e compactação continuam necessárias.

A resposta em streaming precisou ser verificada evento por evento

A migração para a Responses API revelou outra armadilha. A chamada de ferramenta aparecia nos eventos intermediários do fluxo, mas output estava vazio no objeto final. A versão instalada do SDK obtinha o resultado do turno desse objeto final, e o agente repetia as chamadas até esgotar o limite de etapas.

Um programa de diagnóstico separado, que coletava os itens concluídos do fluxo, permitiu dar continuidade ao processo. Mas o autor não identificou onde os dados se perdiam: não houve comparação do fluxo antes e depois do proxy. Este caso não permite atribuir o problema à própria API.

Após atualizar as dependências, o autor relatou seis cenários de API bem-sucedidos, sem fallback oculto para Chat Completions. A verificação no navegador, a carga paralela prolongada e alguns cenários de recuperação de estado ficaram fora dos testes de aceitação.

No seu próprio sistema, vale repetir três verificações: analisar o histórico real de requisições, testar o sumarizador com a entrada máxima e confirmar nos logs o protocolo efetivamente utilizado. Este caso mostra quantos erros podem se esconder por trás de uma resposta do agente que parece bem-sucedida.