The Browser Stops Being Just a Client

For most of the web’s history, the browser has been the place where computation ends up, not the place where intelligence begins.

It renders documents.

It executes JavaScript.

It stores local state.

It turns user actions into requests and server responses into interfaces.

When language models first entered web applications, they fitted that architecture neatly. The page gathered a prompt, sent it to an application server, the server called a model provider, and the answer travelled back through the same chain.

    flowchart LR
    U[User] --> B[Browser]
    B --> A[Application server]
    A --> M[Remote model]
    M --> B
  

That remains a sensible architecture. Remote models are often larger, easier to update, and available across a wider range of client devices. But it is no longer the only architecture.

Chrome’s built-in AI work introduces another possibility: a web page or extension can ask the browser for an AI capability, and the browser can arrange the model, runtime, download, execution and update lifecycle on the user’s device.

    flowchart LR
    U[User] --> B[Browser application]
    B --> API[Built-in AI API]
    API --> R[Browser AI runtime]
    R --> M[Local model]
  

The change is easy to underestimate because the application still makes an API call. Yet the architectural boundary has moved. The browser is no longer only the client of an intelligent service. It is also capable of becoming the model host.

This book follows that boundary all the way down.

We will learn the APIs, but API syntax is not the real subject. We will ask what the browser manages, what the application still owns, how model lifecycle becomes application state, what can be observed, what remains opaque, how a local model changes privacy and failure modes, and what happens when that model is allowed to use structured tools.

We will also build something real.

The running project now has two visible stages.

Stage One is the Browser AI Laboratory. Every chapter will acquire a full-page experiment that runs the mechanism being discussed, reports whether the visitor’s browser supports it, and exposes the resulting Observatory trace. When live execution is unavailable, the same page can replay a captured run without pretending that the replay happened in the visitor’s browser.

Stage Two is the AI-enabled site. The book and eventually the wider website become structured, locally searchable context. Pages expose bounded content units and typed operations. A user can ask about the current passage, compare chapters, run an experiment, apply a personal policy, or choose which AI runtime is permitted to process the request.

Browser AI Observatory remains the evidence instrument underneath both stages. Its DevTools extension monitors capability and session state, captures consented traces, displays download and inference timing, compares runs, and eventually inspects WebMCP tools and policy decisions.

The laboratory, the site experience and the extension are not appendices. Together they are the software the book develops.

1. Begin with the boundary, not the model

The phrase local AI collapses several different systems.

A JavaScript application might download model weights from a model repository and execute them through WebGPU. A browser extension might call a native application running a local model server. A web page might use a browser-provided Prompt API. All three perform inference near the user, but they assign responsibility differently.

The last row is the one we are studying first.

With an application-managed model, the model is part of the application. The developer chooses a model family and quantization, hosts or references its weights, loads a runtime, manages caching, detects available acceleration, and decides when to evict resources.

With a browser-managed model, the application requests a capability. The browser decides whether the capability is supported, whether a compatible model is present, whether another download is required, and how the underlying model is executed.

The difference can be expressed as a change in ownership:

application-managed

application
  ├── feature
  ├── model choice
  ├── weights
  ├── inference runtime
  └── lifecycle

browser-managed

application
  └── feature request

browser
  ├── capability API
  ├── model choice
  ├── weights
  ├── inference runtime
  └── lifecycle

That abstraction creates leverage. It also removes control.

The application may gain a simpler API, shared model storage, browser-level updates, and a runtime selected for the current device. In return, it cannot assume that every machine is eligible, that the model is already present, that its exact implementation will remain fixed, or that the browser exposes every metric a developer would like to inspect.

This is the first principle of browser-managed AI:

The browser owns the mechanism. The application owns the experience around an uncertain capability.

2. The model is becoming an implementation detail

Developers naturally ask which model powers an API. That question matters. Model choice affects quality, latency, supported languages, context limits, memory use and behavior under adversarial input.

But a capability API creates a second question:

Which properties may the application safely depend on even when the implementation changes?

Consider a program that calls LanguageModel.create() and then prompts the resulting session. The program depends directly on the Prompt API contract. It depends only indirectly on the particular weights behind that contract.

application feature
        ↓
Prompt API contract
        ↓
browser AI implementation
        ↓
current model and runtime

Chrome’s public documentation has described the Prompt API using Gemini Nano, while experimental Chrome builds can test a newer model behind the built-in infrastructure. The exact experimental model is interesting, but the architectural result is more durable: an application can remain largely unchanged while the browser changes the implementation underneath it.

We should not confuse abstraction with equivalence. Replacing a model can change outputs even when the JavaScript interface remains identical. A prompt that reliably produced a three-field result yesterday may produce different phrasing tomorrow. Latency and context behavior may move. Safety behavior may move. Bugs may disappear and regressions may arrive.

