Vercel Labs Dropped a Coding Agent Written in Zig

Vercel Labs just released fx — a coding agent written in Zig. Not TypeScript, not Python, not Go. Zig.

That's the headline. The rest is details, but this choice tells you everything about where Vercel thinks the agent tooling space is going: smaller, faster, embeddable, and radically simpler than the "IDE in your terminal" approach everyone else is chasing.

What Is fx?

fx is a coding agent harness and CLI that describes itself as "Unix-like" — closer to awk than Cursor. It ships as a single native binary (7.8 MiB compressed) written entirely in Zig 0.16+, with no Node.js dependency, no Python runtime, no container required.

Version 0.0.4 dropped today on GitHub (Apache-2.0). It's very early — the README says experimental, the changelog is one entry — but the architecture is already more complete than most agents that have been iterating for a year.

What Makes It Different

1. Zig, Not JS/TS

Every other notable coding agent picks a high-level language:

• Claude Code — TypeScript (Node.js)
• Codex — Go
• OpenClaw — Python
• Cline — TypeScript (VS Code extension)
• fx — Zig

Zig gives fx a genuine advantage: no runtime dependency, no garbage collector pauses, deterministic resource management, and a binary small enough to ship as a CLI tool the way Unix intended. The tradeoff is a smaller ecosystem and steeper contribution curve, but for a tool that's meant to be embedded, piped, and composed, the payoff is real.

2. Embeddability as a Design Goal

fx doesn't just want to be a CLI — it's designed to be a library. The build system produces three WebAssembly targets:

• fx-core.wasm — The agent core, embeddable in any JavaScript host
• fx-term.wasm — The interactive terminal renderer
• Native binary — The full CLI experience

The WebAssembly SDK lets apps embed a full coding agent without subprocessing out to a separate process. This is the direction the docs push hardest: createFxAgent() in your JS app, get a coding agent. No containers, no REST API, no daemon.

3. Permission Model That Treats Agents as Untrusted

fx's permission system is refreshingly paranoid. Instead of asking the agent to be honest about what it needs, fx enforces at the gateway layer:

graph TD
  A[User Prompt] --> B[Agent Loop]
  B --> C{Tool Call}
  C --> D[Permission Gate]
  D -->|Allowed| E[Execute Tool]
  D -->|Blocked| F[Request Approval]
  F --> G{User Decision}
  G -->|Allow| E
  G -->|Deny| H[Block Action]
  E --> I[Result → Agent Loop]

This mirrors what OneCLI (also launched today, YC S26) calls "zero-trust for agents" — the model doesn't hold real credentials, can't bypass the gateway, and every tool invocation gets logged with provenance. The difference is fx bakes this into a single binary rather than a separate proxy service.

4. Subagent Delegation

fx supports spawning subagents — child agent processes that get their own context, tool set, and budget. This is more than just "fork a thread": subagents have constrained permissions, independent session state, and can be monitored for completion. The orchestration model is built into the core runtime, not bolted on via MCP.

Building and Running

I cloned the repo and built it from source. The process was refreshingly straightforward:

git clone https://github.com/vercel-labs/fx.git
cd fx
zig build
./zig-out/bin/fx --help

The build completed in seconds (Zig's compiler is fast). The resulting binary at zig-out/bin/fx is 182 MB in debug mode — the release build with LTO and stripping likely hits the advertised ~7.8 MiB.

Running it without configuration shows the full help system. The CLI is well-designed: kebab-case flags, sensible defaults, and a --json mode for scripting. The help output is the most polished part of the experience so far — better than most production tools.

I wasn't able to run a full agent loop without a Vercel AI Gateway API key or GitHub OAuth, so the actual agent experience is gated behind Vercel's ecosystem. That's the tradeoff: you get a polished auth and billing pipeline, but you're inside Vercel's garden to use it out of the box.

Rough Edges (v0.0.4)

• Vercel dependency — You need either fx login (Vercel OAuth) or fx setup (AI Gateway API key) to run real requests. Bring-your-own-model isn't a CLI flag yet; it's buried in gateway configuration.
• No offline mode — Unlike local-first agents, fx requires gateway connectivity even for basic operations. The docs mention local inference support but the setup path is cloud-first.
• Experimental stability — The README warns about frequent breaking changes. The session format, permission model, and tool interfaces are all in flux.
• WebAssembly SDK is nascent — The WASM targets exist but the JS bindings are thin. The examples show basic embedding but there's no real-world usage yet.
• Subagent tooling is untested — The subagent domain model is the most complex subsystem in the codebase (~2,000 lines across domain, tool_provider, and tool_result) but the tests are minimal.

The Broader Picture

fx arriving from Vercel Labs is a signal. Vercel has been building developer tooling infrastructure for years — Next.js, Turborepo, the AI SDK — and they see agent tooling as the next platform layer. Their bet is that agents will be composed like Unix pipes, not run as monolithic IDEs.

The timing is interesting: today also saw the launch of OneCLI (YC S26), another agent harness with a very similar permission philosophy but built in TypeScript. The convergence is telling — everyone is realizing that agent security isn't about model alignment, it's about network-level enforcement outside the model's reach.

Bottom Line

fx is too early to recommend for production use. But the architectural choices — Zig, embeddability via WASM, Unix-like philosophy, gateway-level permissions — point in a direction I think the entire agent tooling space will follow within 18 months. The era of "install Node.js, install 400 dependencies, run an Electron app" for coding agents is ending. The era of curl https://agent.sh | bash is beginning.

Watch Vercel Labs on this one. They have a habit of shaping where developer tooling goes next.