"Serverless AI features" with Chrome built-in AI (Prompt API) — On-device AI implementation in custom development 2026

In Chrome for Developers' Build new features using built-in AI in Chrome (2026-05-26), the suite of AI capabilities built directly into the browser was organized. Through APIs such as LanguageModel (Prompt API), Summarizer, Translator, LanguageDetector, Writer, and Rewriter, it is becoming possible to run summarization, translation, language detection, classification, and draft generation on the lightweight on-device Gemini Nano model without spinning up servers, paying for LLM APIs, sending input data externally, and even while offline. The browser downloads the model only once initially, after which all processing runs entirely on the device.

In client web development, we have seen an influx of inquiries stating: "We want to add AI features to our client's site, but server costs are unpredictable, and we cannot send input data to external servers." While "nice-to-have AI features" like summarize buttons, translation, inquiry categorization, and drafting assistance are attractive, implementing them via server-hosted LLM APIs hits a wall: pay-as-you-go costs scale directly with usage, and sending personal or confidential internal data to third-party APIs stalls during internal approval. When supporting client web development, we view this as a design challenge: not whether we can "use the latest AI," but whether we can design and deliver maintainable AI features that sidestep server costs and privacy constraints while incorporating fallbacks for unsupported browsers. Connecting this with the native feature adoption policies in Using Modern CSS Native Features in Client Projects (GH Media) and the on-device architecture in Local-First Web Architecture (GH Media), this article organizes "on-device AI feature implementation support" as a custom development package.

Why browser built-in AI right now?

In short, "calling an LLM API" and "delivering AI features that bypass server costs and privacy constraints" are completely different propositions, and in client development, "establishing on-device processing as the primary path, falling back to server AI in unsupported environments, and handing off code in a production-ready state" has become a core quality prerequisite. This allows us to guarantee deliverables featuring "AI functionality whose billing does not scale with usage" and "AI functionality that never exposes input externally." At the same time, "running anywhere" remains the distinct advantage of server-side AI, so the two are best combined rather than treated as mutually exclusive.

What you can do with built-in AI APIs

1. General-purpose instruction via the Prompt API (LanguageModel)

LanguageModel is a general-purpose API that passes natural language prompts directly to Gemini Nano. It can be used for classifying customer inquiries, extracting structured data (with JSON schema specifications), and handling simple Q&A. The standard pattern is to check model availability (available / downloadable / downloading / unavailable) using availability() before execution and communicate download progress to the user if the model is not yet cached.

// 擬似コード（実際の引数は仕様に追従して確認すること）
if ('LanguageModel' in self) {
  const status = await LanguageModel.availability();
  if (status === 'unavailable') {
    // 未対応 → サーバーAIへフォールバック
    return await fallbackToServerAI(input);
  }
  const session = await LanguageModel.create({
    monitor(m) {
      m.addEventListener('downloadprogress', (e) => {
        console.log(`モデル取得中: ${Math.round(e.loaded * 100)}%`);
      });
    },
  });
  const result = await session.prompt(
    `次の問い合わせを「請求」「技術」「その他」に分類して: ${input}`
  );
  return result;
}

2. Handling text with Summarizer, Writer, and Rewriter

Summarizer can be used for body text summarization, headline generation, and meta descriptions; Writer generates new text tailored to specified tasks; and Rewriter assists in rephrasing and fine-tuning existing copy. All follow the shared workflow of availability() → create() → execution, allowing download progress monitoring during create().

// 擬似コード: 端末内で記事本文を要約する
if ('Summarizer' in self) {
  const summarizer = await Summarizer.create({
    type: 'tldr',
    length: 'short',
    monitor(m) {
      m.addEventListener('downloadprogress', (e) => {
        updateProgressUI(e.loaded);
      });
    },
  });
  const summary = await summarizer.summarize(articleText);
  renderSummary(summary);
}

3. Multilingual localization with Translator and Language Detector

You can detect the input language using LanguageDetector and perform on-device translation using Translator. Because translation completes inside the browser without invoking cloud translation APIs, this is ideal for contact forms and help documentation where teams wish to avoid API fees and external data transmission. Supported language pairs should be verified in advance via availability().