So browser-managed AI gives us two kinds of compatibility:

1. Interface compatibility: the API still accepts the same operations and options.
2. Behavioral compatibility: the feature still meets its product-level quality requirements.

The browser can provide the first.

Only our evaluations can establish the second.

This is why the observatory will record capability and implementation-adjacent facts where they are available, while our test fixtures record behavior. We do not want to discover a behavioral change from a user report three weeks after a browser update.

3. Locality changes the path, not the need for architecture

On-device inference is often summarized with three claims:

• lower latency;
• better privacy;
• no per-request server cost.

Each can be true. None is unconditional.

Latency

Removing a network round trip can improve responsiveness. A small model close to the interface can also stream its first visible output quickly. But the first use may require a substantial download. Session creation may require model loading. Throughput varies with hardware and competing work. A larger remote model on optimized infrastructure may still finish some tasks faster.

The useful measurement is not “local is fast.” It is a distribution:

availability check
      + download time, when needed
      + model load and session creation
      + time to first output
      + generation time
      = user-perceived latency

Warm-run tokens per second describe only one portion of that path.

Privacy

When inference happens locally, prompt content need not be sent to a model provider merely to obtain a completion. That is a meaningful privacy property.

It does not make the feature private by definition.

The surrounding page can still transmit data. Extensions can request broad permissions. Telemetry can accidentally retain prompts. Generated text can be inserted into networked workflows. A malicious page can attempt prompt injection. An application can combine local inference with cloud fallback without making the transition clear.

Privacy therefore belongs to the complete data flow, not the geographic location of one computation.

Cost

Local inference can remove marginal model-provider charges from the application developer. The computation still has a cost: device energy, storage, memory, download bandwidth, engineering complexity and support burden. The browser and device absorb resources that a server architecture would absorb elsewhere.

A serious comparison must count both sides.

4. AI capability becomes state

A normal JavaScript function is either present or absent. A browser-managed AI capability has a richer lifecycle.

At minimum, the application may need to distinguish:

    stateDiagram-v2
    [*] --> Unsupported
    [*] --> Downloadable
    Downloadable --> Downloading: create after user action
    Downloading --> Available: download and preparation complete
    Available --> SessionReady: create session
    SessionReady --> Running: prompt
    Running --> SessionReady: response
    Running --> Failed: abort or error
  

Chrome’s API describes availability using states such as unavailable, downloadable, downloading, and available. That already tells us that the correct UI cannot be a button wired directly to prompt().

The application needs to answer:

• Is the JavaScript API exposed in this context?
• Is this device eligible for the requested options?
• Is the required model present?
• Does creating a session require a download?
• Did the user perform the activation required to begin it?
• How far has the download progressed?
• Is the model being prepared after the bytes arrive?
• Can the request be cancelled?
• Did the context window overflow?
• Should the feature retry, degrade, or offer a remote fallback?

These are application states even though the browser owns the model.

That leads to the second principle:

Built-in does not mean always ready. It means lifecycle is shared between browser and application.

5. The browser contains several AI layers

It is useful to separate the emerging architecture before we write code.

Layer 1: execution primitives

WebAssembly, WebGPU, workers, streams and storage allow applications to execute and manage computation. These are general browser mechanisms. They do not prescribe a model or an AI product.

Layer 2: application-managed AI

Libraries can use those primitives to load models selected by the application. This maximizes control and portability at the cost of packaging and lifecycle responsibility.

Layer 3: browser-managed AI APIs

The browser exposes general or task-specific capabilities: prompting, summarization, writing, rewriting, proofreading, translation and language detection. The browser manages the associated foundation or expert models.

Layer 4: tool interfaces

WebMCP allows a site to describe operations as structured tools with names, descriptions and input schemas. This gives an agent a semantic interface rather than forcing it to infer every action from pixels and DOM structure.

Layer 5: agent runtime

A model, state, policy, permissions and tools can be composed into a loop that selects and executes actions. The browser then becomes more than an inference host. It becomes a plausible operating environment for agents.

These layers are related but not interchangeable. WebGPU is not the Prompt API. The Prompt API is not an agent. WebMCP does not itself decide which tool to call. A DevTools AI assistant is a product built from mechanisms rather than the mechanism itself.

Keeping the layers separate prevents nearly every exciting announcement from being misread as a complete system.

6. An AI-enabled site is a context system, not a giant prompt

Saying that an entire website is “AI enabled” can imply that every page is copied into one enormous prompt. That would be expensive, slow, difficult to update and hostile to privacy.

The stronger architecture has four stages:

    flowchart LR
    H[Hugo content] --> M[Site manifest]
    M --> R[Local retrieval]
    R --> C[Bounded context]
    C --> A[Model and typed tools]
  

