Puter Compiled Firefox to WebAssembly — Built on a $25K Claude Tab, Paid Flat

A browser, inside a browser, inside a browser

The demo is disorienting in the right way: it's the actual Gecko engine — Firefox's rendering core, not a Firefox-styled iframe — compiled to WebAssembly and running the real Firefox interface inside a tab. Puter chose Gecko over Chromium specifically because it has strong single-process support, which matters enormously when your entire multi-process browser architecture has to collapse into one WebAssembly sandbox with no OS-level process isolation to lean on.

The harder problem wasn't rendering, it was networking. Code running inside a browser tab can't open arbitrary TCP or UDP sockets — that's a sandboxing rule, not a bug. So every request the WASM-Firefox instance makes gets funneled over a single WebSocket into a Wisp protocol tunnel that terminates on Puter's own servers, which then make the real connections on the browser's behalf. Wisp exists precisely for this: it's a lightweight protocol for multiplexing many logical TCP/UDP streams over one WebSocket, originally built for browser-based proxy tooling. It's the same trick that makes in-browser VPN-style tools and remote-desktop-in-a-tab projects work — you're not defeating the sandbox, you're routing around what it doesn't let you do directly.

The real number here is the cost split

The detail worth sitting with, for anyone building with AI-assisted tooling, isn't the Wasm trick — Emscripten-compiled engines running in-browser aren't new. It's that Puter estimates the project consumed about $25,000 worth of Claude Opus and Fable tokens, but the actual dollars spent were far lower because the work ran under a Claude Max subscription rather than metered API billing.

That gap is the whole story of what a flat-rate agentic coding plan changes about how you scope work. Metered API pricing makes you ration exploratory runs — every failed compile attempt, every "let's just try recompiling with a different flag" has a marginal dollar cost, so you plan carefully before you burn tokens. A flat monthly ceiling inverts that: the constraint becomes wall-clock time and your own judgment about when to stop, not a running invoice. A systems-level port like cross-compiling an entire browser engine — the kind of project that would normally be scoped in engineer-months — becomes something a small team can attempt speculatively, because the token bill and the credit-card bill stop being the same number.

Why this matters beyond the novelty

Most vibecoding examples are web apps, dashboards, or scripts — legible, bounded, forgiving of a wrong turn. Recompiling Gecko to WebAssembly and re-plumbing its networking layer through a custom multiplexed proxy is not that; it's the kind of low-level, high-blast-radius systems work where a subtly wrong assumption compounds for hours before it surfaces. That it got built at all, agent-driven, is a useful data point on how far current agentic coding stacks now reach — not proof they're ready for every systems project unsupervised, but evidence the ceiling has moved. For teams evaluating whether to put real infrastructure work in front of an agent versus reserving that for senior engineers, cases like this are the sample size worth tracking.