fx de Vercel: el agente de código escrito en Zig

Vercel Labs abrió el código de fx, un agente de código escrito en Zig que cabe en un solo binario nativo y arranca sin runtime que instalar. Era una herramienta interna, hoy es Apache-2.0, y el pitch tiene tres palabras: rápido, ligero, abierto.

Lo interesante no es el pitch, que suena igual en todos los lanzamientos. Es lo que se lee en la documentación cuando bajas dos niveles: cómo decide ejecutar comandos, qué modelo trae por defecto, qué te cuesta el modo cómodo y dónde está el límite de "experimental".

Este fx no es el otro fx. Si buscabas fx, el visor de JSON de terminal de Anton Medvedev (20.400 estrellas en GitHub, fx.wtf, el paquete fx de npm), ese es otro proyecto que solo comparte el nombre. Este fx es un agente de código de Vercel Labs, vive en fx.sh y se instala desde ahí.

Aviso antes de seguir: esto sale de la documentación oficial, del repositorio y del propio instalador, no de un benchmark que haya corrido yo. Cuando algo es una cifra suya y no una medición mía, lo digo.

Qué es fx exactamente

Un harness y una CLI de agente escritos en Zig, pensados para investigación y para empotrarse dentro de sistemas más grandes. El repositorio vercel-labs/fx se creó el 11 de agosto de 2026 y lo describen con una frase corta: "Unix like coding agent".

La comparación con Unix no es decorativa, es la decisión de producto. Frente a los agentes que montan una especie de IDE dentro de la terminal, fx conserva el scroll, imprime poco y usa render TUI complejo lo mínimo posible. Es una herramienta de shell, no una interfaz.

Los números que publican: binario de 7,8 MiB (la web del proyecto cita 6,39 MiB, así que la cifra se mueve entre versiones), arranque en frío de 10 microsegundos y consumo de memoria de un dígito de megabytes en reposo. Nada de eso lo he verificado. Sí es verificable lo otro: el repo es casi todo Zig, la licencia es Apache-2.0 y el estado declarado es experimental, con la advertencia de "úsalo bajo tu propio riesgo" en la primera pantalla del README.

Instalación y primer arranque

curl -fsSL https://fx.sh/setup.sh | bash

El script detecta sistema y arquitectura (Linux y macOS), descarga el binario desde releases.fx.sh y lo deja en ~/.local/bin, o donde apunte FX_INSTALL_DIR. No hay gestor de paquetes de por medio ni dependencias que resolver, que es justamente el punto.

Después toca elegir cómo accede a los modelos:

fx login          # iniciar sesión con Vercel
fx setup          # o pegar una API key de AI Gateway
cd tu_proyecto
fx

El directorio actual pasa a ser el workspace primario. Dentro, /help lista los comandos interactivos. Y para uso no interactivo:

fx ask "explica los cambios de este repositorio"

El modelo por defecto no es de Vercel

fx usa el catálogo de Vercel AI Gateway y el modelo compilado por defecto es zai/glm-5.2-fast. Es un detalle que dice bastante: el default de una herramienta que presume de barata y rápida no es un modelo frontera, es uno pensado para responder mucho y costar poco.

El orden de resolución está documentado y se puede cambiar en cualquier capa:

1. FX_MODEL para el proceso actual
2. un override antiguo del workspace, si queda alguno
3. el default de usuario en ~/.fx/settings.json
4. el default compilado

Aquí hay una decisión que agradezco: el .fx.json de un proyecto no puede fijar model, effort ni el modo rápido. Solo acepta cuatro campos públicos (max_agent_steps, max_tool_result_bytes, context y sandbox), así que clonar un repositorio ajeno no te cambia en silencio a qué modelo le estás mandando tu código. Es exactamente el tipo de superficie que otros agentes dejan abierta.

Las herramientas, y lo que falta

El set built-in es corto y previsible: ficheros (read_file, write_file, edit_file, glob_files, grep_files y compañía), run_command, web_search y web_fetch, vision, skill e install_skill, subagent, las de MCP y unas pocas de runtime como ask_user_question, memory y read_tool_result.

