What this cannot do.

It does not work everywhere

The automaton speaks only where Chrome’s Prompt API exists — Chrome or Edge on desktop, version 148 or later, with roughly 22GB of free disk and a suitable GPU. On Safari, Firefox, and most phones, that one tool reports itself unavailable and the other five keep working. This is a gate, not a graceful degradation, and it is deliberate: see below.

There is no fallback model

Running a model in any browser is possible today — Transformers.js with a WebGPU backend does it well. It is not here on purpose. The claim this site makes is that a model is already on your machine and you were not told. Downloading a different model to prove that point would refute it while adding several hundred megabytes to a page that currently weighs almost nothing.

The shading is not confidence

It is chunk arrival time. The browser exposes no token probabilities, so the more interesting picture is not available and is not drawn. Nothing on this page is a modelled, smoothed, or estimated number — every figure shown was measured in your browser during your session, or it is not shown.

WebMCP is a trial, not a feature

The origin trial runs from Chrome 149 to Chrome 156. The API shape has already changed once during the trial, which is why the registration code tries two shapes and reports which one took. Expect it to break. When it does, the status bar will say so instead of the page pretending.

Tool calls also require an open tab. Nothing here runs headlessly, and no agent can reach these tools without a browser sitting on this page.

The agent is a stand-in

The “tell an agent to do it” box is the local model playing the part, not a browser agent arriving through WebMCP — because during the origin trial almost no visitor has one. The choice it makes is real and unscripted, and it is handed the same manifest, but it is running inside the page rather than calling in from outside it. On a page about honest layers, that distinction is worth stating rather than blurring.

The weight comparison is a ratio, not a bandwidth claim

The agent’s view weighs the rendered HTML against the serialised tool list, both uncompressed, and reports the ratio. That is an honest like-for-like measure of how much of a page is about being looked at — but it is not a transfer-size figure. Over the wire both compress and the HTML compresses considerably better. Do not quote it as bandwidth saved.

The round trip measures the floor, not the real cost

The measurement on the anatomy page is seven requests for four bytes to this site’s own origin, over a connection that is already open. A real inference call adds a fresh connection to another host, authentication, a queue, and the model’s own thinking time. The figure shown is therefore an understatement of what a server costs — deliberately, because an understatement that still makes the point beats a flattering guess.

The model is small

An on-device model is a fraction of the size of one in a datacentre and behaves like it. It will be confidently wrong about facts, has no knowledge of recent events, and cannot hold a long conversation. Judge it on what it is: a model small enough to live on a laptop, answering with no network at all.

Nothing is stored

There is no backend, no database, no analytics, and no telemetry. The call log lives in memory and is gone when you close the tab. That is a limitation as much as a feature — nothing here syncs, persists, or can be shared with anyone, and there is no way for this site to know whether any of it worked for you.

It cannot stop you switching it off

Everything runs in your browser, which means you own it completely. Open the console and you can call any tool directly, feed the log whatever you like, or stop the mechanism. There is no integrity claim here and none is made.