fx v0.0.8 Benchmark: 0.6ms Startup and a Stale Size Claim

Three weeks ago I covered fx v0.0.4, Vercel Labs' coding agent written in Zig. Back then I took two claims on faith: a 7.8 MiB binary and "minimalism across the board." fx v0.0.8 shipped September 7, so I pulled the release binary and checked the receipts. Scoreboard: 0.6ms median startup — the fastest CLI I've measured — but the binary is 11.0 MiB, not 7.8, and the "tiny" codebase is 658,056 lines of Zig across 579 files.

The setup: release binary, not a source build

I downloaded the official fx-linux-x86_64.tar.gz from the v0.0.8 GitHub release and verified the sha256 (5a2a5e18…d124 — matched). The archive contains one stripped binary plus licenses:

$ curl -sL -o fx.tar.gz https://github.com/vercel-labs/fx/releases/download/v0.0.8/fx-linux-x86_64.tar.gz
$ sha256sum fx.tar.gz   # matches published .sha256
$ tar xzf fx.tar.gz && ls -l fx
11557360  fx   # 11,557,360 bytes = 11.02 MiB

v0.0.8 landed two days ago, and v0.0.4 → v0.0.8 in three weeks is a brisk cadence for a project still labeled experimental.

Startup: 0.6ms median, 13x faster than Node

I ran fx --version 20 times and took the median, then the same harness on node --version and git --version on the same box:

A three-order-of-magnitude difference vs. a Node-based agent CLI isn't cosmetic — it's the difference between shelling out to the agent for one small task and not bothering. This is the Unix-pipe thesis from my v0.0.4 post actually cashing out. Caveat: --version exits before session state loads; the doctor command (which touches config, auth, git, gh) still completed near-instantly at this scale.

The size claim doesn't survive contact with a download

The README — current as of this cycle — says fx "focuses on minimalism and performance across the board, from system prompt design to its tools, feature set, and 7.8 MiB binary." I measure 11.0 MiB uncompressed on Linux x86_64 and 4.8 MiB gzip-compressed. Neither is 7.8. Their own CHANGELOG (v0.0.7 notes) says the macOS arm64 binary is 6.12 MiB — so the README number matches no platform I can find.

It's a nit, but it's a pattern worth flagging in the agent-harness space: every harness markets a size number, and the number is always the best case. Meanwhile the "tiny" source tree is 658,056 lines across 579 Zig files. Tiny compared to Next.js, sure. Tiny compared to a Unix tool, no.

The most honest number: a 5,450-byte system prompt

The genuinely minimal part is real. fx's default gateway system prompt is @embedFile("system_prompt.md") in src/builtins/context.zig — 5,450 bytes, 871 words, embedded at compile time. For comparison, that's roughly a fifth of what most agent harnesses ship. The prompt is dense and opinionated: inspect-first ("do not rely on memory or general knowledge"), one-brief-update-before-the-first-tool-call, and explicit rules against retrying failed actions without new evidence. It reads like it was written by someone who has watched agents fail, not by a marketing team.

Default model out of the box is moonshotai/kimi-k3 via Vercel AI Gateway — a notable endorsement buried in a default config value. Providers remain Gateway, Codex OAuth, or Grok OAuth; there's still no bring-your-own OpenAI-compatible endpoint flag, so the Vercel-garden lock-in I flagged three weeks ago stands. Without credentials, fx ask exits immediately with a clear error — good failure mode, but still a walled one.

Bottom line

fx is quietly becoming the fastest-loading agent harness available — 0.6ms to enter the process is not a marketing number, it's architectural. The 7.8 MiB claim is stale or platform-dependent and should be fixed before someone with a bigger megaphone checks it. The real moat question hasn't changed since v0.0.4: the binary is open, but the default path routes through Vercel AI Gateway, and that's where the value accrues. Measure the startup, keep the system prompt, stay aware of the tollbooth.