Dos matices que la documentación admite sin adornos:

• semantic_search es búsqueda léxica en el repositorio, no un índice de embeddings. El nombre promete más de lo que hace y ellos mismos lo aclaran.
• No hay herramientas de navegador ni CDP. Si tu flujo depende de abrir una página y verla, fx no es tu herramienta hoy.

Sí hay dos cosas bien resueltas. Los comandos en segundo plano quedan como procesos del sistema con registro persistente, log y URL detectada cuando la hay, manejables con /background o fx background --json. Y los resultados grandes de herramienta no entran enteros en el contexto: fx devuelve una vista previa acotada más un handle, y el modelo llama a read_tool_result cuando necesita más. Es la respuesta correcta al problema de que un grep desafortunado se coma la ventana entera.

Permisos: el modo cómodo se paga en tokens

Esta es la parte que no aparece en el anuncio y que conviene leer entera.

Cada llamada a herramienta pasa por un runtime de permisos con tres modos: ask pregunta antes de cada acción sensible sin resolver, yolo desactiva las comprobaciones y el sandbox, y auto es el default.

auto aplica primero tus reglas y tus concesiones de sesión, y lo que queda sin resolver lo revisa automáticamente. ¿Quién revisa? Otro modelo. fx manda una petición aparte a AI Gateway usando openai/gpt-5.4, con independencia del modelo que hayas elegido para el agente, y no hay ajuste público para cambiar el revisor. La documentación lo dice sin maquillaje: una llamada sin resolver en modo auto puede salir más cara que la misma llamada en modo ask.

La consecuencia práctica es clara. Si vas a usar auto, escribe reglas estrechas para lo que ya sabes que quieres permitir o negar, y así esas llamadas nunca llegan al revisor:

{
  "permission": {
    "*": "ask",
    "bash": {
      "git *": "allow",
      "git push *": "deny"
    },
    "edit": {
      "docs/*": "allow",
      "*": "deny"
    }
  }
}

Las reglas viven en ~/.fx/settings.json, usan comodines, gana la última que hace match y las de workspace pesan más que las globales. El .fx.json del proyecto no puede definirlas, otra vez la misma línea trazada en el mismo sitio.

Aparte de los permisos está el sandbox, que es una decisión distinta: permiso responde a si un comando puede ejecutarse, sandbox a qué puede hacer una vez lanzado. El modo os usa el sandbox nativo del sistema y hoy solo existe en macOS; en Linux, auto cae a none. Vale la pena saberlo antes de dar por hecho un aislamiento que en tu máquina no está.

Skills, MCP y subagentes

El núcleo es pequeño y se extiende por fuera, con una decisión de compatibilidad que me parece la más lista del proyecto: fx busca skills en skills/, pero también en .claude/skills/, .codex/skills/, .opencode/skills/, .agents/skills/ y .claw/skills/, tanto subiendo desde el workspace como en el home. Es decir, si ya escribiste skills para otro agente, fx las ve sin que muevas nada. Instala siempre en ~/.fx/skills/ y nunca escribe dentro del directorio de otro agente.

Si vienes de ese mundo, tengo escrito cómo funcionan las skills en Claude Code y por qué no matan a MCP, que es el debate de fondo.

Para MCP hay cliente propio con descubrimiento perezoso de herramientas y namespacing para evitar colisiones con las built-in, más configuración privada en ~/.fx/mcp.json. Si nunca montaste uno, empieza por la introducción a MCP.

Los subagentes son sesiones fx hijas sobre el mismo workspace, con su propio modelo, esfuerzo, modo de permisos y transcripción. Pueden ser de un solo uso o persistentes, y hay un gestor con ctrl+x para crear, mensajear, reparentar y cerrar. Como los mensajes entre padre e hijo se encolan de forma durable, el hijo trabaja sin copiar su transcripción entera al contexto del padre. Es la misma idea que cubrí en subagentes de Claude Code, con menos ceremonia.

