Tengo un montón de agentes corriendo en mi propia infraestructura: crons que publican este blog, scripts que monitorean dominios, respaldos que toman decisiones con un modelo encima. Todos usan APIs de LLM. Hace un mes les cerré la puerta: en vez de tener las API keys regadas por media docena de scripts, las puse detrás de un solo punto de entrada. Eso arregló la pega de las credenciales, pero me faltaba la otra mitad del problema: saber qué está pasando realmente en cada llamada.
Ayer andaba fuerte en Hacker News un post de Jared Siegel con una pregunta que no trae respuesta amable: si no corres tu propio proxy de LLM, ¿cómo pretendes saber qué está pasando? A mí me quedó pillo, porque es exactamente lo que viví.
El panel de «analytics» del proveedor es un juguete
El argumento típico es «el proveedor ya te da telemetría». Que no. Los paneles de los proveedores tienen barras bonitas y el gasto del mes. Sirven para presumir qué tan sofisticado es su software; no sirven para que un ingeniero tome una decisión. No me dicen qué key llamó a qué modelo, desde qué cliente, a qué hora ni qué devolvió. Tampoco explican por qué una llamada tardó 40 segundos cuando las otras toman 3, ni por qué un cache miss me está cobrando doble en una sesión larga.
Si tu agente hace 200 llamadas nocturnas por cron, ese nivel de detalle no es lujo: es lo mínimo para saber si está haciendo bien su pega.
Lo que ganas de una vez
Mi versión de los cinco argumentos que da el post, contrastada con lo que ya tengo andando:
Un solo lugar de logs. La data es tuya y está en un servidor que controlas, no en el panel de un tercero que decide qué mostrar y cuándo borrarla.
Virtual keys por agente. En vez de la llave principal en todo lado, cada cron tiene la suya. Si un script se devuelve, la revoco en un minuto y el resto ni se entera. Después de haberlas tenido regadas, no vuelvo atrás por nada.
Cambiar de proveedor sin rehacer nada. Los agentes no hablan con OpenAI ni con Anthropic: hablan con mi endpoint. Cambiar el modelo de fondo es tocar una línea de configuración, no editar seis scripts a las 11 de la noche.
Debugeo real. Cuando una respuesta llega cortada o el cache falla, abro el log y veo la petición completa, cabeceras incluidas. Lo que antes era adivinar, ahora son 20 segundos con el log abierto.
Mi setup y mi opinión
Las llamadas de mis agentes pasan por un proxy autoalojado en el mismo VPS donde corren los crons. Lo modifiqué para mis cosas: agrego cabeceras con el nombre del job y dejo en disco cada request y respuesta, por si hay que auditar después. ¿Sobre-ingeniería para un blog personal? Quizá. Pero cuando un agente se equivoca a las 4 AM y hay un desastre por revisar, el detalle de qué prompt se envió, qué respondió el modelo y cuánto costó es la diferencia entre arreglarlo en minutos o adivinar por horas.
Un matiz donde difiero del autor: él lo hace en parte porque es entretenido y es como le gusta aprender. Mi caso es más chato: corre en producción, manda mensajes de verdad y gasta plata de verdad. Si no instrumentas eso, estás operando a ciegas. La observabilidad de LLM está hoy donde estaba el monitoreo web a inicios de los 2000: cada improvisando por su cuenta. Corre tú mismo el proxy, aunque sea mínimo, antes de que un agente haga algo raro y no tengas cómo rastrear de dónde vino la wea.
Fuente del tema: If you don’t run your own LLM proxy, how do you know what’s going on?, de Jared Siegel.
Fuente de inspiración: If you don’t run your own LLM proxy, how do you know what’s going on? (Hacker News)
