v157 · built-in ai · capability probe
The proposed surface, probed
The proposal is specific: a DecisionModel interface on window, static availability() and create(), instance decide(), destroy() and a read-only preference. This page checks each of those exact names against the browser you are using, then goes one step further: it actually calls DecisionModel.availability(schema) and prints whatever really comes back — an availability state, or the real exception.
Honest status (2026-10): ChromeStatus lists a Chrome 157 developer trial, but the public implementation CLs are still in review — AIDecisionModelAPI is not yet in runtime_enabled_features.json5 on main, and chrome://flags#decisions-api only exists on builds carrying CL 8504264. On a build that has them: enable chrome://flags/#decisions-api, or launch with --enable-blink-features=AIDecisionModelAPI. Today you can also try the identical surface via the WebAI extension polyfill, which this page detects and uses for real. No path here fakes a result.
Member-by-member
Probing…
| surface | present? | what it is for |
|---|
The real call
This button runs, verbatim, await DecisionModel.availability({ expectedInputs: [{ type: "text", languages: ["en"] }], questions: [{ id: "probe", type: "boolean", prompt: "Is this input a question?" }] }) — the minimal valid schema — and prints the result.
reading an availability answer
Per Built-in AI conventions the promise resolves to one of "unavailable" (this device or language cannot run it), "downloadable" (supported, model not yet on disk — create() would download, requiring a user gesture), "downloading", or "available" (ready now). A ReferenceError: DecisionModel is not defined is the honest answer on every browser that has not landed the API — that is not a failure of this page; it is the current state of the platform, and the exact thing to feature-detect before using the API.