Ghosty Lite: un agente en su propia microVM, punta a punta

Ghosty Lite es nuestro agente ligero: un binario en Rust, derivado de goose, que habla ACP y vive en una microVM propia con su disco, su shell y su proveedor de modelo. Este post es el recorrido completo por la API, tal como lo corrimos hoy, con los tiempos que medimos y sin omitir el paso que suele fallar.

0. Las dos llaves

Antes de la primera llamada conviene tener claro qué llave va dónde, porque son cosas distintas:

• Tu llave de Easybits (eb_sk_…). Va en el header Authorization de cada request. Es la que te identifica como dueño del agente.
• La llave del modelo (DEEPSEEK_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY…). Va en el env del agente al crearlo. Easybits la escribe dentro de la microVM, en el archivo de entorno del servicio, y el binario la lee por nombre. Nunca vuelve a salir por la API.

Hay una tercera que no ves: el token interno con el que el frontal de la caja habla con el proceso del agente. Se genera al arrancar la VM y no existe fuera de ella. Si alguien llega al puerto del agente sin él, recibe un 401.

1. Crear el agente

Respuesta, en 1.3 segundos:

Lo que pasó en ese segundo: se reservó la microVM, se creó la fila del agente en estado building y se disparó el arranque en segundo plano. La respuesta no espera a que el agente esté listo, y eso es a propósito: tu UI puede pintar la tarjeta ya.

GHOSTY_PROVIDER acepta cualquier proveedor de goose: anthropic, openai, custom_deepseek, ollama… Si mandas sólo DEEPSEEK_API_KEY sin proveedor, la caja elige DeepSeek sola.

2. Esperar a que esté listo

Hoy pasó de building a running en unos 6 segundos. En ese lapso ocurrieron cuatro cosas dentro de la caja:

1. La VM arrancó y montó su volumen en /data.
2. systemd levantó el servicio del agente con el env que mandaste.
3. El frontal de la caja respondió /health sólo cuando el proceso del agente ya contestaba, no antes.
4. Easybits hizo el handshake ACP (initialize y session/new) y guardó el id de sesión en la fila del agente.

El punto 4 es el que importa: running significa que ya hay una sesión ACP abierta, no sólo que la VM enciende. Hasta hoy el estado se adelantaba un par de segundos y el primer mensaje podía llegar antes del handshake; ya no.

3. Mandarle un mensaje

La respuesta es un stream SSE con el texto en trozos y un done al final:

Pegado, el agente contestó en 3 segundos:

Listo. Creé /data/work/hola.txt y quedó escrito: 2026-09-02 (fecha de hoy).

Por debajo, Easybits tradujo tu content a un session/prompt de ACP con el sessionId que guardó en el paso 2, y convirtió las notificaciones agent_message_chunk del agente al formato simple que ya consume el widget de embed. Tú no ves JSON-RPC; el agente no ve HTTP tuyo. El mismo endpoint funciona con el embedToken desde un navegador, así que sirve tanto para tu backend como para un chat público.

4. Comprobar en su disco

La microVM es tuya mientras exista. Puedes ejecutar comandos en ella con la misma llave:

Esto es lo que distingue a un agente con máquina de uno sin ella: el archivo existe, lo escribió un shell real, y lo puedes leer por fuera del modelo. /data sobrevive a que la caja se duerma y despierte.

5. Borrarlo

Se destruye la VM con su disco. Si no lo borras, tampoco pasa nada: cuando lleva un rato sin mensajes la caja se duerme sola, y el siguiente mensaje la despierta con su disco intacto.

Lo que se cobra y cómo se sabe

Cada session/prompt devuelve del agente un bloque usage con inputTokens, outputTokens y totalTokens, y una notificación usage_update con el costo estimado. Es el mismo formato que emite goose, así que el consumo por turno se registra igual con Ghosty Lite que con cualquier agente ACP de la plataforma. Si traes tu propia llave del modelo, ese consumo no descuenta de tu plan: el proveedor te lo cobra a ti directamente.

Resumen de tiempos de hoy

Cuatro llamadas, dos llaves, una máquina que es sólo tuya.