Chrome 157 puts a decision model in the browser: when it beats your rules engine — and when it doesn't

Chrome's Decisions API (window.DecisionModel) lets a site ask the browser closed questions — yes/no, pick from a list, rate something — and get the answer back with its probability, computed on the user's own machine, in a single model pass, with the text never leaving the device. The code landed in Chromium between October 6 and 8, 2026; the chrome://flags#decisions-api flag is riding the Chrome 157 beta, which ships today, October 14, with stable scheduled for November 3. Our position, after reading the code reviews and the independent tests: we would not put it in a production interface yet. Accuracy swings from 38% to 85% depending on the question schema, which means the schema is the product — and a badly designed confidence gate is worse than a real if.

What it is, in one sentence

An if whose condition the model understands instead of the person who wrote the code. You describe your questions in a schema — each one boolean, choice, or score — pass in the user's text, and get back, per question, the winning label, a confidence between 0 and 1, and the full probability distribution:

const model = await DecisionModel.create({
  questions: [{
    id: "intention",
    prompt: "Is the visitor here to buy or to research?",
    type: "choice",
    options: [
      { label: "buy", description: "wants pricing, stock, or a demo" },
      { label: "research", description: "wants an explanation or a comparison" }
    ]
  }]
});

const result = await model.decide(visitorText);
// result.intention.label / .confidence / .probabilities

Before you create anything, DecisionModel.availability() returns available, downloadable, downloading, or unavailable. The order matters: downloadable does not mean yes — it means not yet.

Why this is not just another Prompt API

The difference is architectural, not branding. The Prompt API decodes token by token — hundreds of milliseconds per answer, free-form output that has to be parsed. The Decisions API does logarithmic scoring in a single forward pass: the input text and each candidate answer are compared by cosine similarity, and the similarities are turned into probabilities with a softmax at temperature 0.05. The result is a "System 1" decision engine, not a sentence generator.

The numbers circulating with the first independent tests give the scale: ~0.2 s per decision with EmbeddingGemma, ~1.5 s with Laya, ~2.4 s with Gemma 4 (RESONEO, 414 queries tested). None of them compete with a local if, and none pretend to. The correct comparison is a network round trip to a server-side LLM, not JavaScript.

Three limits straight from the code are worth knowing before anyone gets excited:

A fourth piece of policy is worth remembering: the API shares the language-model Permissions Policy with the Prompt API. Whoever already controls who may use built-in AI on their origin controls this API with the same key.

The three pieces that moved in the same week

This is not an isolated feature. Between October 6 and 8, 2026, three pieces moved that only make sense together:

The point is that MediaPipe Decision Maker already works on any site today (official documentation): the same three primitives (BooleanQuestion, ChoiceQuestion, ScoreQuestion), the same engines, calibrated probabilities out of the box. What changes is who pays for the model: with MediaPipe each site downloads its own — RESONEO measured roughly 165 MB with EmbeddingGemma 2 and 678 MB with Laya — while Chrome would share a single model across every site that user visits. Telemetry changes too: MediaPipe reports the site, the browser, the decision count, and response times to Google, though never the text.

The schema is the product: 38% to 85%

This is the finding that should slow down any enthusiasm. In the most complete independent test published so far — 414 queries in French and English across 11 mock schemas for car, hotel, and appliance sites — the default engine with the default schema was right 38% of the time and fell back to the "any" option 70% of the time. Four edits to the schema wording — describing each option instead of merely labeling it — took that to 58%. With the best engine tested, 85%. Same API, same queries, four rewrites: 47 points of difference.

A second finding comes from reading the actual code reviews (DEJAN, October 8, 2026): because every candidate answer repeats the question text, their embeddings share a large common component, the margin between them shrinks, and confidence collapses toward uniform. A Google reviewer flagged exactly this in the review itself. Practically: confidence > 0.5 as a safety threshold is a statement of intent, not a gate.

That is why our policy does not rest on raw confidence but on the margin between the first and second option — and on that margin being wide enough that the deterministic fallback has nothing left to say.

Four paths for the same decision

The typical mistake is to present this API as a replacement for the rules engine. It is not. It is a fourth path for one very specific kind of decision — free user text turned into a closed option.

And inside the on-device path, three engines with different profiles:

Our shipping policy: six rules

Before a decision model touches a real interface:

1. Never on unattended paths. Money, permissions, publishing, deleting: out. A decision engine that is right 38% of the time in the worst case signs nothing irreversible.
2. Gate on margin, not raw confidence. Require the winning option to beat the second one by a defined margin (we set 0.15 across the distribution) and drop the rest. Confidence collapses toward uniform; margin lies less.
3. availability() before promises. downloadable and downloading are treated as "not yet." If the model is not ready, the deterministic path wins — it does not wait.
4. Download only after a user gesture. Chrome has required this since October 8; use it. Kick off the download on the first real interaction, not on render.
5. Two weeks in shadow mode. Log the model's decisions next to your rules' decisions without applying them. Two weeks of your own traffic tells you whether the schema works on your text, not on someone else's 414 queries.
6. The deterministic fallback never gets deleted. It is the same doctrine we already apply to navigator.cpuPerformance: unknown is treated as the safe value. If the API does not exist — Firefox, Safari, Android, Chrome before 157 — the site behaves exactly as it did before.

What we actually do today

None of this is a new doctrine for us; what changed is the object of the doctrine. When we argued that Chrome's two-week release cycle forces an adoption pattern — enable it where it exists, keep working where it doesn't — we were talking about CSS APIs. The Decisions API is the same pattern with a product question behind it: which part of your interface makes decisions that you still resolve with hand-written rules?

Rules win when the criterion is explicit, auditable, and the input arrives already structured — rules still beat agents on bounded processes, and this API does not change that. The model wins when the input is text written by a person and the output is one of three possible options: search filters, the intent behind a query, triage of an inbound message. There, and only there, an on-device "semantic if" saves a network round trip, a token invoice, and a data leak.

The bottom line

Chrome 157 turns an architecture question into something you can test this quarter: not "should I use AI on the front end" but "which decisions in my interface still depend on someone having written the right rule." The correct answer right now is conservative — flag, shadow, margin, fallback — and it will stay that way for months: the API is desktop-only, expires at milestone 160, and its real accuracy depends almost entirely on how well you write the schema. Write it well and you gain 47 points. Write it the way anyone would write it and you have a 38% making decisions that used to be free and correct.