Vercel Labs has released fx, a tiny open-source coding agent, and the headline number is the binary itself: 7.8 MiB, written in Zig, designed to feel closer to a Unix shell than to an “IDE in the terminal.” The project is Apache-2.0 licensed, model-agnostic, and built for both local and cloud inference. The agent signs in through Vercel’s AI Gateway, or directly through OpenAI Codex OAuth with an eligible ChatGPT subscription, or through xAI OAuth with a Grok subscription.
What is genuinely new here is not another coding assistant. It is the architectural bet buried in the README: fx is a harness, not a product. It compiles to a native binary or WebAssembly, exposes an Agent Client Protocol interface via fx acp, and ships an experimental WebAssembly SDK with createFxAgent() and createFxTerminal() so JavaScript hosts can embed the agent core directly. Vercel is not trying to win the chat-window war. It is trying to make the agent runtime a commodity layer that other software embeds, the way SQLite became the embedded database.
The timing matters. The coding-agent market has split into two camps: heavyweight IDEs-in-the-terminal like OpenAI’s Codex CLI and Anthropic’s Claude Code, and lightweight, composable tools that treat agentic work as a pipeline stage. fx sits firmly in the second camp, and its design choices read as a deliberate critique of the first. The CLI output style aims for Unix-shell minimalism. The permission system defaults to auto mode, which runs routine actions directly and sends only unresolved sensitive actions to a bounded automatic review. There is a yolo mode that disables permission checks entirely, which is either a power-user feature or a footgun depending on who is holding the keyboard.
The most consequential detail is the OAuth architecture. When a user signs in through Codex or Grok, fx talks to OpenAI or xAI directly. The README is explicit that the OAuth token never touches Vercel’s AI Gateway. Sessions are stored privately in ~/.fx/chatgpt-auth.json or ~/.fx/grok-auth.json. This is a meaningful statement about where the value sits in the agent stack: Vercel is willing to be the harness, the permission layer, the session store, and the embeddable runtime, but it is not trying to interpose itself as the model proxy for subscription users. The AI Gateway remains an option for API-key users, but the default path for ChatGPT and Grok subscribers is direct provider access.
That choice has a strategic logic. Vercel’s business is deployment infrastructure, not model inference. By making fx open source and provider-neutral, Vercel positions itself as the neutral substrate on which AI-assisted development runs, then monetizes the surrounding platform: AI Gateway, hosting, and the developer workflows that funnel into its deployment products. It is the same playbook Vercel ran with Next.js, which became the default React framework and drove adoption of Vercel’s hosting. fx is an attempt to do for agent runtimes what Next.js did for React.
The embeddability story is the part most competitors will struggle to copy. A 7.8 MiB binary that compiles to WebAssembly and exposes a JavaScript SDK means any application can ship agentic capabilities without standing up a heavyweight service. The WebAssembly SDK is marked experimental, but the direction is clear: agent functionality becomes a library, not a platform. That is a genuinely different distribution model from Claude Code’s terminal-first approach or Codex’s IDE integration.
There are real tradeoffs. The project is explicitly experimental, with a status warning that says “Use at your own risk.” The native OS sandbox for command isolation is currently available only on macOS. The permission model, while thoughtful, adds a layer of cognitive overhead that a plain bash session does not have. And the model-agnostic stance means fx inherits the reliability of whatever model sits behind it, which is a feature for flexibility but a risk for consistency.
What fx signals for the broader AI economy is a shift in where infrastructure money gets spent. The past two years saw a land grab in agent products: chat interfaces, IDE plugins, and CLI tools each trying to own the developer relationship. fx points toward a different endgame where the agent is a component, and the winners are the ones who own the harness, the permission layer, and the deployment path. Vercel’s move is a bet that developers will embed agents the way they embed databases, and that the platform beneath those embeddings is where the durable business lives.
For AI builders, the practical takeaway is about leverage. The skills system reads from .claude/skills/, .codex/skills/, and .opencode/skills/ directories, which means a skill written for one agent ecosystem can be reused in fx without modification. MCP server support is built in, and subagents can be spawned with independent models, reasoning effort, and permission modes. The tooling is converging on open standards, and fx is an aggressive consolidator of those standards in a single small binary.
The open question is whether Vercel can convert harness adoption into platform revenue. The AI Gateway pricing follows the selected model and provider, and fx usage tracks local spend, but the subscription OAuth paths bypass Vercel’s metering entirely. If most users sign in through ChatGPT or Grok subscriptions, Vercel becomes a free distribution channel for OpenAI and xAI, with the platform monetization deferred to whatever comes after the agent finishes its work.
The README’s ASCII art and the curl -fsSL https://fx.sh/setup.sh | bash installer give fx the feel of a weekend project, but the engineering is serious. Zig 0.16.0 or newer builds the binary from source, the test suite runs via zig build test, and the session system supports recovery checkpoints, context compaction after eight turns, and migration of older session formats. This is infrastructure with a maintenance budget, not a demo.
Vercel’s real competition is not OpenAI or Anthropic. It is the default assumption that agentic coding happens inside a heavyweight tool. fx is a bet that the future is smaller, faster, and embedded, and that the agent becomes another Unix utility in the developer’s toolkit. Whether that bet pays off depends on whether developers agree that the agent should be a pipe, not a window.