---
title: "fx de Vercel: el agente de código escrito en Zig"
excerpt: "Vercel Labs liberó fx, un agente de código en un binario nativo de 7,8 MiB, Apache-2.0 y agnóstico de modelo. Qué trae por dentro, qué detalles no cuenta el anuncio (el revisor automático de permisos cuesta tokens aparte) y para qué sirve de verdad."
date: "2026-08-18T10:30:00.000Z"
category: "Inteligencia Artificial"
author:
  name: "angel cruz"
  picture: "/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/vercel-opengraph-image.png"
seo_title: "fx de Vercel: qué es el agente de código escrito en Zig"
seo_description: "Qué es fx, el agente de código de Vercel Labs escrito en Zig: un binario de 7,8 MiB, instalación, modelo por defecto, permisos, skills y MCP, y en qué se diferencia de Claude Code."
tech_article:
  article_section: "Inteligencia Artificial"
  keywords: "fx vercel, que es fx vercel, agente de codigo zig, agente de codigo ligero, fx vs claude code, fx.sh, cli agente ia, ai gateway, acp agent client protocol"
---

**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

```bash
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:

```bash
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:

```bash
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:

```json
{
  "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](/post/skills-claude-code) y por qué [no matan a MCP](/post/han-muerto-los-mcp-por-culpa-de-skills), 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](/post/introduccion-a-mcp-model-context-protocol).

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](/post/subagentes-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":

| Superficie | Para qué |
| --- | --- |
| `fx acp` | Conectar el agente nativo a editores y clientes que hablen Agent Client Protocol |
| `createFxAgent()` | Empotrar el núcleo en un host JavaScript con `fx-core.wasm` |
| `createFxTerminal()` | Empotrar la terminal interactiva con `fx-term.wasm` |

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](/post/clis-orquestar-agentes-ia): 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.

| | fx | Claude Code | Codex CLI |
|---|---|---|---|
| Implementación | Zig, binario nativo | Node.js | Rust |
| Instalación | binario suelto, sin runtime | requiere Node | binario nativo |
| Modelo | agnóstico, por AI Gateway | Claude | modelos de OpenAI |
| Empotrable | binario, ACP y WebAssembly | CLI y SDK | CLI |
| Estado | experimental, cambios frecuentes | maduro | maduro |

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

### ¿Qué es fx de Vercel?

Un agente de código open source de Vercel Labs, escrito en Zig y distribuido como un único binario nativo. Sirve tanto para usarlo en la terminal como para empotrarlo dentro de otros sistemas. Es Apache-2.0 y está marcado como experimental.

### ¿Es lo mismo que el fx de JSON?

No. El visor de JSON de terminal es de Anton Medvedev, vive en `fx.wtf` y en el paquete `fx` de npm. Comparten nombre y nada más.

### ¿Cuánto pesa fx?

El README declara 7,8 MiB y la web del proyecto cita 6,39 MiB, así que la cifra se mueve entre versiones. En reposo dicen usar memoria de un dígito de megabytes.

### ¿fx es gratis?

El software sí, es Apache-2.0. Lo que pagas es la inferencia: fx enruta por Vercel AI Gateway, con tu cuenta de Vercel o una API key. También admite endpoints locales, y ahí no hay coste por token.

### ¿fx reemplaza a Claude Code?

Hoy no, y su propia documentación no lo pretende. Es experimental, avisa de cambios frecuentes y no tiene herramientas de navegador. Donde sí es mejor opción es como pieza de infraestructura: sandboxes, evals, benchmarking de modelos o un agente dentro del navegador.

### ¿Funciona en Linux y en Windows?

El instalador oficial cubre Linux y macOS. El sandbox de comandos nativo, en cambio, solo existe hoy en macOS; en Linux la configuración `auto` se queda sin aislamiento propio de fx.

### ¿Qué modelo usa por defecto?

`zai/glm-5.2-fast`, a través del catálogo de Vercel AI Gateway. Se cambia con `FX_MODEL`, con `/model` dentro de la sesión o en `~/.fx/settings.json`. Un repositorio no puede cambiártelo desde su `.fx.json`.

### ¿Puedo usar mis skills de Claude Code en fx?

Sí. fx descubre skills en `.claude/skills/`, `.codex/skills/`, `.opencode/skills/`, `.agents/skills/` y `.claw/skills/`, además de las suyas. No hay que mover nada.

## Recursos

- Sitio y documentación: [fx.sh](https://fx.sh) y [fx.sh/docs](https://fx.sh/docs)
- Código: [github.com/vercel-labs/fx](https://github.com/vercel-labs/fx)
- Probar en el navegador: [fx.sh/try](https://fx.sh/try)
- Compilar desde fuente: requiere [Zig 0.16.0+](https://ziglang.org/download/) y `zig build -Doptimize=ReleaseSafe`

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/fx-vercel-agente-codigo-zig](https://www.angelcruz.dev/post/fx-vercel-agente-codigo-zig)