Un desarrollador saca su agente de OpenWebUI tras una solicitud de 1,67 millones de tokens

Si su agente lee un archivo grande, su contenido puede volver a enviarse al modelo con cada mensaje posterior. Así fue como el asistente interno de un pequeño equipo, basado en OpenWebUI, acabó generando una solicitud de 1 674 813 tokens que la API rechazó. El autor del análisis publicado en Habr primero limpió el historial con un filtro y después trasladó la ejecución de tareas a un servicio independiente. La lección práctica: antes de ampliar la ventana de contexto, averigüe qué datos se reenvían al modelo y qué componente conserva el estado de la conversación.

Un archivo permanece mucho tiempo en la conversación

Según el autor, una sola llamada a read_file devolvió 66 871 caracteres. Once llamadas a herramientas produjeron casi 130 mil caracteres: unos 32 mil tokens, según su estimación. Esos resultados seguían acompañando al historial. El agente pedía nuevas comprobaciones, el contexto crecía y el usuario terminaba cancelando la tarea.

Imagine que pide corregir la configuración de un servicio. El agente lee el archivo, modifica unas líneas y ejecuta una comprobación. En el siguiente paso, quizá necesite el resultado de esa comprobación y un pequeño fragmento de la configuración. Pero el chat vuelve a adjuntar el archivo antiguo completo, los comandos anteriores y sus salidas. Unos cuantos ciclos así convierten una conversación de trabajo en un almacén de datos repetidos.

El primer filtro eliminaba los resultados de herramientas de los turnos anteriores y dejaba intacto el turno actual. Es un límite importante: si se elimina el resultado de una herramienta recién ejecutada, el modelo pierde los datos necesarios para continuar la tarea. Después, el autor añadió un resumen de la conversación antigua que conservaba los mensajes más recientes.

La prueba sintética parecía convincente: el tamaño estimado bajó de 3637 a 103 tokens. Sin embargo, los registros de un día mostraron otra realidad: en 128 activaciones, el filtro solo eliminó dos mensajes con el rol tool. Buena parte del contenido sobrante permanecía dentro del texto normal de las respuestas de assistant, incluidos los bloques de visualización de herramientas. También hubo que limpiarlos.

La memoria del agente se trasladó a un servicio independiente

La generación de resúmenes también chocó con el tamaño de la entrada. Según el informe del autor, las solicitudes de compresión alcanzaban entre 161 y 170 mil tokens, frente al límite de 128 mil del modelo elegido. El mecanismo fallaba en las conversaciones más largas, precisamente donde más se necesitaba.

También se produjo un tiempo de espera agotado cuando el filtro llamaba a la propia API de OpenWebUI en una configuración con un solo worker. El autor lo relacionó con el procesamiento de una solicitud anidada y sustituyó esa ruta por una llamada directa al gateway. Se trata de una observación de una instalación concreta; no conviene extrapolar la explicación a cualquier configuración con un solo worker sin un diagnóstico.

Para julio, el autor había cambiado la arquitectura. OpenWebUI conservó la gestión de usuarios, la carga de archivos y la visualización de respuestas. Una función Pipe pasó a enviar el último mensaje, las reglas del sistema y los archivos adjuntos a un Agent Runtime externo. El propio servicio de ejecución, que utiliza Agents SDK o Codex SDK, almacena ahora el estado de la conversación.

Para el equipo, lo importante es que las responsabilidades estén claras. En el modo de ingeniería, un único servicio gestiona el historial, las herramientas y la continuación de la tarea. Ya no tiene que reconstruir la memoria de trabajo a partir de la conversación de la interfaz. Aun así, un Runtime independiente no garantiza por sí solo un contexto reducido: siguen haciendo falta reglas de almacenamiento y compresión.

Hubo que comprobar la respuesta en streaming evento por evento

El cambio a Responses API destapó otra trampa. La llamada a una herramienta aparecía en los eventos intermedios del flujo, pero output estaba vacío en el objeto final. La versión instalada del SDK obtenía el resultado del turno de ese objeto final, y el agente repetía las llamadas hasta agotar el límite de pasos.

Una herramienta de diagnóstico independiente que recopilaba los elementos completados del flujo permitió continuar el proceso. Sin embargo, el autor no determinó dónde se perdían los datos: no se comparó el flujo antes y después del proxy. Este caso no permite atribuir el problema a la propia API.

Tras actualizar las dependencias, el autor informó de seis escenarios de API completados correctamente, sin recurrir de forma oculta a Chat Completions como alternativa. Las comprobaciones en el navegador, la carga paralela sostenida y algunos escenarios de recuperación del estado quedaron fuera de las pruebas de aceptación.

En su propio sistema conviene repetir tres comprobaciones: analizar el historial real de solicitudes, probar el resumidor con el tamaño máximo de entrada y confirmar en los registros el protocolo utilizado realmente. Este caso muestra cuántos errores pueden ocultarse tras una respuesta del agente que parece correcta.