Equipo Easybits
10 min de lectura
eve
Actualizado el 23 de septiembre de 2026 para eve 0.64+. eve 0.64 cambió la forma de declarar sandboxes (de
defineSandbox({ backend, bootstrap })a providers conenvironment.open()). Todo lo de abajo está probado con eve 0.65 y@easybits.cloud/eve-sandbox0.2. Si sigues en eve 0.63 o anterior, fija@easybits.cloud/eve-sandbox@0.1.
eve es el framework open-source de agentes de Vercel: un agente es un directorio (instrucciones, tools, canales, schedules) y cada sesión es un run durable del Workflow SDK. Cuando el agente necesita ejecutar código, eve le pide una caja a un provider de sandbox. Trae varios (Vercel Sandbox, Docker, microsandbox, just-bash) y deja la interfaz pública para que alguien más escriba el suyo.
@easybits.cloud/eve-sandbox es ese provider para EasyBits: cubre el contrato completo y cada sesión de tu agente corre en su propia microVM Firecracker, en tu cuenta, cobrada con tu plan en pesos. Cambias un archivo y el agente no se entera.
Hay dos formas de usarlo, y conviene elegir antes de empezar:
Necesitas Node ≥ 24 en tu máquina (lo exige eve). Si ya tienes un proyecto eve, salta al npm i:
El export const environment es obligatorio: eve build lo busca para preparar la plantilla antes de que exista cualquier sesión.
El scaffold de eve init apunta al AI Gateway de Vercel (model: "spacexai/grok-4.7" como string), que fuera de Vercel pide AI_GATEWAY_API_KEY. Para llamar a un proveedor directo, eve ya trae helpers; no hay que instalar nada:
Con OpenAI es igual: openai() de eve/models/openai, que lee OPENAI_API_KEY.
Con EASYBITS_API_KEY en el entorno, en tu laptop:
eve start en local responde 401 incluso desde localhost (el localDev() del scaffold se ignora en producción): para probar en tu máquina usa eve dev --no-ui, o declara httpBasic como en la ruta 2. En Vercel (o cualquier Node 24) eve start sigue igual: el servidor corre ahí y cada sesión que necesite código pide su caja a EasyBits.
Lo probamos con una cuenta gratuita recién creada: el agente corrió cowsay (instalado en el prepare) dentro de su microVM en el primer mensaje.

eve build llama al prepare() del provider: levantamos una caja temporal node, copiamos tu agent/sandbox/workspace/ a /workspace y tus skills a ~/.agents/skills, corremos tu prepare(sandbox), capturamos el resultado como plantilla derivada con clave de contenido (POST /sandboxes/:id/template-snapshot, 12-24 MB) y destruimos la caja temporal. El siguiente build encuentra la plantilla y no reconstruye nada (reusada): medido, 0.3 s contra 9.7 s la primera vez. Si cambias el prepare, el workspace o las skills, sale una plantilla nueva; si no la usas en 30 días se borra sola.
Cuando una sesión pide caja, environment.open() llama a start(): la caja nace desde esa plantilla (POST /sandboxes con templateKey + templateHash), con todo lo del prepare ya hecho, en ~5 s. Entre turnos la caja duerme con snapshot de la VM completa y despierta en ~1 s; si el servidor reinicia, eve llama a resume() con el estado que guardó y la reabre con el disco tal cual lo dejó. Si esa caja ya no existe, resume() falla (es lo que pide el contrato de eve) y eve abre una sesión nueva. Detener la sesión la duerme; borrarla la destruye. run() y spawn() corren en login shell con stdout y stderr en streams, y kill() señala al grupo de procesos entero.