The 5 phases of "on-device AI feature implementation support" offered in client development

Phase 1: Inventory and assessment (1 week)

• Auditing candidate AI features (summarization, translation, classification, drafting) for the client site
• Estimating projected billing and data transmission risks if built using server-side AI
• Confirming browser and device support requirements
• Deliverable: Candidate AI feature list + on-device feasibility report

Phase 2: Design (1–2 weeks)

• Separating features assigned to on-device AI from those retained on server AI
• Determining fallback policies for unsupported browsers
• Designing UX for un-downloaded models (progress display, latency handling, alternative UI)
• Deliverables: Implementation policy document + fallback design specification

Phase 3: Implementation (2–4 weeks)

• Implementing availability() branch logic, model download progress UI, and individual API calls
• Refining prompts and post-processing to absorb output variance
• Implementing server AI fallbacks for unsupported environments
• Deliverable: Implemented features + implementation standard documentation

Phase 4: Verification and handover (1 week)

• Verifying behavior and fallbacks across supported/unsupported browsers and devices
• Confirming output quality and data privacy (absence of transmission)
• Deliverables: Verification report + maintenance procedure manual

Phase 5: Continuous maintenance (ongoing)

• Ongoing monitoring of browser and model support updates
• Evaluating phased removal of fallbacks
• Implementing additional AI features

Implementation standards set for custom development

Which projects need this and which do not

Six clauses to include in custom development contracts

Client-side estimated ROI (assuming a site making heavy use of AI features)

Even an initial assessment (starting from 200,000 yen) delivers tangible value simply by clarifying how much of your intended AI functionality can run on-device and how much server spend and data transmission can be eliminated. The usage-based pricing of server LLM APIs directly hits your cost structure the instant adoption scales.

Five common pitfalls to avoid

Pitfall 1: Failing to account for un-downloaded models

The initial run triggers a large model download, causing availability() to return downloadable. Display progress via downloadprogress and present alternative placeholder UI during acquisition.

Pitfall 2: Neglecting unsupported browsers

On-device AI requires compatible browsers and operating systems. Incorporate a fallback design to server AI for unsupported environments from the start.

Pitfall 3: Exposing raw, volatile output directly

Lightweight models exhibit output variance. Stabilize results through prompt engineering and post-processing (formatting/validation) rather than displaying raw output directly.

Pitfall 4: Postponing fallback design

Assuming "it runs on-device so no server is needed" causes features to disappear entirely on unsupported devices. Design conditional branches assuming hybrid server AI usage.

Pitfall 5: Assuming "on-device always means zero transmission"

When fallbacks invoke server AI, data is indeed transmitted. Explicitly document under what conditions data is transmitted to maintain absolute consistency with your privacy policy. If combining this with authentication and persistence, please also read Advancing Passwordless Authentication with Passkeys (GH Media).

90-day action plan

Summary — Moving from "calling LLM APIs" to "delivering by sidestepping constraints"

The practical arrival of Chrome built-in AI shifts the implementation paradigm for web AI from "paying meter-based fees to server LLM APIs" to "running on-device and relying on servers only when needed." From our position supporting client web development, our "on-device AI feature implementation support"—establishing on-device AI as the primary engine, engineering server AI fallbacks for unsupported environments, and clearly delineating privacy and quality parameters upon delivery—is a core service offering that sidesteps server cost and data privacy constraints. If you also need to build with comprehensive accessibility in mind, refer to Web Accessibility Implementation Guide (GH Media).

If you want to "curb server charges for AI features," "deploy AI capabilities without transmitting input data externally," or "have a solution delivered complete with fallbacks for unsupported browsers," please contact us through our contact form.

Sources

• Build new features using built-in AI in Chrome（Chrome for Developers 2026-05-26）
• The Prompt API（Chrome for Developers）
• Summarize with built-in AI（Chrome for Developers）
• Built-in AI APIs（Chrome for Developers）
• Using Modern Native CSS Features in Client Development (GH Media)
• Local-First Web Architecture (GH Media)
• Advancing Passwordless Authentication with Passkeys (GH Media)
• Web Accessibility Implementation Guide (GH Media)