Un développeur sort l'agent d'OpenWebUI après une requête de 1,67 million de tokens

Si votre agent lit un gros fichier, son contenu peut être renvoyé au modèle à chaque message suivant. C'est ainsi que l'assistant interne d'une petite équipe, bâti sur OpenWebUI, a atteint une requête de 1 674 813 tokens et un refus de l'API. L'auteur de l'analyse publiée sur Habr a d'abord nettoyé l'historique avec un filtre, puis déplacé l'exécution des tâches vers un service distinct. La leçon pratique : avant d'agrandir la fenêtre de contexte, déterminez quelles données repartent vers le modèle et quel composant conserve l'état de la conversation.

Un seul fichier reste longtemps dans la conversation

Selon l'auteur, un seul appel à read_file a renvoyé 66 871 caractères. Onze appels d'outils ont produit près de 130 000 caractères, soit environ 32 000 tokens selon son estimation. Ces résultats continuaient de voyager avec l'historique. L'agent demandait de nouvelles vérifications, le contexte grossissait, et l'utilisateur finissait par annuler la tâche.

Imaginez une demande de correction de la configuration d'un service. L'agent lit le fichier, modifie quelques lignes, lance une vérification. À l'étape suivante, il peut avoir besoin du résultat de la vérification et d'un petit extrait de la configuration. Mais le chat joint de nouveau l'intégralité de l'ancien fichier, les commandes précédentes et leur sortie. Quelques cycles de ce type transforment un échange de travail en entrepôt de données répétées.

Le premier filtre supprimait les résultats d'outils des tours précédents tout en laissant le tour en cours intact. C'est une limite essentielle : si l'on retire le résultat d'un outil qui vient d'être appelé, le modèle perd les données nécessaires pour poursuivre la tâche. L'auteur a ensuite ajouté un résumé des anciens échanges, en conservant les derniers messages.

Le test synthétique semblait convaincant : le volume estimé est passé de 3637 à 103 tokens. Mais les journaux sur vingt-quatre heures ont montré un tout autre tableau : sur 128 déclenchements, le filtre n'a supprimé que deux messages avec le rôle tool. Une grande partie des déchets restait dans le texte ordinaire des réponses de l'assistant, y compris dans les blocs d'affichage des outils. Il a fallu les nettoyer aussi.

La mémoire de l'agent a déménagé dans un service distinct

La synthèse a elle aussi buté sur la taille de l'entrée. D'après le rapport de l'auteur, les requêtes de compression atteignaient 161 à 170 000 tokens, pour une limite de 128 000 sur le modèle choisi. Le mécanisme échouait sur les conversations les plus longues, là où il était le plus nécessaire.

Il y a eu aussi un délai d'attente lors de l'appel du filtre à l'API propre d'OpenWebUI, dans une configuration à un seul worker. L'auteur l'a rattaché au traitement d'une requête imbriquée et a remplacé ce chemin par un appel direct à la passerelle. Il s'agit de l'observation d'une installation précise ; il ne faut pas étendre cette explication à toute configuration à worker unique sans diagnostic.

En juillet, l'auteur a modifié l'architecture. OpenWebUI a conservé les utilisateurs, le téléversement de fichiers et l'affichage des réponses. Une fonction pipe transmet désormais le dernier message, les règles système et les pièces jointes à un Agent Runtime externe. L'état de la conversation est maintenant conservé par l'exécuteur lui-même, qui utilise l'Agents SDK ou le Codex SDK.

Pour l'équipe, la clarté des responsabilités compte ici. En mode ingénierie, un seul service gère l'historique, les outils et la poursuite de la tâche. Il n'a plus à reconstituer la mémoire de travail à partir de l'échange d'interface. Pour autant, un Runtime distinct ne garantit pas à lui seul un contexte court : des règles de conservation et de compression restent nécessaires.

Il a fallu vérifier la réponse en streaming événement par événement

En passant à l'API Responses, l'auteur a découvert un autre piège. Dans les événements intermédiaires du flux, l'appel d'outil était présent, mais dans l'objet final, output était vide. La version installée du SDK prenait le résultat du tour dans l'objet final, et l'agent répétait les appels jusqu'à épuisement de la limite d'étapes.

Une sonde distincte, qui rassemblait les éléments terminés à partir du flux, a permis de poursuivre le scénario. Mais l'auteur n'a pas déterminé où les données étaient perdues : il n'y a pas eu de comparaison du flux avant et après le proxy. On ne peut donc pas imputer le problème à l'API elle-même sur la base de ce cas.

Après la mise à jour des dépendances, l'auteur a fait état de six scénarios API réussis, sans repli caché sur Chat Completions. En revanche, la vérification dans le navigateur, la charge parallèle prolongée et une partie des scénarios de restauration d'état sont restées hors du périmètre de la recette.

Pour votre propre système, trois vérifications méritent d'être reproduites : analyser l'historique réel des requêtes, tester le résumeur sur l'entrée maximale et confirmer dans les journaux le protocole effectivement utilisé. Ce cas montre combien d'erreurs se cachent derrière une réponse d'agent formellement réussie.