Sólo a los dominios que tú autorices para esa caja, o a ninguno ("deny-all"). También se cambia en caliente con sandbox.setNetworkPolicy(...), se conserva al dormir y despertar, y si un dominio no está en la lista la conexión simplemente no sale. Es el mismo shape que usa eve en Vercel Sandbox, así que el código de tu agente no cambia. Lo único que no hacemos es transform (inyectar headers en el firewall): lanza un error claro en vez de fingir.
s (512 MB).Cuando tu agente atienda varias conversaciones a la vez, o necesite sesiones más largas o más grandes, pasa a Mega ($499 MXN/mes, 2 cajas, sesiones de 4 h) o Tera ($2,490 MXN/mes, 5 cajas, 24 h). Mega es también el mínimo para la ruta 2.
Aquí el servidor eve corre en una caja eve-nitro y cada sesión en su caja hija: son dos cajas concurrentes como mínimo, por eso no cabe en Byte. A cambio el servidor tiene URL pública, su estado sobrevive a la máquina y no necesitas nada fuera de EasyBits.
El template eve-nitro trae Node 24, pnpm y el CLI de eve 0.65, así que eve init usa pnpm. El flag --allow-build=cbor-extract es obligatorio con pnpm 12: sin él pnpm add falla con ERR_PNPM_IGNORED_BUILDS (lo necesita eve-world). /data es el volumen persistente, pero no el directorio de trabajo: exec arranca en /, por eso cada comando hace cd /data explícito.
Los archivos del agente se escriben con el endpoint de archivos del REST v2 (POST /sandboxes/:id/files/write, contenido en texto o "encoding":"base64"). Así sube agent/sandbox.ts (el mismo de la ruta 1); agent/agent.ts y agent/channels/eve.ts de los pasos 2 y 3 van igual:
Igual que en la ruta 1, más una línea: el estado durable de eve va a EasyBits DB con @easybits.cloud/eve-world, en agent/agent.ts:
En producción eve exige auth en su API HTTP: con el scaffold (vercelOidc()/localDev()/placeholderAuth()) la URL pública responde 401 Authorization is required for this route. Edita agent/channels/eve.ts:
eve build prepara la plantilla de las sesiones, así que necesita EASYBITS_API_KEY en el env del exec (sin él: @easybits.cloud/eve-sandbox: falta apiKey).
La caja eve-nitro nace con EASYBITS_DB_URL en su entorno (sin token), así que el world lo encuentra solo. Para retomar runs en una caja nueva, créala con el mismo valor ("env":{"EASYBITS_DB_URL":"…"} en el POST /sandboxes); lo lees en metadata.eve_db_url de la caja original. Sin él, eve cae al disco de la caja sin avisar. La URL pública proxea /eve/ y /.well-known/workflow/ sin configurar nada, pero eve pide la auth que declaraste, así que cada llamada va con -u eve:$EVE_PASSWORD.
Tres llamadas: crear la sesión devuelve { sessionId }, el stream es NDJSON de eventos (message.completed trae la respuesta) y el mismo id acepta más mensajes:
Por default eve guarda el estado de cada run en el disco del servidor. Con eve-world (la línea world del paso 2) ese estado —runs, pasos, hooks, streams y la cola de entregas— vive en EasyBits DB. Es parte de esta ruta y no de la gratis: la URL de la base es de la red interna de EasyBits, sólo se alcanza desde una caja.
Lo volvimos a medir con eve 0.65: le dimos al agente una palabra clave, destruimos la caja del servidor y levantamos otra con el mismo EASYBITS_DB_URL. El servidor nuevo quedó listo en 21 segundos y, al preguntarle por la misma sesión, recordó la palabra y volvió a su misma caja de sesión. Antes, con eve 0.58, un run de 8 pasos cortado a la mitad retomó en el paso siguiente sin repetir los anteriores. Es un port del world oficial de Postgres a libSQL, en la misma línea de versiones que eve.
Ruta 1: crea el proyecto, instala el paquete, escribe agent/sandbox.ts y agent/agent.ts, y corre eve build y eve dev/eve start donde ya lo corrías; gratis, una conversación a la vez. Ruta 2: sube a Mega y sigue los seis pasos. La página del producto está en /eve, la referencia en /docs/eve.md y tu propio agente puede configurarlo con npx skills add https://www.easybits.cloud --skill easybits-eve.