fx: Vercel Labs' experimental Zig coding agent that behaves like a Unix command

The banner says experimental, and the version numbers agree

The README opens with an ASCII logo, the line Tiny, open, embeddable, native coding agent, the install command, and a status line: Experimental. Use at your own risk. The releases back that up. The newest are v0.0.16 on 2026-10-29, v0.0.15 on 2026-10-27 and v0.0.14 on 2026-10-16, which is a rapid sequence of zero-point versions.

fx is described as a minimal coding agent CLI that still comes with batteries included. It is one native binary written in Zig, so there is no runtime to install, and it is said to run the same on a laptop, in CI or inside an agent sandbox. The practical meaning of experimental is that flags, file formats such as saved sessions and the embedding API may change between releases. Pin a version if a script depends on it.

Its output is closer to a Unix shell than an IDE, because the conversation prints into your terminal and editors reach it over a protocol instead of a plugin. That positioning is the whole design: fx wants to be one more command that you pipe, script and embed, and it leaves editing surfaces to the editors that connect to it.

The speed promise is enforced in CI, but only for start-up commands

The project says CI fails a pull request if any benchmarked command, such as fx help or fx status --json, takes longer than 2 ms on Linux. Stable releases for Apple silicon must also fit under a fixed size limit. A benchmarks directory in the repository holds the harness.

Read the claim for what it covers. The benchmarked commands are local ones that do not call a model, so the 2 ms limit says nothing about how long an agent turn takes, which depends on the model provider and the task. What it does guarantee is that invoking fx from a script or a shell prompt costs almost nothing, which matters when you call it many times in a pipeline.

Installation is a piped script for macOS and Linux only

The install command downloads a script and runs it with bash:

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

fx runs on macOS and Linux, on x86_64 and arm64. The installer puts the binary in ~/.local/bin, so that directory must be on your PATH. fx checks for updates in the background, and fx upgrade installs the latest release right away. The changelog lists what changed in each release.

Windows is not on the list, and a piped script runs whatever the server returns at that moment, so read it first if you manage shared machines. If you only want to look, the project also offers a way to try fx in your browser without installing anything.

Four sign-in routes, and any OpenAI-compatible endpoint

You must connect a model before fx does anything. The quick start lists these sign-in commands:

fx login                    # Vercel AI Gateway
fx login codex              # ChatGPT subscription
fx login grok               # Grok subscription
fx login vercel --api-key   # AI Gateway API key

Alternatively you can connect any OpenAI-compatible Chat Completions endpoint, with Ollama and OpenRouter given as examples, through the custom model connections settings. That is the route for a local model. Then you change to your project directory, run fx, type what you want and press Enter. The slash command help lists the commands, and fx doctor checks your setup when something does not work.

Two practical points follow. The ChatGPT and Grok routes use subscriptions you already pay for, while the AI Gateway routes bill through Vercel, so check which account is charged before you leave a long task running. And because the model is a setting rather than part of the binary, you can compare providers on the same project without changing anything else.

Auto permission mode lets a model judge actions it did not pre-approve

The default permission mode is auto. Routine work, such as editing project files and running tests, runs without asking. Anything else goes first to a model that checks the exact action for prompt injection or malicious behaviour, and fx holds the action if the check finds a problem. You can switch to the ask mode to approve each action yourself.

The design deserves some caution. A model-based check is a judgement, not a rule: it can miss an attack or block a harmless step, and an agent in auto mode edits files and runs commands in your project without asking. For repositories with credentials, build scripts you do not trust, or content from the web, use ask mode or a throwaway clone. Commands receive AI_AGENT=fx in their environment so your own tools can detect when an agent is running them.

Output prints inline and commands run in your own login shell

Unlike an IDE or a full-screen interface, fx prints the conversation into the terminal as inline output. You scroll, search and copy it like any other command's output, and tmux bindings and copy mode keep working. Terminals that support the Program Status Protocol can also show when fx is busy or waiting for you.

Shell commands run in your login shell, with your aliases, functions and PATH. fx runs your startup files once and reuses the result until one of them changes, so a slow .zshrc does not slow down every command. The caching is a trade-off: a startup file that changes the environment in ways fx does not detect could give stale results until a file changes. Saved sessions live under ~/.fx/sessions, fx -c continues in a project, and compaction keeps the full older text on disk for lookup.

Scripts, editors and JavaScript apps embed the same agent

For a single request from a script or CI job, use fx ask, adding the JSON flag when a program must read the result:

fx ask "explain the changes in this repository"
fx ask --json "summarize the failing tests" | jq -r .final_output

Editors and other clients connect with fx acp, which speaks the Agent Client Protocol over stdio. JavaScript applications use libfx, the agent core built as a native Node.js addon and as WebAssembly. Its createFxAgent function runs an agent with your own tools, MCP clients and skills, and createFxTerminal embeds the fx terminal. The WebAssembly build is experimental. The examples directory has small apps: a terminal chat, a browser agent, a Next.js agent and a Nuxt agent, each run with an AI Gateway API key.

Skills, MCP servers and AGENTS.md extend what fx knows

fx loads skills from .fx/skills and ~/.fx/skills, and from folders other agents use, such as .claude/skills and .agents/skills. The model sees each skill's name and description and reads the full instructions only when needed, so installed skills take little room in the context. MCP servers are set up with /mcp add slack or managed from the terminal with fx mcp, and tool schemas load when the model looks for them.

Project instructions come from the AGENTS.md in your project, nested AGENTS.md files for the directories they cover, and ~/.fx/AGENTS.md for your personal rules across projects. The license is Apache-2.0, third-party notices are in the repository, and the last push was on 2026-11-02. For coding agents, the project publishes its manual as Markdown, with an llms.txt index and a combined llms-full.txt, so an agent can learn fx by reading it directly.

Editorial conclusion

fx suits developers who want a coding agent that is a single native binary, prints into the terminal like any command, and can be scripted with fx ask or embedded through libfx. It is a poor fit for production workflows that need a stable interface, since the project says plainly that it is experimental and at your own risk, and Windows is not among the supported platforms. Run it in a disposable checkout first and decide whether to keep the default auto permission mode.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes