Vercel open-sources fx, an AI agent written in Zig built to run embedded

Vercel Labs, Vercel's experimental group (the company behind Next.js), has open-sourced fx, a coding agent and command-line tool written in Zig. The project was announced in August 2026 and now arrives as open source with a proposal quite different from most AI agents for developers: instead of taking over the screen with a persistent interface, fx was designed to be scripted or embedded inside other applications.

According to Vercel, fx's native binary is 6.3 MiB, uses single-digit megabytes of memory, and has a cold start of 10 microseconds. These are figures the company itself publishes, not independently verified benchmarks, and it's worth keeping that caveat in mind when evaluating the project for production.

Built to be embedded, not to take over the screen

Most terminal coding agents (Claude Code, Cursor, OpenCode) take over the screen with a full-screen interface. fx does the opposite: it writes the conversation to the terminal's regular scrollback, like any other command, and exposes the same engine both as a CLI and as a library.

In practice, this means a CI script can call fx, request structured JSON output, and parse the response without having to deal with an interactive interface:

fx ask --json "summarise the failing tests"

Code editors can also connect via the Agent Client Protocol with fx acp, which opens the door to integrating fx with IDEs and other tools that already speak that protocol, instead of relying on a proprietary integration.

The path to JavaScript: libfx and WebAssembly

The most interesting angle for anyone building agent infrastructure is libfx, the layer that exposes fx's engine to JavaScript, including a WebAssembly build. It's this piece that makes it plausible to run the same agent inside a web application, an editor extension, or a Node pipeline, without spinning up a Python runtime or orchestrating a heavy external process.

Vercel has already slotted fx into the AI SDK's own harness layer, alongside Claude Code, Cline, Codex, Cursor, OpenCode, and Pi, presenting it as one more option behind a shared interface. For those who already use the AI SDK to abstract away agent providers, switching tools at this point tends to be less costly than rewriting the integration from scratch.

Which model it actually depends on

fx presents itself as model-agnostic, but early feedback on Hacker News questioned that promise: some first-run reports pointed out that the default configuration routed inference through the Vercel AI Gateway, and commenters compared fx's still somewhat unpolished terminal experience to OpenCode's.

One of these comments summed up both the skepticism and the interest at the same time:

Just tried and although it's not that polished or fast imo it's very cool. GLM 5.2 totally free even with a free Vercel account. Make business sense too - fx is the entry point to bring more user to Vercel AI.

Hacker News user comment

Since then, provider choice has broadened. Version 0.0.11 added named connections compatible with the OpenAI API for local servers and alternative gateways, and the project's README now lists Vercel AI Gateway, ChatGPT and Grok subscriptions, as well as endpoints like Ollama and OpenRouter. For those who want to run a local model or avoid lock-in to a single gateway, this changes the adoption calculus.

A name that already existed

A practical complication: the name fx collides with a terminal JSON viewer that's been established for years, which is also called fx and holds the fx formula on Homebrew. A GitHub issue on Vercel's project flagged the conflict, and a contributor confirmed that packaging and the coexistence of the two commands are being reviewed. Anyone who already uses the original fx to inspect JSON needs to pay attention when installing Vercel's agent, to avoid overwriting the wrong binary.

Still pre-1.0 (and that matters for anyone embedding it)

Vercel is explicit about it: fx is experimental and changes fast. Version 0.0.13, released on October 4, 2026, added an Ultrafast mode on supported OpenAI models, with faster launches and shell calls, but it brought a relevant warning for those embedding the engine: libfx checkpoints saved by the new version can't be restored by older versions.

For CLI users, the way forward is to update with fx upgrade and read the changelog first. For those embedding libfx in another application, the library's migration guide explains that the old createFxAgent() call became createFxEngine() in the current documentation. It's the kind of breaking change that won't break a standalone script, but can break a production pipeline that persists state across versions, exactly the scenario the embedded-by-design proposal should make easier.

What this means for those building with agents

fx doesn't compete directly with polished terminal assistants like OpenCode. Vercel's bet is a different one: treat the coding agent as a composable piece of infrastructure, small enough to run in a binary of a few megabytes or inside a WebAssembly build in the browser, and simple enough to be called from a CI script without spinning up a whole Python runtime.

For teams that already think of AI as an automation layer rather than a chat, fx is worth testing, but with feet on the ground: a still pre-1.0 API, a checkpoint format that changes between minor versions, and (even if optional) dependence on the Vercel AI Gateway are real risks for anyone putting this into a pipeline that needs medium-term stability. The project's repository documents the CLI, skills, MCP, permissions, and SDK, and there's a browser demo for anyone who wants to see the terminal behavior without installing anything.