When Local Is Not Available

A browser-native AI feature cannot assume that its preferred local capability exists everywhere.

The API may be absent. Hardware may be ineligible. A language pair may be unsupported. Model assets may need acquisition. Session options may be rejected. Storage pressure or a browser update may change a state that worked yesterday.

Reliability begins by treating local availability as a runtime condition, not an installation promise.

1. Unavailable is not one state

A useful feature distinguishes:

“AI unavailable” erases decisions the application needs to make.

2. Degradation is a policy ladder

A sensible fallback order might be:

preferred browser-local capability
        ↓ unavailable
another compatible local browser worker
        ↓ unavailable
deterministic non-AI behavior
        ↓ insufficient
explicitly approved remote service
        ↓ unavailable or disallowed
manual workflow

The order depends on the feature. A language selector may prefer a deterministic user choice over any remote request. A bulk public-document evaluation may route to another local Chrome worker automatically.

The fallback should preserve the task contract, not merely produce some text.

3. Do not silently change the data route

Moving from browser-local inference to a cloud service changes the system.

local path
page content → browser-managed model → result

remote path
page content → network → service → model → result

The interface must disclose that change before protected content moves.

function chooseFallback({ localState, contentClass, remoteConsent }) {
  if (localState === "ready") return { route: "browser-local" };
  if (contentClass === "private") return { route: "manual", reason: "local-unavailable" };
  if (remoteConsent) return { route: "remote" };
  return { route: "manual", reason: "consent-required" };
}

Consent is not a Boolean remembered forever for every kind of data. It should be scoped to a route, purpose and retention policy.

4. Multiple Chromes can form a local worker pool

Our experimental workflow has another kind of fallback. One Chrome profile may run the default browser configuration, another may run an experimental model flag, and a third may exercise a different channel.

Instead of entering metadata and clicking every fixture manually, we can treat each browser as a labelled worker:

    flowchart TD
    J[JSON job or inbox file] --> C[Local coordinator]
    C --> A[Chrome worker: baseline]
    C --> B[Chrome worker: experimental]
    A --> R[Trace and result store]
    B --> R
  

The coordinator is a localhost process. It can expose an HTTP endpoint and watch a directory. The extensions register capabilities, lease compatible jobs and return events.

The browser extension itself should not monitor an arbitrary Windows directory. Browser file access is permission-bound, and a Manifest V3 service worker may be suspended. Filesystem ownership belongs in the local process.

5. A job is declarative, not arbitrary JavaScript

One evaluation request might be:

{
  "schema": "browser-ai-observatory.job/1",
  "id": "job-20260902-001",
  "selector": {
    "tags": ["canary", "gemma4-enabled"]
  },
  "operation": "run-fixture",
  "payload": {
    "fixtureId": "prompt-session-accounting",
    "phase": "warm-session",
    "repetitions": 3
  },
  "captureMode": "metrics-only"
}

The operation comes from an allowlist. The coordinator must not accept a field such as javascript and execute it in a browser page.

Declarative jobs let us validate intent, enforce limits and compare results across workers.

6. Worker metadata should be registered once

Repeated run forms exist because the trace needs provenance. Automation should remove repetition without removing provenance.

Each Chrome profile can register a stable worker description:

{
  "workerId": "chrome-gemma4-01",
  "tags": ["canary", "gemma4-enabled", "windows"],
  "operatorModelLabel": "Gemma 4 flag enabled",
  "configurationNotes": "Chrome Canary; experimental flag enabled",
  "hardwareNotes": "Windows; 24 logical processors; 32 GiB memory"
}

The extension adds automatically observed information such as user agent, platform, language, extension version and current API states.

Model identity remains operator-supplied unless the browser begins attesting it.

7. Jobs need leases and idempotency

With several workers, two browsers must not accidentally perform one job unless replication was requested.

The coordinator can move a job through:

pending → leased → running → completed
                    ├── failed
                    └── expired → pending

A lease contains a worker ID and expiry. If the browser closes, the coordinator can make the job available again.

Every job has an idempotency key. Results carry the job ID, attempt ID and worker ID. A late result from an expired attempt remains evidence but does not overwrite the accepted result silently.

8. Directory input and HTTP input can share one contract

The local service can support both workflows:

POST /v1/jobs

and:

inbox/*.json

The directory watcher should read only fully written files. A producer writes to a temporary name and atomically renames it into the inbox. The coordinator validates the schema and moves the file to pending, rejected or dead-letter.

Both paths call the same job service. Otherwise file-based and HTTP submissions acquire different behavior over time.

9. Localhost is still a security boundary

A service listening on localhost can receive requests from other local processes and, depending on configuration, malicious web pages.

Minimum controls include:

• bind to 127.0.0.1, not every network interface;
• use a random authentication token;
• restrict CORS and validate the extension origin;
• cap job and result sizes;
• allowlist operations and target origins;
• require explicit approval for content capture or page actions;
• keep an append-only audit record;
• never place tokens inside exported traces.

“Local” does not mean “trusted.”

10. Another worker is not always a valid fallback

A job requesting the experimental configuration should not silently run on the baseline worker. That would produce a result while invalidating the comparison.

Worker selection needs hard requirements and preferences:

{
  "requires": ["prompt-api", "gemma4-enabled"],
  "prefers": ["warm-session"],
  "onNoMatch": "leave-pending"
}

For some product tasks, another compatible local worker is acceptable. For controlled experiments, configuration mismatch must stop the job.

Routing success is subordinate to experimental validity.

11. Fallback decisions belong in the trace

Record:

• requested route;
• observed capability state;
• selected route and worker;
• rejected alternatives;
• consent or policy decision;
• whether data crossed a network boundary;
• resulting feature evaluation.

This lets us distinguish “the local model produced a bad result” from “the local capability was absent and a different system handled the task.”

Without route evidence, evaluation results from different systems can be mixed accidentally.

Conclusion

Local AI availability is conditional. Reliable software classifies the condition, follows an explicit degradation policy and tells the user when the data route changes.

For our research environment, a localhost coordinator turns multiple Chrome profiles into a controlled worker pool. JSON jobs remove repeated forms while retaining worker provenance. Directory ingestion and HTTP submission share one validated contract.

The next chapter examines that contract more closely. JSON shape helps machines communicate, but structured output remains model output and must be parsed, validated and constrained before it can become executable authority.

Sources and further reading

1. Chrome for Developers, Get started with built-in AI.
2. Chrome for Developers, Understand built-in model management in Chrome.
3. Chrome Extensions, Native messaging.
4. Chrome Extensions, Declare permissions.