Why AI tooling should run in your browser

Running the work in the browser is almost always justified by privacy. That argument is correct, but it is also the weakest one available — it frames local-first as a stance rather than an engineering trade-off. What actually makes the case is that local-first deletes an entire class of failure: network round trips, rate limits, outages, and the fact that your text exists in someone else's logs.

The assumptions an upload-based tool accepts

A tool that posts your text to a server has to satisfy a long list of conditions before it can do anything. It assumes the network is up, the service is running, the quota is not exhausted, a round trip is acceptable, and that the provider's retention policy does not conflict with your obligations to whoever owns that text.

Each assumption looks reasonable on its own. The problem is that they fail together, and they usually fail while you are in the middle of something. Worse, the failures do not look alike: a dropped connection is an explicit error, a rate limit is an unhelpful sentence, and the worst case succeeds while quietly keeping a second copy of your text.

Delete one assumption, delete one class of failure

Moving the computation into the browser removes nearly all of those assumptions at once.

• With no round trip, "request timed out" is not a state your code can be in, so it needs no retry logic.
• With no server, there is no quota, no queue and no 3 a.m. alert.
• With no upload, there is no retention policy to explain, because there is no copy to retain.

The point is not that privacy is better. The point is that the state space is smaller. A tool built from HTML, CSS and browser APIs has a failure set you can enumerate.

More work is client-side than people assume

The instinct that "real AI features need a server" comes from model inference, which genuinely does. But the whole ring of work around inference — sizing a prompt, assembling it, cleaning the response, pulling structure out of it — does not need a model at all.

What these share is that the input is text, the output is text or a few numbers, and nothing in between requires judgement. They need no GPU and no network. They need determinism. The toolkit on this site is built entirely out of that category.

What it costs

Local-first is not free, and the costs are concrete:

• You cannot get the provider's exact tokenizer, so you ship a heuristic — and you have to label it as an estimate rather than implying precision you do not have.
• With no server there is no cross-device sync, so sharing has to be solved as a product problem rather than a backend one.
• Whatever code the user has to download is genuinely downloaded, and bundle size is a debt you pay.

All of that is acceptable, provided it is stated in the product rather than hidden in it.

When to go the other way

Some jobs genuinely require the network: real model inference, third-party APIs, state shared across users. Insisting on local execution there just pushes complexity into the client.

The test is simple: does this step require judgement? Judgement goes to the model; everything else stays in the browser. Most daily chores are in the second category — and they are exactly the chores that tend to be built as upload-first tools.

Local-first is not the more conservative choice; it is the choice with fewer assumptions. No network, no account, no server quota, no maintenance window. Every assumption you delete is a class of failure you delete with it.