Opera announced its WebAI preview on October 27. A wider debate about model choice and compatibility remains unsettled.

The big change

  • Opera’s browser exposes local AI to websites and extensions running on visitors’ computers.
  • A shared interface can reduce the need to build a separate model connection for every task, but it does not make the answers of different models interchangeable.
  • An application still needs a clear response when a capability is missing, and must explain if an alternative sends information to a server.

What Opera has announced

Opera’s announcement says users enable Web AI API in Settings → Opera AI, triggering a model download. It lists 64-bit Intel/AMD Windows PCs and Apple-silicon Macs; Linux, Intel Macs and Windows on Arm are excluded. Opera says individual sites require permission.

The company’s descriptions disagree on rollout: its blog names Opera One, GX and Neon in the preview, while its press release says Opera One is first and the others follow. The blog’s setup instructions start with Opera One. Check the installed version before relying on it.

Opera’s playground lists separate capabilities with availability indicators. Its indexed Prompt page shows a system prompt, sampling controls and a streaming option; the Semantic Embedder page shows a query and sentences for similarity ranking. These interfaces point to different tasks: generating language and comparing text by meaning.

BIG CHANGE did not run the playground on a supported Opera build or verify its generated code. A direct request to the Prompt page returned 404 during this check. The indexed controls describe an intended interface, not proof of successful execution or a recipe verified for an Opera version.

Why the same interface may not mean the same result

The Prompt API proposal describes a browser-provided model interface. The point is to let a page request a capability without building its own model-serving infrastructure. But a prompt is not like a calculation with one guaranteed answer: the model, its settings and the context supplied by the application can all affect the response.

Mozilla’s standards position is negative. It argues that developers may tune prompts to the quirks of a widely used model, making another model or even an update to the original perform worse for those applications. A common method name alone would not prevent that. A developer evaluating a feature needs representative tasks and expected outcomes, not only a check that the interface exists.

The Web Machine Learning Community Group’s May meeting notes show the problem being discussed from several directions. Participants considered describing model capabilities instead of brand names, and raised concerns that revealing installed models could enable fingerprinting. The group resolved to explore model-neutrality and interoperability issues and experiment with categorical sampling modes. These are research and design steps, not evidence that the issues have been solved or that Opera implements the proposals identically.

A decision is different from a generated answer

A separate Google Chrome team Decisions API explainer sketches a way to ask structured questions over input. Its example defines questions and options, checks availability, creates a session and submits text; the proposed result includes a selected label and probabilities. The document calls itself an early design sketch and says it has not been approved to ship in Chrome.

That distinction matters for a product choosing an output. A fixed choice can be easier to use in a defined workflow than free-form prose, but a valid label can still be the wrong answer. The application must decide how much uncertainty it can tolerate and when to ask a person to review. The explainer describes a proposal; it does not establish the behavior of Opera’s Decision implementation.

Local inference is one part of the data path

Running a task on a visitor’s computer can remove a cloud-model request, but the site can still send information elsewhere. WebKit’s position on the Prompt API makes that distinction explicit: a site controls its prompts and can receive and transmit the responses. Its concerns address the proposal, rather than proving how Opera handles permissions.

There is also a practical choice when a local capability is missing. Chrome’s documentation describes a hybrid approach using a server model as a fallback. That is a separate architectural example, not a verified Opera integration. The fallback can keep a feature available, but it changes where information goes and may introduce service costs. A product should make that change clear before a user supplies sensitive text; an honest unavailable state may be preferable to a silent switch.