Four layers. One tight contract.

Runs once per session (≤ 40ms) and re-runs on route failure. Emits a signed capability vector:

{
  "runtime": "browser" | "desktop" | "ios" | "android",
  "cpu":    { "cores": 8, "arch": "arm64", "isa_ext": ["neon","i8mm"] },
  "gpu":    { "vendor": "Apple", "model": "M3 Pro", "vram_mb": 18432, "webgpu": true },
  "npu":    { "present": true, "vendor": "Apple Neural Engine" },
  "ram":    { "total_mb": 18432, "free_mb": 9112 },
  "battery":{ "level": 0.82, "charging": true },
  "net":    { "rtt_ms": 34, "downlink_mbps": 118, "effective": "4g" },
  "sig":    "ed25519:..."
}

• First-run consent dialog (required under GDPR; configurable copy)
• Granular toggles: run locally, contribute to mesh, allow cloud fallback
• Battery floor slider (default: pause mesh work under 30%)
• Bandwidth cap (default: pause under metered connection)
• Live status indicator + receipts log

The Router Engine evaluates each incoming request against the requester's cost, latency, and privacy preferences, the device's capability vector, and the current state of the mesh pool. It selects among three tiers — local execution, peer mesh dispatch, and cloud fallback — choosing the tier that best satisfies the requester's constraints.

Privacy is a structural gate, not a policy check. For local-only requests, the privacy gate resolves synchronously before any network I/O occurs. No speculative cloud stream is started, no fetch is issued, and no data leaves the device. This is enforced by the structure of the routing path, not by a runtime check that could be bypassed.

Speculative dispatch reduces cold-start latency. When local execution is eligible but the model is still cold, the Router may start a cloud stream concurrently with local warm-up. If the local model becomes ready in time, the cloud stream is cancelled and local takes over. If not, the already-started cloud stream is kept. This optimization is never invoked for local-only or cost-first requests.

Candidate selection incorporates reputation and load. Among eligible mesh peers, the Router weights candidates by reputation, model availability, and current load. A small exploration factor ensures the router continues learning and prevents any single node from monopolizing traffic.

The probe (§ 2.A) is extended with two new fields on mobile runtimes:

{
  "battery": {
    "level": 0.82,
    "charging": true,
    "floor": 0.20          // user-configured minimum
  },
  "thermal": "nominal",    // nominal | fair | serious | critical
  "app_state": "foreground" // foreground | background-task | background
}

Developers set a participation profile at SDK init time. The Coordinator enforces the stricter of the developer profile and the user's personal settings — the user can always tighten, never loosen, what the developer allows.

new MeshInfer.AI({
  apiKey: 'msk_live_...',

  // Choose the participation profile for this app.
  // Users can tighten further in their own settings, but never loosen.
  meshParticipationProfile: 'eco',      // 'eco' | 'standard' | 'power' | 'off'

  // Or override individual thresholds for fine-grained control:
  meshPolicy: {
    requireCharging:  true,
    batteryMinLevel:  0.80,   // only contribute at 80%+
    thermalMaxState:  'nominal',
    maxTasksPerMin:   60,
  },
});

The participation profile sets static thresholds. Real-time device conditions act as a continuous hard filter on top — checked every heartbeat (15s). A condition breach triggers an immediate ephemeral off state regardless of the active profile.

The participation profile sets static thresholds. Real-time device conditions — battery level, thermal state, network type — act as a continuous hard filter on top, re-evaluated on every heartbeat. A condition breach triggers an immediate ephemeral off state regardless of the active profile: the node is removed from the dispatch pool, in-flight tasks complete normally, and no new tasks are accepted. Recovery requires the breached condition to remain satisfied across consecutive heartbeats, preventing rapid on/off cycling at threshold boundaries.

Single-node dispatch (1B–7B models) fails over atomically — the coordinator re-routes the entire request with no partial state to recover. Sharded inference across multiple nodes (70B+) requires an explicit migration strategy. Three approaches, phased by version:

Before attempting cache migration the Coordinator evaluates a viability gate. Migration is only initiated when it is strictly faster than restarting from cloud. The bandwidth estimate used in the gate is derived dynamically — not from a static config value.

Before attempting migration, the Coordinator evaluates a viability gate: migration is only initiated when it is strictly faster than restarting from cloud. The gate compares estimated transfer time against the remaining generation budget — if migration would consume too much of that budget, the request aborts to cloud immediately and no migration is attempted.

The score is a weighted blend of these signals, normalized to a 0–100 range. New nodes start at a neutral score and earn trust through task history. The score is stored per-node and updated in real time as events arrive — task completions, verification results, and heartbeat observations all adjust the score immediately. Old events lose weight as they age out of their measurement windows, so honest nodes recover automatically without operator intervention.

The reputation score enters the Router's multi-armed bandit as a multiplicative modifier on the mesh candidate score (see § 2.B routing logic). A node at 90 reputation gets full weight; a node at 50 gets 0.5× weight; a node below 40 is excluded from the candidate set entirely before scoring begins.

The reputation score enters the Router's candidate selection as a multiplicative modifier on the mesh candidate score. Trusted nodes receive full weight; nodes in the probation band are heavily discounted; nodes below the probation threshold are excluded from the candidate set entirely before scoring begins.

  Browser        Coordinator         Peer Node
      │                │                 │
      │──infer(task)──►│                 │
      │                │─dispatch(enc)──►│──infer──┐
      │                │                 │◄────────┘
      │                │◄──result(enc)───│
      │◄──tokens────────│                 │
      │                │─meter_event     │
      │                │                 │
      │                │ (verification:   │
      │                │  a sample of     │
      │                │  compute hash,   │
      │                │  compare,        │
      │                │  penalize        │
      │                │  mismatches)     │

• Dispatch: Coordinator selects peer from registry based on reputation, latency, model availability, and privacy policy. Task encrypted with peer's session key (AES-256-GCM derived from TLS exporter).
• Result: Peer returns encrypted result. Coordinator decrypts, verifies hash (on a sample of tasks), updates reputation, meters usage, streams tokens to client.
• Latency cost: +180ms round-trip to coordinator vs. direct P2P (~50ms on LAN). Offset by better peer selection (reputation router has full signal vs. blind local discovery).

After the initial capability probe, the SDK establishes a persistent WebSocket to the Gateway for token streaming and real-time routing feedback. Failover to REST (request-by-request) occurs if WebSocket unavailable (legacy browsers, firewall blocks).

After the initial capability probe, the SDK establishes a persistent WebSocket to the Gateway for token streaming and real-time routing feedback, with automatic failover to REST (request-by-request) if WebSocket is unavailable. The connection multiplexes concurrent requests and uses keepalive pings to detect dropped connections. On route degradation (peer timeout, cloud error), the capability probe re-runs and a fresh routing decision is fetched. Session identity is derived from the API key and a stable device identifier cached locally. Per-peer session keys are derived from the TLS channel — no persistent key material is stored on the client.

• Keepalive: SDK sends ping; Coordinator pong. 3 missed pongs → reconnect.
• Probe re-run: On route degradation (peer timeout, cloud 5xx), capability probe re-runs and new router decision fetched.
• Session state: API key + device_id (derived from probe) = session identifier. Device_id stays stable across page reloads (IndexedDB cache).
• Encryption: Per-peer session keys derived from TLS exporter (RFC 5705). No persistent key storage on client.

Post-GA, we will explore direct WebRTC dispatch as an opt-in mode for latency-critical workloads (interactive routing latency budget < 50ms).