no. 12 · the browser-native stack

A model, its runtime, an agent, an IDE and your filesystem — all inside one browser tab.

There is no server. There is no account. There is no API key. You open a URL and, a couple of gigabytes later, a 4B model is running on your GPU, an agent harness is calling tools with it, a real VS Code editor is open next to it, and it is reading and writing files in a folder on your own disk. Nothing you type leaves the machine. This is what that stack is made of, how it got assembled, and the embarrassingly simple reason a little site with an elf on it gets opened a bit more every day.

6 aug 2026~9 minWebGPU · agents · local-first

The claim, stated plainly

Two web apps — Elffuss Code (an IDE with an agent) and Elffuss Claw (a chat where apps get generated on demand) — ship the whole vertical: weights, inference runtime, agent loop, tool layer, editor, and OS integration. No framework, no build step, vanilla ES modules. The backend is nginx serving static files. That's it.

The modelGemma-4 E4B (~4 GB) or E2B (~2 GB), the official litert-community web builds. Where WebGPU isn't available, our own healed LFM2.5-1.2B in ONNX q4. Nothing is downloaded until you ask for it.

The runtimeGoogle's LiteRT-LM on WebGPU for Gemma; transformers.js (ONNX Runtime Web, WebGPU with a wasm fallback) for the small one. Weights are cached in Cache Storage, under a navigator.storage.persist() grant so the browser doesn't evict them.

The harnessA 6-step agent loop: model → fenced tool block → run it → feed the result back. Plus ACE-lite context management (BM25-lite + IDF eviction over the message history), permissions per scope, persistent memory and skills.

The editorReal Monaco — the actual VS Code editor core — with a file tree, tabs and Ctrl+S. Git branch and last commit are parsed straight out of .git, no library.

Your machineFile System Access API: you grant one folder, and that folder is the only world the agent touches. Real .xlsx reading, folder-to-folder automations, an AES-256-GCM vault, and an optional local bridge for real node/npm/python.

Every layer in that table is a decision that could have gone the easy way — a hosted API, a Python backend, an Electron shell — and didn't. The rest of this series is one post per layer. This one is about the shape of the whole thing, and why it holds together.

How we got here (it wasn't a plan)

This did not start as "let's put an IDE in the browser." It started as a much smaller question, and every answer moved one more piece off the server:

Can a small model do a real tool call in a tab? That was the first experiment — a 0.5B model, ONNX, WebGPU, and a fenced JSON block as the protocol. It worked badly, but it worked. The protocol never changed after that day.
Then: can it touch a real file? The File System Access API turned out to be the hinge of the entire project. The moment the model could read a real calc.py from your disk instead of a pasted snippet, "toy" became "tool."
Then: is a 0.5B enough? No. Not for multi-file reasoning. Google's LiteRT-LM web builds of Gemma-4 landed and suddenly a 4B-class model ran on the same tab — same protocol, same tools, dramatically better decisions.
Then: does it need an editor at all? Two answers, so we built both. Code says yes: developers want Monaco, a tree, and tabs. Claw says no: the chat is the interface, and if you need an app, the model writes it as self-contained HTML and it renders on the spot.

The through-line is that nothing was added because it was fashionable. Each piece exists because the previous experiment hit a wall, and the wall had a name.

The simple reason a website with an elf on it keeps getting opened

Both apps have a cartoon elf as their face, they were announced once, and they have not been advertised since. They still get opened every single day. The reason isn't the elf, and it isn't the marketing — there isn't any. It's arithmetic:

friction

0installs, accounts, API keys, credit cards or CLI commands between a stranger and a working AI agent. It's a URL.

marginal cost

~0 €per user, per session, forever. The inference runs on their GPU. I serve static files; they bring the compute.

privacy question

moot"Where does my code go?" — nowhere. There is no upload endpoint to worry about, because there is no endpoint.

That third one is the quiet winner. Every hosted AI tool has to answer the data question — with a policy page, a compliance badge, an enterprise tier. A local-first tool dissolves the question: there's no server that could keep your code even if it wanted to. And because the marginal cost of a user is genuinely zero, the tool can stay free without a countdown timer running under it.

The whole economic model of "AI product" flips. Nobody's tokens are being burned while you play with it. If a hundred people show up tomorrow, my bill doesn't move. That's why a hobby project with an elf on it can be used every day, indefinitely, by people I will never meet — and why it can afford to be Apache-2.0.

What it actually looks like when it runs

Here's the boot sequence of Elffuss Code the first time you open a folder, taken from the real console logs:

The interesting part is what isn't in that log: no login, no telemetry handshake, no round trip to anything except a CDN for the weights — once. Reload the page and the model comes back from Cache Storage in a second or two.

Everything that is hard about this

This series is going to be about the details, and the details are where the honesty lives:

A 4B model is a 4B model. It locates things well (grep-then-read) and reasons across many files badly. Half the engineering is tool design that keeps its job small enough to succeed at.
The first visit costs gigabytes. There is no way around it: you're shipping the brain to the user. What you can do is make it happen once, and never again — which is a Cache Storage and quota-eviction problem, and it bites.
WebGPU is not evenly distributed. navigator.gpu can exist with no usable adapter behind it. Detecting that before you download 4 GB is a real bug we shipped and had to fix.
Chrome and Edge only. File System Access plus WebGPU is the price of admission. Safari and Firefox users get a degraded mode, and pretending otherwise would be dishonest.

The series

This post — the whole stack and how it got assembled.
Two runtimes, four gigabytes, one tab — WebGPU, LiteRT-LM, ONNX, and the caching war stories (including the service worker we deliberately made inert).
The entire agent is a fenced code block — the tool protocol, the 6-step loop, and ACE-lite context eviction in a place with no attention scores.
Your folder never leaves your machine — File System Access, five tools, git parsed by hand, an encrypted vault, and a local bridge for real execution.

Both apps are Apache-2.0: elffuss-code, elffuss-claw, shared core. Every number and code path quoted in this series comes from the shipped source, not from a slide.

Update (Aug 2026): This description was accurate and the engine still lost to almost everything. It has been rewritten: real BM25, endogenous IDF, no hand-written rules, and knobs derived from measured compression pressure. → no. 16.