Embebido: donde está la verdadera apuesta

fx compila a binario nativo o a WebAssembly, y ahí es donde el proyecto deja de parecer "otra CLI de agente":

Y para scripts y CI, fx ask --json devuelve un objeto con output, exit_code, model, session_id, steps y la lista de tool_calls con su estado. El progreso y los diagnósticos van a stderr, así que fx ask --json "..." | jq -r .output funciona limpio. Ojo con una cosa: fx ask no puede pausar a preguntar, así que en modo auto una llamada sin resolver termina la ejecución antes de correr la herramienta.

Sobre el papel esto encaja mejor en benchmarking de modelos, gyms, evals y sandboxes de agentes que en tu sesión de martes por la tarde. Y encaja con lo que ya conté sobre orquestar agentes desde la CLI: lo que quieres de un agente empotrado no es una interfaz bonita, es salida estructurada y un proceso que arranque y muera barato.

Privacidad

Sin telemetría de producto ni analítica hacia un servicio de fx. fx usage lee registros locales y /trace arma el diagnóstico en tu máquina. Las comprobaciones de actualización leen metadatos estáticos y no llevan identificador de instalación.

El estado privado vive en ~/.fx/: ajustes, sesión de Vercel, sesiones, historial de prompts, uso, configuración y credenciales MCP, skills gestionadas y logs. En macOS la API key va al Keychain, en Linux a ~/.fx/api-key con permisos 0600.

Las peticiones de inferencia salen vía AI Gateway, que no retiene prompts ni salidas después de la petición, aunque sí registra metadatos de facturación. Y fx admite endpoints locales por loopback, así que con inferencia local y actualizaciones automáticas apagadas el conjunto es hermético: sin salida de red, el contexto no sale de la máquina y las herramientas de red no pueden llamar a nadie.

fx frente a Claude Code y Codex

La comparación honesta empieza por decir que no compiten en lo mismo, y en qué eje sí se pueden comparar.

Lo que fx no tiene y ellos sí: herramientas de navegador, madurez y una superficie de funciones amplia. Lo que fx tiene y ellos no: correr sin runtime instalado, compilar a WebAssembly y arrancar tan barato que puedes lanzar cientos de instancias sin pensarlo.

No he medido rendimiento de los tres, ni lo voy a fingir. La diferencia que sí es estructural y no depende de benchmarks es esa: fx es un binario que puedes meter en un contenedor mínimo o en un navegador, y los otros dos no están pensados para eso.

Y hay una ventaja práctica que no cuesta nada aprovechar: como fx lee las skills de .claude/skills/ y .codex/skills/, probarlo no te obliga a reescribir lo que ya tienes.

Entonces, ¿lo uso?

Depende de a qué vayas.

Como reemplazo diario de tu agente actual, hoy no. Es experimental, avisa de cambios frecuentes, no tiene herramientas de navegador y el sandbox real solo existe en macOS. Instalarlo para "probar el agente nuevo" y compararlo con lo que ya usas te va a dejar una impresión tibia, porque no compite en esa liga.

Como pieza de infraestructura, es otra conversación. Un binario de menos de 8 MiB, sin runtime, con --json, ACP y build a WebAssembly es exactamente lo que hace falta cuando quieres cien agentes en cien sandboxes, o un agente dentro del navegador, o una batería de evals donde el arranque del proceso no puede ser el cuello de botella. Ahí el minimalismo deja de ser estética y pasa a ser la característica.

Lo que más me gusta no es la velocidad, es dónde pusieron los límites: el proyecto no puede cambiarte el modelo, el revisor automático está documentado con su coste en vez de escondido, y las skills de otros agentes se leen tal cual. Son decisiones de alguien que ha usado estas herramientas, no solo construido una.

Preguntas frecuentes

Recursos

• Sitio y documentación: fx.sh y fx.sh/docs
• Código: github.com/vercel-labs/fx
• Probar en el navegador: fx.sh/try
• Compilar desde fuente: requiere Zig 0.16.0+ y zig build -Doptimize=ReleaseSafe