At build time, Hugo already knows the books, chapters, headings, descriptions, tags and stable URLs. The site can publish that structure as a versioned context manifest. The browser can build or load a local index, retrieve only passages relevant to the current request, and disclose exactly which fragments entered the model context.

The site can also expose semantic operations:

search_site
get_chapter
explain_selection
compare_chapters
run_experiment
inspect_evidence
apply_personal_policy

This is more than placing a chat box beside an article. The current page supplies location and selection. The site supplies structured knowledge and capabilities. The browser supplies one possible model runtime. The user supplies the goal, the provider policy and authority for any effect.

The AI layer therefore becomes part of site navigation and interaction without becoming the only interface. Every answer should remain grounded in identifiable source passages. Every tool should have a contract. Every consequential action should remain behind a policy or human approval boundary.

That is Stage Two of this book. Stage One gives us a controlled laboratory in which to build and observe each mechanism before it is allowed to mediate the entire site.

7. Our instruments: Browser AI Laboratory and Observatory

If the book only contains examples that print answers to the console, it will miss the engineering problem.

We need an instrument that lets us see the runtime as an event sequence.

The first public surface is a top-level Browser AI Laboratory page. It performs capability checks in the page’s real execution context, starts downloads or sessions only after a user action, and renders either live events or an explicitly labelled recorded trace. A chapter query selects the reader’s position so that the same application grows with the book.

The deeper instrument is Browser AI Observatory: a Manifest V3 DevTools extension with a dedicated panel. The panel begins with calls owned by the extension itself. An opt-in instrumentation bridge allows applications under development—including the laboratory—to publish browser-AI traces to the panel.

The distinction is important. A DevTools extension cannot responsibly promise that it can see every opaque internal event in every page. We will define what is directly observable, what requires application instrumentation, and what the browser does not expose.

The initial trace will contain:

trace identity
origin and inspected tab
API and requested capabilities
availability result
session creation start/end
download progress
prompt start
first output time
stream chunks
completion or abort
error category
redacted size and timing metrics

The interface will answer concrete questions:

• Why is the feature unavailable on this machine?
• Is the model missing, downloading, loading or ready?
• How long did session creation take?
• How long until the first output appeared?
• Did generation slow down during the run?
• Was the request aborted or rejected?
• Which session produced this output?
• Did a browser or model change alter the result on our evaluation cases?
• Which WebMCP tool was offered, selected and executed?

The extension will also impose a rule on itself:

Prompts and page content are sensitive by default. Capture must be explicit, visible, bounded and redactable.

An observability tool that silently creates a second privacy problem would contradict the architecture it is meant to study.

8. The book will proceed by experiments

We will not organize the work as a catalogue of APIs. We will organize it as a sequence of failures and measurements.

The first experimental group asks four questions:

1. What changed when the model moved behind a browser capability boundary?
2. What lifecycle must an application handle before it can safely prompt?
3. What is the smallest working DevTools extension that exposes that lifecycle?
4. What must be recorded before a demo becomes debuggable software?

Later groups will add task APIs, sessions and context, model changes, structured outputs, evaluation, hybrid fallback, WebMCP discovery, tool execution, permissions and prompt-injection defenses.

Every feature must earn its place by answering an observed problem.

This gives us a loop:

    flowchart TD
    Q[Question] --> E[Experiment]
    E --> T[Trace]
    T --> C[Chapter]
    C --> X[Extension capability]
    X --> Q
  

The book explains the mechanism.

The laboratory lets the reader run it.

The Observatory tests the book’s claims.

The AI-enabled site composes those tested mechanisms into a new interface.

Conclusion

Browser AI is not merely a smaller language model running in JavaScript.

The important transition is a new allocation of responsibility. The application asks for a capability. The browser can manage the model and runtime. The user’s device performs the work. The application must still handle availability, download, latency, failure, privacy and behavioral change.

That is enough to give us the first architectural definition:

Browser-managed AI is a probabilistic capability whose mechanism belongs to the browser but whose consequences belong to the application.

It also gives the book a concrete trajectory. First, each chapter becomes a live, inspectable browser experiment. Then the complete site becomes structured context that a user-selected model can navigate through explicit tools and policies.

The next chapter opens that capability boundary. We will map the API families, follow the model lifecycle from absence to execution, and turn “built-in” into a state machine precise enough to implement.

Sources and further reading

1. Chrome for Developers, Built-in AI.
2. Chrome for Developers, Get started with built-in AI.
3. Chrome for Developers, The Prompt API.
4. Chrome for Developers, Understand built-in model management in Chrome.
5. Chrome for Developers, WebMCP and AI agents.