Fragmentation of Built-In Browser AI APIs — Fallback Strategies for Client Web Development Following Mozilla's Opposition

In late April 2026, Mozilla published its formal opposition to Chrome's Prompt API (built-in browser LLM API) on the Web standards repository. While Chrome packages Gemini Nano directly within the browser to champion a world where "you can use an LLM simply by calling window.ai.languageModel from JavaScript," Mozilla opposes this on the grounds that "differences in underlying models across browsers compromise output quality compatibility for users."

Building "AI features that work in Chrome but fail in Firefox or Safari" in client web development instantly diminishes deliverable asset value. In this article, we outline the current state of built-in browser AI APIs and summarize implementation strategies designed with fallbacks for client projects.

Current state of built-in browser AI APIs (as of May 2026)

While Chrome (Google) charges ahead, Firefox (Mozilla) and Safari (Apple) exhibit distinctly different attitudes.

Chrome's Prompt API is a general-purpose API designed around bundling Gemini Nano (~2GB on-device model) to directly accept prompt strings and return responses. Mozilla argues against this general-purpose API, stating that "because outputs vary across model differences, it should not be incorporated into the Web platform."

On the other hand, "task-specific APIs" such as the Translator API and Summarizer API have relatively higher chances of cross-browser adoption, and Mozilla is conditionally supportive of the Translator API. In client web development, prioritizing "task-specific APIs" over "general-purpose LLM APIs" offers a safer guiding policy.

This can be viewed as the continuation of the "browser AI integration" covered in SEO Impact of Google AI Mode in Chrome, challenging how developers should prepare for this shift.

Three options for implementing browser AI features in client projects

Implementation patterns fall broadly into three options.

Option 1: Limit strictly to Chrome (not recommended)

Treating the feature strictly as a Chrome-exclusive capability. While acceptable for Web Store extensions or internal B2B tools (where Chrome is enforced), it should be avoided for public-facing client websites. The likelihood of incurring support overhead from "inquiries by Firefox users" post-delivery is high.

Option 2: Hybrid server LLM + browser AI (recommended)

Hosting an LLM API (OpenAI / Gemini / Claude) server-side, while preferentially utilizing the Prompt API whenever available in the browser. This two-tiered setup offers low latency and zero API cost on Chrome, while falling back to server APIs on other browsers. Implementation details are covered in the next section.

Option 3: Server LLM only (defensively robust)

Avoiding browser-side AI entirely. While losing the cost benefit for Chrome users, it delivers a uniform experience across all browsers and simplifies ongoing support. This is best suited for e-commerce, reservation platforms, and other systems where "feature failures are critical."

Selection criteria:

• Public-facing sites & large-scale e-commerce → Start evaluation from Option 3
• Internal tools & B2B admin panels → Adopt Option 2 with Chrome recommendation guidance
• Chrome extensions & restricted-distribution apps → Option 1 is also acceptable

Hybrid implementation sample — starting from feature detection

Here is an implementation sample for Option 2 (Hybrid). It uses Chrome's Prompt API when present, falling back to the server when absent.

// 1. Feature Detection
async function getLanguageModel() {
  // Chrome の window.ai.languageModel を試す
  if (typeof window !== 'undefined' && 'ai' in window && 'languageModel' in (window as any).ai) {
    try {
      const availability = await (window as any).ai.languageModel.availability();
      if (availability === 'available' || availability === 'downloadable') {
        return await (window as any).ai.languageModel.create();
      }
    } catch (e) {
      // ユーザーが許可しなかった/モデル未ダウンロード等
    }
  }
  return null;
}

// 2. クライアント側のラッパー
export async function summarize(text: string): Promise<string> {
  const localModel = await getLanguageModel();
  if (localModel) {
    // 端末内モデルで処理（高速・無料・オフライン可）
    return await localModel.prompt(`次の文章を 3 行で要約してください:\n${text}`);
  }
  // サーバー API にフォールバック
  const res = await fetch('/api/summarize', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text }),
  });
  if (!res.ok) throw new Error(`Summarize failed: ${res.status}`);
  const { summary } = await res.json();
  return summary;
}

The key design choice is to check for built-in browser APIs via getLanguageModel() once and cache the result. Running feature detection on every request risks repeatedly triggering user permission prompts, degrading UX.

The server-side /api/summarize can be implemented with OpenAI, Gemini, or Claude. By managing prompts centrally on the server, you can minimize quality discrepancies between in-browser and server models (refining server-side prompts to preserve consistent quality).

Design principles for progressive enhancement

Here are key design principles when incorporating browser AI capabilities into client projects.

In particular, managing the state of model downloads requires caution. Chrome downloads Gemini Nano (~2 GB) in the background during initial use, which can take several tens of minutes depending on network conditions. You should avoid a UX that leaves users waiting in silence without showing progress.

This corresponds to the AI equivalent of the "gradual adoption of browser features" covered in Web Platform Baseline 2026. As a rule of thumb, APIs not yet part of Baseline should be adopted on the premise of progressive enhancement.

Cost optimization for server-side LLMs

Here is the cost strategy for server-side LLMs used as fallback destinations in hybrid implementations.

For small-to-medium-scale custom development projects, "OpenAI / Anthropic API + Cloudflare Workers + Redis caching" provides the most cost-effective architecture. For volumes of 10,000 to 100,000 requests per month, costs typically fall within roughly 50,000 to 300,000 yen per month.

This seamlessly extends the edge API architecture covered in the Hono × Cloudflare Workers Edge API Guide to AI.

The "true cost of AI features" to estimate in custom development

Estimates for in-browser AI features fail if you only consider initial implementation expenses. Here is a breakdown of the ongoing costs that must be accounted for in custom development.

In reality, an AI feature requiring 1 to 3 million yen in initial implementation incurs an ongoing cost of 200,000 to 600,000 yen per month. Quoting a package of "initial fee + monthly maintenance" during contract negotiation prevents future disputes.

Conclusion — The stance to take in client web development during the "Chrome dominance" era

Mozilla's declaration of opposition was a symbolic event showing that in-browser AI will not progress as a monolith. In custom development, our fundamental policy is to "never build Chrome-exclusive features, or always provide fallbacks when doing so."

We offer phased packaging covering feature detection, hybrid implementation, and ongoing maintenance for in-browser AI functionality. With robust design predicated on progressive enhancement, we support client web development that avoids Chrome dependency. If you have concerns such as "We want to introduce in-browser AI but worry about compatibility" or "We built a Chrome-exclusive implementation and now want to support Firefox and Safari," please feel free to reach out via our contact form.

Sources

• Mozilla’s opposition to Chrome’s Prompt API（GitHub）
• Built-in AI APIs — Chrome for Developers
• Translator and Language Detector APIs — web.dev
• Apple Intelligence and the Web — WebKit Blog