← Back to all posts
Tools

A 6MB Coding Agent Boots in 10 Microseconds. Local Models Not Included.

August 21, 2026 · 04:09 UTC · Tools
A 6MB Coding Agent Boots in 10 Microseconds. Local Models Not Included.

TL;DR

Vercel Labs open-sourced fx, a coding agent that is emphatically not an npm package. It is one native binary written in Zig, 6.39 MiB on the tin, Apache-2.0, that Vercel says cold starts in 10 microseconds and holds a single-digit-megabyte memory baseline. It also compiles to WebAssembly, so the entire agent loop runs in a browser tab. The catch: it is at v0.0.4, it ships 26 built-in tools under a banner that says "minimal," and every documented route to a model goes through Vercel's AI Gateway. Fast, small, open. Not yet fully yours.


What actually shipped

The repo went public this week and hit the Hacker News front page at 310 points. It was created on August 11, tagged v0.0.1 on August 17, and was on v0.0.4 by August 19. As of today it sits at roughly 1,700 stars, 164 forks, and 54 open issues. The README's own status line is "experimental, use at your own risk," which is at least honest.

empty repo to front page in ten days repo created v0.0.2 + v0.0.3 1,697 stars v0.0.1 v0.0.4 aug 11 aug 17 aug 18 aug 19 aug 21
Four releases in three days. Star count read from the GitHub API on August 21.

Install is the usual curl | bash ritual against fx.sh, macOS and Linux, x86_64 and arm64. Building from source needs Zig 0.16 or newer. There is no runtime to install, which is the entire point: no Node, no Python, no virtualenv, no version manager, nothing that resolves a dependency graph at startup.

The 10 microseconds are real and also beside the point

Vercel's claim is specific: fx does no unnecessary work or I/O before it accepts your first keystroke. That is a genuine engineering result for a category where the competition boots a JavaScript runtime first and thinks about it later.

It is also a sprinter who still has to wait for the bus. Ten microseconds to the prompt, then several seconds staring at a token stream from someone else's datacenter. Where the small binary actually pays off is not your laptop, it is the thousandth agent sandbox your CI spins up, where 6 MiB and a few megabytes of RSS multiply into real money.

"Minimal" ships with 26 tools

Read the tools reference and the minimalism gets harder to locate. fx exposes 26 built-in tools to the model, eleven of them file operations, including separate copy_file, rename_file, and create_folder entries in a product whose selling point is that it feels like a Unix shell.

built-in tools by category (26 total) files11 mcp3 runtime3 search / nav2 skills2 web2 commands1 subagents1 vision1
Counted from the published tools reference. File operations are 42% of the surface.

This is the loudest complaint in the HN thread, and it is a legitimate design argument rather than a bug: a frontier model handed run_command can already move, copy, and rename files. Every extra tool spec is context you pay for on every turn. Vercel's bet is that explicit tools produce more reliable behavior than shelling out. Reasonable people disagree, and the disagreement is now testable in 6 MiB.

The other extension points are the ones you expect in 2026: MCP servers, reusable skills, and subagents that get their own session.

Where your tokens actually go

The README says model-agnostic, suitable for local and cloud inference. The authentication docs say something narrower. Credentials resolve in this order: VERCEL_OIDC_TOKEN, then AI_GATEWAY_API_KEY, then a saved fx login session, then a key stored by fx setup. Model selection pulls from the Vercel AI Gateway catalog. The full configuration reference lists no base URL, no endpoint override, and no local provider key.

fx binarylocal, 6.39 MiB Vercel AI Gatewayauth, routing, billing model catalogdefault: zai/glm-5.2-fast no documented endpoint override or local provider
The binary is local. The inference path, as documented today, is not.

Multiple HN commenters reported hunting for a generic OpenAI-compatible endpoint and coming up empty. The architecture is not the problem: src/gateway/ is a clean transport seam, and the license means anyone can add a base URL flag. But the shipped, documented product is a local binary that has to ask a hosted gateway for permission to think.

One detail nobody at Vercel seems embarrassed by, and nor should they be: the compiled default model is zai/glm-5.2-fast, from Z.ai. An American cloud's flagship agent demo ships pointed at a Chinese lab's model, because on price and speed that is currently the sane pick.

Auto mode hires a second model to babysit the first

The permissions design is the most interesting thing in the docs and the part most likely to surprise you on the bill. Three modes: ask prompts you, yolo disables checks and sandboxing entirely, and auto is the default.

In auto mode, a tool call that your saved rules do not resolve gets sent to a separate reviewer model, openai/gpt-5.4, which decides whether it proceeds. Think of it as a bouncer who reads every request at the door, never gets tired, and charges per ID check. That is a second API request on top of your agent's own token spend, plus bounded retries when the reviewer call fails. Sandboxing is a distinct layer underneath, and on macOS it uses native OS sandboxing to keep writes inside your workspace and temp directories.

If you run fx headless in CI on auto, budget for two model bills, not one.

The WebAssembly part is the actual news

Everything above is a good CLI. The WebAssembly SDK is the thing other agent harnesses cannot casually copy. Zig compiles fx to a wasm target with a pluggable network stack, networking is delegated to browser fetch, and two APIs, createFxAgent() and createFxTerminal(), hand a JavaScript host either a headless agent or a full terminal. The demo at fx.sh runs the real CLI in the page.

For anyone building an agent into a product rather than using one, that is a different distribution story than shipping a Node process and hoping the customer's sandbox cooperates. There is also fx acp, an Agent Client Protocol server, so editors that speak ACP can drive it without a bespoke integration.

Should you install it

If you want a small, hackable agent core to embed, read, or fork, yes. It is Apache-2.0, the source layout is unusually legible, and 6 MiB of Zig is a codebase a single person can actually hold in their head. Note the binary size claim varies by where you read it: the homepage says 6.39 MiB, the README says 7.8 MiB, which is the kind of drift you get from a project on its fourth release in three days.

If you were hoping to point it at Ollama or vLLM this afternoon, wait, or write the patch. And if you were hoping for a stable daily driver, note that v0.0.4 with 54 open issues is a research artifact wearing a CLI, exactly as advertised.

Key Takeaways

  • One binary, no runtime. fx is 6.39 MiB of Zig, Apache-2.0, macOS and Linux on x86_64 and arm64, with a claimed 10 microsecond cold start and single-digit-megabyte memory baseline.
  • Minimal is a claim, not a count. 26 built-in tools ship by default, eleven of them file operations, which is the loudest criticism of the release and a real design argument about tool-spec context cost.
  • Local binary, hosted brain. Auth and model selection run through Vercel AI Gateway. No base URL override or local endpoint appears anywhere in the configuration reference.
  • Auto mode costs extra. Unresolved tool calls are reviewed by a second model, openai/gpt-5.4, as a separate billable request per call.
  • WebAssembly is the differentiator. The whole agent compiles to wasm with browser fetch as its network stack, and fx acp exposes it to any Agent Client Protocol editor.
  • It is v0.0.4. Four releases in three days, 54 open issues, and a README that says experimental. Treat it accordingly.

Sources: vercel-labs/fx on GitHub, fx.sh, fx tools reference, fx authentication docs, fx models docs, fx permissions docs, fx WebAssembly SDK docs, Hacker News discussion

AICoding AgentsVercelZigOpen SourceDeveloper ToolsWebAssembly
CONSOLE
$