llm-echo 0.5: simula tokens del LLM sin gastar en APIs

llm-echo 0.5: un plugin que simula tokens sin llamar a ningún modelo

Simon Willison publicó el 18 de octubre de 2026 la versión 0.5 de llm-echo, un plugin de debug para su herramienta de línea de comandos LLM. En el ejemplo que acompaña al release, una consulta de dos palabras devuelve un conteo de 2 tokens de entrada y 24 de salida — y ningún modelo de IA intervino en el proceso.

Para un equipo que construye productos sobre APIs de modelos, eso no es una curiosidad de terminal: es una forma de testear la plomería de tu producto sin pagar por cada iteración. El plugin existe justamente porque probar prompts, plantillas y flujos de agentes contra un proveedor real es lento, caro y difícil de replicar en un pipeline de integración continua.

¿Qué es exactamente llm-echo y cómo funciona?

llm-echo no es un modelo: es un plugin que se registra dentro de la CLI LLM como si fuera uno, bajo el nombre echo. En lugar de enviar el prompt a un proveedor, repite el contenido que recibió y expone la estructura interna de la llamada. El propio autor lo describe como un plugin de debug que provee un modelo de eco.

En el ejemplo publicado, la salida incluye un objeto con los campos prompt, system, attachments, stream y previous. Es decir: no solo ves qué texto entró, sino cómo lo empaquetó la herramienta antes de mandarlo. Eso es exactamente lo que necesitas cuando un prompt sale bien en tu notebook y mal en producción.

El release llegó de forma casi lateral: Willison está trabajando hacia una nueva versión de LLM, y probar pull requests lo llevó a revisitar este plugin. Es un patrón conocido en proyectos de infraestructura para desarrolladores: la herramienta de diagnóstico se mantiene al día porque quien la construye la usa para su propio trabajo.

¿Qué cambió en la versión 0.5?

El cambio central está en el conteo simulado de tokens. La nueva versión actualiza esos conteos para tomar en cuenta tres cosas que antes quedaban fuera del cálculo:

• Tool calls: las llamadas a herramientas que un agente dispara durante una conversación.
• System prompts: las instrucciones de sistema, que en muchos productos son bloques largos y fijos que se repiten en cada request.
• Reasoning tokens: los tokens internos que consumen los modelos con modo de razonamiento, invisibles en la respuesta final pero facturados igual.

Ese trío es precisamente el que hace que las estimaciones de costo de un producto con IA se desvíen de la realidad. Un chat simple y un agente con cinco herramientas y razonamiento extendido pueden compartir la misma interfaz y tener estructuras de gasto completamente distintas.

¿Cómo se usa en la práctica?

El comando de ejemplo es una sola línea. Se ejecuta el plugin sin instalarlo de forma permanente, se elige el modelo echo y se pide el detalle de uso:

uvx --with llm-echo llm -m echo 'hi there' -o thinking 1 --usage

La respuesta incluye el eco del prompt y el conteo de tokens. La opción -o thinking 1 activa el modo de razonamiento simulado, y --usage muestra el detalle de consumo. Como el modelo no existe del otro lado, el resultado es determinista: el mismo input produce el mismo output, siempre.

Esa determinismo es la razón por la que un plugin así termina siendo útil más allá del debug puntual. Es la diferencia entre testear contra un sistema que responde distinto cada vez y testear contra uno que se comporta igual todas las veces.

Por qué el conteo de tokens sigue siendo el punto ciego del desarrollo con IA

La CLI LLM es una utilidad de línea de comandos que permite conversar con servicios como ChatGPT, Gemini y Claude usando comandos de shell y plugins dedicados, según describió MacStories en su guía para procesar transcripciones de YouTube desde la terminal. En ese ecosistema, cada proveedor tiene su propio plugin y su propio esquema de cobro.

El problema es que la factura no la decide el prompt que escribiste, sino todo lo que la herramienta agrega alrededor: el system prompt, los esquemas de las herramientas, el historial de la conversación y los tokens de razonamiento. En un flujo con agentes, una sola acción del usuario puede disparar varias llamadas encadenadas. Sin visibilidad sobre esas capas, optimizar costos se vuelve adivinanza.

Un plugin de eco no resuelve el problema de fondo, pero sí te deja medir la parte que controlas: cuánto pesa tu propia estructura antes de que un proveedor la interprete.

¿Qué significa esto para tu startup?

Si estás construyendo un producto con agentes, la lección no es "instala este plugin". Es que necesitas una capa de simulación en tu propio stack. Dos acciones concretas para esta semana:

• Separa tus tests en dos capas. Una que valide la lógica de tu aplicación con un modelo falso como echo (rápida, gratuita, determinista) y otra que valide la calidad de las respuestas contra un proveedor real, ejecutada con menos frecuencia. Si cada test de tu pipeline golpea la API de pago, tu equipo deja de correr tests.
• Audita la estructura de tus llamadas, no solo el resultado. Revisa qué proporción de cada request es system prompt, qué herramientas estás declarando y si todas se usan. Los tres puntos que la versión 0.5 incorpora al conteo son los mismos tres que suelen explicar una factura que no cuadra a fin de mes.

Y una nota de disciplina: antes de adoptar cualquier herramienta de debug en producción, verifica que no filtre contenido de tus prompts a logs o servicios externos. Un plugin de eco es seguro porque no sale de tu máquina; no todas las utilidades de observabilidad tienen esa propiedad.

No se encontraron datos adicionales verificables sobre métricas de adopción o usuarios de llm-echo en el research realizado para esta nota.

Fuentes

• llm-echo 0.5 — Simon Willison's Weblog (fuente original)
• Using Simon Willison's LLM CLI to Process YouTube Transcripts in Shortcuts with Claude and Gemini — MacStories