[RFC]: Opt-in LAN compute mesh for T3 Code — use spare devices as bounded workers #17822

Before submitting

• Searched existing T3 Code issues and discussions for mesh/distributed-compute proposals.
• This is a concrete use case with a small testable first slice, not a request to make every device a full T3 environment.

Area

Server/orchestration V2 and remote environments; ideally an optional external compute bridge rather than a new mandatory T3 execution subsystem.

Problem or use case

I want T3 Code to coordinate useful work across hardware I already own: a GPU desktop, older PCs/laptops, NAS or small Linux boards, Android phones, Android TV boxes/smart TVs, and (where legitimately supported) console browsers. Buying more compute shouldn't be the only way to speed up AI-assisted development.

Examples: run independent test/build shards on spare PCs, batch deterministic file/image transforms on lightweight devices, or route small-model inference to an explicitly approved GPU host. T3 should show which devices were actually eligible, what work ran, and whether the outputs were verified.

Important distinction: this is not a request to migrate a live T3 thread, share a filesystem/database between machines, or turn a console into an unrestricted development host. It is an opt-in resource/compute layer beneath an existing T3-owned workflow. Some devices will never be eligible.

Fit with T3's existing architecture

T3's architecture keeps provider execution, Git, files and durable orchestration state in the owning environment; its remote design connects clients to environments, not environments into one shared runtime. Orchestrator V2 commits intent/effects durably.

I'd preserve those invariants:

• The owning T3 environment retains its thread, repo, provider sessions, credentials, approvals and event log.
• An optional mesh bridge/sidecar discovers authorized worker nodes, reports capabilities, picks eligible work, manages leases and transport, and returns evidence.
• Workers pull bounded jobs and can never directly mutate the owning thread's lifecycle or declare its work complete.
• The owner verifies outputs and records the result through its normal orchestration path. No distributed SQLite or shared writable checkout.
• No new behavior or background load when the feature is disabled. Clients remain control/visibility surfaces, not implicit worker nodes.

Proposed flow:

T3 thread / operator intent (sole workflow authority)
  → typed, approved compute requirement
  → optional mesh policy + capability registry
  → eligible paired node pulls a time-limited job
  → sandboxed adapter executes with resource limits
  → output hashes + logs + resource receipt return
  → owning environment verifies and records outcome

A generic mesh.submit/MCP-style boundary is illustrative, not a request to bless a specific core API yet.

Device tiers: capability-based, not marketing-based

Not every TV NPU is exposed to third-party apps. Retail consoles typically prohibit arbitrary native/background compute, and their browsers may lack or restrict needed APIs. Discover and measure actual capability; never advertise unusable GPU/NPU capacity, bypass device restrictions, or silently enroll devices. Browser nodes are ephemeral/untrusted and should only receive small public/non-secret deterministic work.

This won't pool heterogeneous devices into one magical GPU or speed up a single non-parallelizable LLM call. It targets workloads that can genuinely benefit from sharding/placement after transfer overhead.

Smallest useful scope (P0)

An out-of-tree proof of concept, using existing T3 server boundaries wherever possible:

1. Two ordinary computers over LAN/Tailscale. Register one explicitly paired, trusted full worker with CPU/memory/runtime limits.
2. One typed job adapter, e.g. deterministic test shard in a rootless container, scoped to immutable inputs/artifact digests (no arbitrary remote shell strings).
3. Pull/lease/cancel/retry, including disconnect/restart handling. No result accepted twice or from an expired/revoked lease.
4. Evidence: a bounded execution receipt with job ID, input/output digests, exit status, timing, and verifier decision; owner accepts only verified results.
5. Minimal visibility: online/paused node and job states, placement reason, failures, energy/thermal limits where available. Avoid high-volume websocket updates.

Acceptance test: a T3-owned task dispatches one isolated test shard to a second approved computer; the origin verifies the result and records it. Lost worker, replay, cancellation and restart tests pass. Existing single-environment work and app performance are unchanged with mesh disabled.

Only after that: portable WASI jobs, Android charging/Wi-Fi/thermal policy, browser workers, and an empirical TV/console compatibility matrix.

Consent and security non-negotiables

• Manual opt-in per device, clear pause/leave/revoke and quiet-hour/power/network ceilings. No background use just because someone opened a T3 client.
• Local LAN/private tailnet by default, authenticated pairing; no automatic public exposure.
• Expiring, scoped job grants and signed or authenticated results; fail closed on stale/forged/replayed receipts.
• No secrets, Git credentials, writable repositories, arbitrary commands or privileged filesystem access on untrusted workers.
• Container/WASI capability restrictions on trusted hosts; bounded CPU, RAM, runtime, bandwidth and thermal use.
• Placement checks data classification, input locality, transfer overhead and current interactive pressure; transparent provenance and opt-out.

Related work and provenance

• Hermes Mesh RFC — prior proposal for a household edge-compute fabric, with device tiers, receipts and authority separation. This idea also traces back to the community distributed self-development proposal.
• T3 discussion #6935 by ThinkSalat, with helpful concrete cross-environment observations from TechFeatured, rabesss and others; PR #15904 explores launching threads on other environments. Adjacent but distinct: those deal with agent/thread delegation; this proposal concerns execution of small typed compute jobs on heterogeneous non-agent devices.
• #14793 proposes an external cloud-environment provisioning broker; different purpose and lifecycle.
• Prior art worth evaluating rather than reinventing: BOINC (opt-in device/power policies), wasmCloud, WasmEdge, wasimoff (portable/browsers).

Maintainer design question

Would a community-maintained sidecar + narrow, optional T3 job/receipt integration be an acceptable extension boundary, or would maintainers prefer this stay entirely external (e.g. an agent-configured MCP server)? I'm happy to keep the first implementation outside core and return with measured latency, verifier/failure tests, and a hardware compatibility matrix before suggesting a native UI.

The aspiration is to make spare household hardware useful to coding agents without compromising T3's minimalism, environment ownership, performance, or consent model.