fx is Vercel Labs' tiny, open, native coding-agent CLI. It is written in Zig, ships as a ~6.4 MiB binary, and aims at Unix-shell ergonomics rather than a full TUI IDE.

How do I authenticate on a remote box?

`fx login` uses Vercel OAuth device-code — it prints a URL and a short code. That works in a remote PTY. You can also run `fx setup` and paste an AI Gateway API key, or export AI_GATEWAY_API_KEY.

No. The official installer drops a static binary into ~/.local/bin. There is no npm tree and no nvm bootstrap.

From $25/mo, BYOK (your Vercel login or AI Gateway key), 30-day money-back on your first purchase. No free trial and no free tier.

fx on a MicroVM: The 6MB Unix-like Coding Agent

Most coding agents want to be an IDE in your terminal. fx wants to be a shell.

That is the whole product. A 6.4 MiB Zig binary. Cold start measured in microseconds. Output that scrolls like a Unix tool instead of a full-screen TUI. Apache-2.0, model-agnostic, installable with one curl.

Run fx on a jurniti microVM

The laptop problem, again

A tiny binary is easy to install locally. That is not the same as easy to leave running.

You close the lid and the turn dies with it.
Device-code login works, but you still do not want the agent editing files on the machine that holds your password manager.
You want the same ~/.fx — settings, skills, sessions — reachable tomorrow from a phone.

fx is small enough to feel disposable. The work it does is not.

What we actually run

jurniti gives fx its own computer — a Firecracker microVM, the same isolation primitive AWS uses for Lambda. Not a container. Not a shared box with someone else's agent in the next namespace.

On provision you get:

A fresh Ubuntu microVM with fx already on PATH. The binary is pre-baked, so first boot is not a CDN fetch.
A live in-browser terminal. Run fx login (Vercel device-code — PTY-safe) or fx setup to paste an AI Gateway key.
A persistent home. ~/.fx/settings.json, ~/.fx/skills/, and your project's AGENTS.md survive stop/start.
Pinned CPU and RAM. Your reservation.

BYOK throughout. fx talks to Vercel AI Gateway with your login or your key. We never proxy model spend.

Why the form factor matters

fx's own pitch is "closer to a Unix shell than a heavy IDE in the terminal." That is not marketing fluff. A 6MB agent with a 10µs cold start is the shape you want when you fx ask from a script, or when you pack many instances onto one machine.

The managed version of that is not "more UI." It is the same small binary, left on, isolated, with a disk that outlives the process.

fx acp is there too — Agent Client Protocol over stdio — so an editor host can drive the same box you already use from the shell.

Snapshot it, fork it, share it

Once the box is yours — model, permissions, skills, MCP servers in ~/.fx/mcp.json — snapshot it into a template. A template forks into a fresh paid VM in about three minutes.

Credentials do not travel. Public capture drops ~/.fx/auth.json (the Vercel OAuth session) and ~/.fx/api-key (the Linux file store). Session transcripts and usage records go with them. What survives is the reusable layer: settings, skills, project AGENTS.md.

Honest limits

Experimental upstream. fx.sh itself says experimental. The binary we bake is a real X.Y.Z (0.0.3 on first ship) and we watch GitHub releases, but expect frequent changes.
Terminal-first. There is no web dashboard to proxy. You work in the in-browser terminal.
No free tier. From $25/mo. The de-risk is a 30-day money-back guarantee on your first purchase, not a trial that expires while you are still evaluating.

Get the box

Pick a plan, choose fx, pay. The VM is up in a few minutes with fx on your PATH. Then:

fx login
fx