Agent alpha: a coding agent that runs in your browser

For a year this site did one thing: load a model in a tab and talk to it. It worked, people came back, but a chat remains a chat. You ask, it answers, and everything that happens next is your job.

Today we open the alpha of something else. An agent, in the sense that Claude Code or Codex give to this word: a model which has tools, which decides alone which one to call, which reads the result and continues until the task is finished. The difference with the others is that this one runs entirely in your browser. No server, no API key, no upload of your files. Your code does not leave the machine, because there is nowhere for it to go.

It is in alpha. We will say below exactly where it breaks.

What it does

You give it a task in natural language. It looks at your files, finds what it needs, and modifies what must be modified. A session looks like this:

> find where the retry delay is hard-coded and make it configurable

Grep(setTimeout)            3 matches in 2 files
Read(src/client.js)         84 lines
Edit(src/client.js)         approve? [y/n]

The last line is the important one. Everything which reads passes without asking you. Everything which writes stops and waits.

The workspace is real

This is the point on which we spent the most time, and the one which changes everything in use.

The agent works on a real tree of files, stored in the Origin Private File System. OPFS is the only browser storage which gives directories, writes in streaming, and which survives a reload without a quota dialog. Concretely: you close the tab, you come back tomorrow, your files are there.

You can:

• import a folder from your disk, with the native picker;
• import loose files by drag and drop;
• export everything as a .zip when you have finished.

On import we skip node_modules, .git, dist, build, .next and target, and we ignore files above 2MB. The agent reads and writes text; a binary asset of 40MB would eat the storage quota of the origin for nothing.

Paths are normalised before touching OPFS, and everything which looks like ../ or an absolute path is refused. The model has no reason to go out of the workspace, but one does not count on a model to respect a rule that the code can enforce.

The seven tools

Tool	What it does	Approval
list_files	lists the workspace	no
glob	finds files by name	no
grep	finds files by content	no
read_file	reads a file	no
write_file	creates or replaces a file	yes
edit_file	replaces a passage in a file	yes
run_js	executes JavaScript	yes

The separation is not decorative. The four read tools are free because a useless read costs nothing and because an agent which must ask permission to look at a file is an agent one stops using after five minutes. The three others stop the loop and display a preview of what is going to happen — the content which will be written, the code which will be executed — with a button to accept or refuse.

If you accept a tool for the session, the choice is remembered. If you refuse, the agent receives the refusal as a tool result and continues; it is not an error, it is an answer.

On run_js

Let us be precise, because this is the kind of thing about which one lies by omission.

run_js executes the code in a Web Worker, without DOM, with a wall-clock budget of 5 seconds. The worker is isolated from the page, but it remains same-origin. This is a timeout and an isolation boundary, it is not a security sandbox. A sufficiently motivated code could touch the storage of the origin.

This is exactly why run_js always asks approval, even when you have accepted the others, and why we show you the code before executing it. Read it. It is two seconds and it is the only real protection.

The loop

At each turn, the agent has the right to a maximum of 8 tool calls before having to answer you. It is a hard ceiling, not a suggestion: a small model which enters a loop — read the same file, grep the same term, read again — would otherwise never stop, and you would watch a progress bar forever.

When the ceiling is reached, the loop stops and the agent summarises what it has done. Often it is enough. Sometimes you must relaunch with a more precise instruction, which is anyway what one would do with a human colleague.

The context meter

At the top of the transcript there is a counter which displays the number of tokens in the prompt, and among them how many have been read again from the KV cache instead of being recomputed.

Look at it. It is the best indicator of what is going to happen:

• a large cached number — your turn will be fast, the model only prefills what you have just added;
• cached at zero — something has invalidated the prefix and everything is recomputed, you will wait;
• the counter passes 80% of the context window — it turns red, and it is time to /clear. Beyond, the model starts to forget the beginning of the session without telling you.

The commands

Four, and no more:

• /help — the list;
• /files — what is in the workspace;
• /clear — empties the transcript and the context of the model, keeps the files;
• /reset — deletes the workspace and puts back the starter files.

The transcript and the history are saved in localStorage, capped at 200 entries. A reload does not lose your session.

Which model

All the catalogue is available, but be reasonable. Qwen3.5 2B is the smallest on which the loop works reliably; below, the tool call format degrades after a few turns and you spend your time relaunching. Qwen3.5 4B is clearly better on tasks which touch several files. Gemma 4 E4B gives the best results if your GPU supports 5.2GB.

LFM2.5 350M and Qwen3.5 0.8B are in the list, and they will answer you, but the agentic loop is not what they do best. Use them in chat.

Where it breaks

It is an alpha. Here is the honest list, before you discover it yourself:

1. The tool call format. The small models get the syntax wrong regularly. We detect a malformed call and we tell the model rather than displaying the broken markup as an answer, but that costs a turn.
2. Long files. A tool output is truncated at 6000 characters. On a file of 2000 lines, the agent sees the beginning and reasons on the beginning.
3. The first load. Between 1.6GB and 5.2GB of weights according to the model. Once, then cached, but the first time is long.
4. No shell, no network. run_js executes JavaScript in a worker. There is no npm install, no git, no HTTP call. It is a workspace, not a machine.
5. Nothing runs your project. The agent modifies files. To see whether it has broken something, you export and you test at home.

Why do it in the browser

One can legitimately ask the question. A coding agent on a server has more memory, a real shell, models ten times bigger. We are not going to pretend to compete on quality.

What we offer is different: your code is never uploaded anywhere. Not "encrypted in transit", not "deleted after 30 days", not "not used for training". Never uploaded. The model is downloaded to you, the files stay with you, the inference happens on your GPU. There is no request to audit because there is no request.

For a lot of code, that is not important. For some code, it is the only thing that is.

Try it

The Agent is open, without account. If you do not know whether your machine follows, the AI Readiness Test tells you in a few seconds which models will load.

It is an alpha, it has rough edges, and we prefer to publish it like that rather than in six months polished. Tell us what breaks.