Chrome Built-in AI on Programmer.ie: Modern AI programming

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.

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:

From Buttons to Capabilities

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

A browser agent can operate software by looking at a page, guessing which control matters and simulating a click.

That is sometimes necessary. It should not be the preferred contract between two pieces of software.

The alternative is a capability: an operation the application exposes deliberately, with a name, description, input schema, result and authority boundary.

1. A button is evidence, not an interface contract

The text “Book” may represent a purchase, reservation, navigation link or decorative heading. Position and colour help a human infer meaning, but none provides a stable machine contract.

Expose the First WebMCP Tool

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

Our first WebMCP tool should not send a message, edit a document or buy anything.

It should read from the book we control.

We will expose search_book: a bounded operation that finds relevant chapters and passages.

1. Start with a narrow contract

Conceptually, the page registers:

navigator.modelContext.registerTool({
  name: "search_book",
  description: "Search this book for passages related to a query.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", minLength: 2, maxLength: 300 },
      limit: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["query"],
    additionalProperties: false
  },
  execute: ({ query, limit = 5 }) => searchIndex(query, limit)
});

WebMCP is evolving, so the exact registration surface must be checked against the browser version used for an experiment. The durable architecture is name, description, schema and implementation.

Tool Choice Is a Behavioral Problem

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

A tool can be perfectly implemented and never used correctly.

Once an agent sees several capabilities, success depends on a behavioral pipeline:

discover → select → construct arguments → invoke → interpret result

A single “task passed” score cannot tell us which stage failed.

1. Discovery precedes choice

If the tool never enters the agent’s effective context, it cannot be selected. Record which registrations were available, filtered, truncated or rejected.