A visitor types “cheap electric city car” into a car site’s search box. With the Decisions API, which Google is building for Chrome, the site will be able to ask the browser to tick the right filters, without going through a server. We tested it with the three AI models that can power it, then compared Chrome’s current model with its version 2, released on October 6.
Google is building two AI tools into Chrome that websites will be able to call. The embedding API sums up the meaning of a text as a “meaning signature”, a list of numbers used for instance to sort pages by topic. The Decisions API answers closed questions (yes or no, a pick from a list, a rating) about what the visitor types on the site. Both compute on the visitor’s own computer, and neither is switched on yet. On October 6, Google released EmbeddingGemma 2, the new version of Chrome’s model, and added the Decisions API to Chrome’s code. We tested the Decisions API on 414 queries and compared the two model versions on 151 pages.
The three reasons Google gives (Decisions API proposal, Chrome Status page for the embedding API, EmbeddingGemma 2 announcement), our reading, then where Chrome really stands on October 7, 2026.
The computation runs on the visitor’s own computer: no server to pay for, no personal data sent. When a visitor types “cheap women’s waterproof jacket” into a fashion site’s search box, the site can map the request to the right departments without paying an online AI. And every site shares the same model.
Google is targeting sites that need to decide quickly from a sentence. On a hotel site, which filters to tick for “dog-friendly, not too expensive”? In an online storage service, which button to press when someone types “share this file with my coworkers”?
According to Google, having a large model write an answer to choose between three options is “10 to 50 times” heavier. Google takes up the idea of Jev, launched on September 15 by the start-up TypeSafe AI: a model that does not write, but picks from answers set in advance. It cites Jev on its Chrome Status page and published its proposal two weeks later. Chrome does not run Jev, though: its engines are EmbeddingGemma, Laya (an open source equivalent of Jev) and Gemma 4, a large model that is more accurate but slower.
Google first wanted to classify users for advertising (Topics), then pages with the IAB advertising taxonomy (Classifier API), and dropped both. It now gives publishers the tool to create their own sections, such as “mountain trail running” or “first marathon”, and sort their pages into them. Neither the Decisions API proposal nor the Chrome Status page for the embedding API mentions advertising.
Everything is being prepared in Chrome’s test builds. As a reminder, a “meaning signature” is a list of 768 numbers that sums up a text; “women’s waterproof jacket” and “ladies’ rain coat” get close signatures without sharing a word.
| Item | What it is | In Chrome on October 7 |
|---|---|---|
| EmbeddingGemma 2 | Open model that turns text, images, audio or video into a meaning signature; 100 languages | Absent: Chrome still ships EmbeddingGemma 1 (May 2026) |
| Embedding API | Computes a text’s meaning signature for the site | Present but switched off, even in consumer Chrome |
| Decisions API | Answers a site’s closed questions about what the visitor types | Landed in Chrome Canary on October 7, behind an advanced setting. With no engine, it answers “unavailable” |
| Laya | Open source equivalent of Jev, built outside Google | Listed since October 5, but Chrome cannot run it yet |
| Gemma 4 | Large model that writes, already used by other Chrome AI tools | Its connection to the Decisions API is under review at Google |
Nothing is switched on yet, but our tests already show what to do, team by team.
| Team | What is coming | What you can do, and where |
|---|---|---|
| E‑commerce | Chrome will be able to turn a search typed on the site into filters | In the page code: write the schema, with one sentence per filter and per value (example below). In your site search history: collect real queries to test it as soon as the API opens |
| SEO and content | Sites and tags will be able to sort pages by topic in Chrome, which reads only the first 1,500 words or so | In the page content: say what it is about in the title, the standfirst and the first two paragraphs |
| Brand safety and contextual targeting | A third-party tag allowed by the publisher will be able to classify the page at display time | In your brand safety tool’s settings: define each prohibited topic in one sentence, and plan to review thresholds at every model change |
| Data and product | Meaning signatures computed for free on the visitor’s computer | In your database: store the source text and the model name with each signature, so everything can be recomputed. Never compare signatures from two models |
In practice, the site’s developer adds a small script to the page. The script describes the questions in a “schema”, a JSON-like object: for each question, its wording and its possible answers. When the visitor runs a search, the script passes the typed text to Chrome, which returns the chosen answer and a confidence score for each question; the script then ticks the filters. Example for a car site:
// The schema: the questions Chrome will have to settle const schema = { context: "", // left empty questions: [{ id: "body_type", type: "choice", prompt: "Which body type is the visitor looking for?", options: [ { label: "city car", description: "small urban car, easy to park" }, { label: "sedan", description: "family car with a large trunk" }, { label: "suv", description: "tall, roomy vehicle, 4x4 style" } ] }] }; // The text the visitor typed goes to Chrome, which picks an answer const model = await DecisionModel.create(schema); const answer = await model.decide(typedText); // answer.body_type: chosen answer + confidence score from 0 to 1
In our tests, four adjustments to this schema take Chrome’s current model from 38% to 58% correct answers:
This tuning has to be redone for each model: the same schema drops to 45% with EmbeddingGemma 2.
The API does not work in Chrome yet, so we rebuilt it from its code. We then wrote the questions of 11 mock sites (cars, hotels, home appliances…) and typed 414 searches and messages, in French and English, to check whether the API picks the right answers.
The API hands each question to an AI model, its “engine”. Google plans three: EmbeddingGemma, already in Chrome and fast (0.2 seconds per decision); Laya, an open source equivalent of Jev built outside Google (1.5 seconds); Gemma 4, a large model already used by other Chrome tools (2.4 seconds).
Yes/no questions: the correct answer is “no” 80.5% of the time, because most queries do not mention the criterion asked about.
| Car site filter | Correct answer | EmbeddingGemma | Laya | Gemma 4 |
|---|---|---|---|---|
| Body type | city car | any | sedan | city car |
| Powertrain | electric | any | electric | electric |
| Automatic gearbox required | no | yes | no | no |
| Low mileage required | no | yes | no | no |
| Budget, from 1 to 4 | 1 | 4 | 2 | 1 |
| Correct filters | 5 | 0 of 5 | 3 of 5 | 5 of 5 |
Green background: correct answer. Pink background: wrong answer.
For “mountain chalet for 8 people”, typed on a rental site, it ticks “pets allowed”, “pool” and “parking”. 14 of 18 yes/no questions get the same answer, whatever is typed.
EmbeddingGemma picks “other” or “any” 70% of the time, though that is the right answer in only 26% of cases. “Quiet 9 kg washing machine” ends up in “other appliance”.
Each answer comes with a confidence score from 0 to 1. In its examples, Google only applies the answer above 0.85. A single decision out of 1,365 clears that threshold.
Chrome does not compare the search alone with the possible answers: it inserts it into a sentence with the question and the site’s introduction, where it makes up only a fifth. All searches end up looking alike. With the same model, comparing the search alone with each answer gives 63% correct answers, 25 points more.
It is the only engine with a useful confidence score: 80% of answers exceed 0.85, and 91% of those are correct. But it takes 2.4 seconds per decision and more than 4 GB on the computer. Its connection is under review at Google.
Laya scores 64% and falls far less often for “any” options (21% instead of 70%). Chrome has listed three Laya models since October 5, but Google removed the code that connected them: Chrome cannot run them yet. We tested it with the public files of the same name.
51.5% correct answers, but only because it answers “no” more often, which happens to be right when the search does not mention the criterion. On multiple-choice questions, no progress.
The engines reproduce code that Google may still change before any release.
The other use of Chrome’s model: sorting pages by topic with the embedding API, for a site or an ad tag that wants to know what a page is about. We compared the two versions on 151 real pages from 45 sites, in French and English, across 12 topics.
With the current model, that 0.62 threshold flagged no normal page; with EmbeddingGemma 2, it flags all of them. And the two models’ signatures have almost nothing in common: any database built with the old one has to be redone.
A sports betting ad and a football match preview get almost the same score against a “content to avoid” profile (0.871 and 0.845). What works, with both models: describe each prohibited topic in one sentence, such as “content that encourages betting: betting offers, boosted odds, casino bonuses”.
EmbeddingGemma 2 is 2 to 5 times slower than the current model. Adding three examples per topic costs it 11 points: a single defining sentence works better.
On text, EmbeddingGemma 2 barely moves (61.36 against 61.15 on MTEB, the reference benchmark). It gains 9.9 points on code and now reads images, audio and video. None of this reaches Chrome, whose API handles text only.