Browser AI on Programmer.ie: Modern AI programming

The Browser Stops Being Just a Client

Wed, 02 Sep 2026 12:00:00 +0100

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.

What Does Built-In Actually Mean?

Wed, 02 Sep 2026 12:05:00 +0100

The word built-in suggests permanence.

A built-in function is present when the program starts. A built-in browser feature is expected to work without an installer, account or deployment. If a web developer hears that AI is built into the browser, the obvious mental model is a global function waiting to be called.

const answer = await browserAI.prompt("Explain this page");

That is not the system we actually have.

The API may be absent. The device may be ineligible. The requested language or modality may be unsupported. A model may need to be downloaded. Downloading may require a user action. The bytes can arrive before extraction and loading finish. A session can be created and later exhaust its context. The same interface can be backed by a changed implementation after a browser update.

One Runtime, Several Interfaces

Wed, 02 Sep 2026 14:00:00 +0100

The first Browser AI Observatory knew about one global object: LanguageModel.

That was enough to expose the common lifecycle. We could inspect availability, create a session, monitor model acquisition, stream output, cancel a request and record what happened.

Chrome also exposes narrower built-in AI capabilities. Instead of asking a general language-model session to perform an arbitrary task, an application can create a summarizer, writer, rewriter, proofreader, translator or language detector.

Summarization Is a Contract

Wed, 02 Sep 2026 14:05:00 +0100

Summarization looks like the ideal local AI feature.

The input is already in the browser. The desired output is smaller than the input. The task is useful for articles, documentation, conversations, reviews and support content. Sending the entire source to a remote provider can feel disproportionate when a browser-managed model can operate on the device.

So the implementation seems obvious:

const summarizer = await Summarizer.create();
const result = await summarizer.summarize(text);

The code is correct.

The feature is unspecified.

Writing, Rewriting and Proofreading Are Different Operations

Wed, 02 Sep 2026 14:10:00 +0100

Writer, Rewriter and Proofreader all accept text and return text-related results.

That surface similarity makes it tempting to place them behind one function:

const output = await improveText(input);

The name hides the most important property of the operation.

How much is it allowed to change?

A writer may create content that did not exist. A rewriter may change expression while preserving the underlying message. A proofreader should correct a bounded class of errors while leaving correct content alone.

Language Detection Is a Decision, Not an Answer

Wed, 02 Sep 2026 14:15:00 +0100

Translation appears to be a two-step browser-AI pipeline:

text
  ↓
detect language
  ↓
translate to target language

The implementation is short enough to fit inside one event handler.

const candidates = await detector.detect(text);
const sourceLanguage = candidates[0].detectedLanguage;
const translator = await Translator.create({
  sourceLanguage,
  targetLanguage: "en"
});
const output = await translator.translate(text);

The dangerous line is not the model call.

It is the array index.

candidates[0] is the highest-ranked language returned by the detector. That does not make it correct, supported for translation, or confident enough to justify an automatic action.

A Session Is Not a Stateless Function

Wed, 02 Sep 2026 15:00:00 +0100

A remote model API often encourages a simple mental model:

const answer = await complete(prompt);

Input goes in. Output comes back. Any conversation state is reconstructed by the application and sent again.

A browser-managed Prompt API session is a different kind of object. It owns resources, may retain conversational state, reports a finite input budget, supports branching in some implementations, and should be destroyed when its work is finished.

The correct abstraction is not a stateless function.

When the Context Window Fills

Wed, 02 Sep 2026 15:15:00 +0100

A stateful session eventually encounters a physical limit.

Prompts, initial instructions, examples, conversation history and model outputs all compete for a finite context budget. Once the budget is exhausted, the application cannot solve the problem by pretending the next message is independent.

The difficult question is not how to delete text.

It is how to preserve the right state.

1. The context window is a budget

When a session exposes usage and quota, context pressure becomes observable:

Cold Starts, Warm Runs and Real Latency

Wed, 02 Sep 2026 15:30:00 +0100

“Local AI is faster” is not a measurement.

It compresses several different waiting periods into one adjective. A browser-native feature can avoid network round trips and still make a user wait for model acquisition, process startup, session creation, context ingestion or slow generation.

To understand latency, we have to take the lifecycle apart.

1. One duration hides several clocks

For one interaction, useful timestamps include:

Phase	Starts	Ends	User-visible?
Capability inspection	`availability()` call	state returned	Usually not
Acquisition	session request requires assets	assets ready	Yes, if it blocks
Session creation	`create()` called	session returned	Often
Prompt startup	prompt called	first chunk	Yes
Generation	first chunk	final chunk	Yes
Validation	output complete	feature accepted/rejected	Sometimes

The perceived wait for a streaming feature is often dominated by time to first output:

The Browser Manages the Model

Wed, 02 Sep 2026 15:45:00 +0100

The central promise of built-in AI is an abstraction boundary:

application
    ↓
browser AI API
    ↓
browser-managed runtime
    ↓
current model and execution strategy

The application asks for a capability. The browser chooses how to provide it.

That separation is powerful, but it does not make the lower layers irrelevant. Changes beneath the API can alter availability, accepted options, performance and behavior.

We encountered that fact before completing our first prompt experiment.

A Resolved Promise Is Not a Correct Answer

Wed, 02 Sep 2026 16:00:00 +0100

The following code has only one definition of success:

try {
  const output = await session.prompt(input);
  show(output);
} catch (error) {
  showFailure(error);
}

If the promise resolves, the interface displays the result.

That is sufficient for a deterministic lookup whose return value is authoritative. It is not sufficient for a probabilistic system that can return fluent, well-formed and incorrect text.

A resolved promise proves that an operation completed according to the runtime contract. It does not prove that the feature did its job.

Evaluate the Feature, Not the Demo

Wed, 02 Sep 2026 16:15:00 +0100

A demo asks whether one carefully chosen example can work.

A feature evaluation asks how often the product contract holds across the inputs, states and failures users will actually encounter.

Both have value. Confusing them is the problem.

1. The unit of evaluation is the feature

“Evaluate Gemma 4” is too broad for our application. “Evaluate this prompt” is too narrow.

The useful unit is something a user attempts:

summarize selected documentation
rewrite permission copy without changing authority
detect language and decide whether to translate
produce structured arguments for a read-only tool

Each feature includes input preparation, capability selection, model output, validation, fallback and UI behavior.

When Local Is Not Available

Wed, 02 Sep 2026 16:30:00 +0100

A browser-native AI feature cannot assume that its preferred local capability exists everywhere.

The API may be absent. Hardware may be ineligible. A language pair may be unsupported. Model assets may need acquisition. Session options may be rejected. Storage pressure or a browser update may change a state that worked yesterday.

Reliability begins by treating local availability as a runtime condition, not an installation promise.

1. Unavailable is not one state

A useful feature distinguishes:

Structured Output Is Still Model Output

Wed, 02 Sep 2026 16:45:00 +0100

JSON feels safer than prose because software can parse it.

That is a real advantage. It is not a guarantee that the values are correct, permitted or useful.

A model can produce perfectly valid JSON containing a nonexistent file, an unsupported operation, a reversed date range or an action the user never authorized.

Structured output is still model output.

1. Structure removes one class of ambiguity

Suppose we ask a model to choose a fixture and repetition count. Prose might return: