A cooperative hive, not shared GPU memory

One pool can include phones, Windows, macOS, Linux and a Slurm gateway. Devices claim compatible independent tasks. This does not split a model across phones, turn macOS/Windows into native Slurm hosts, or supply distributed model training.

flowchart TD
    Human[Coordinator] --> Broker[Broker API]
    Oracle[Optional LLM recommendation] --> Validate[Schema and allowlist validation]
    Validate --> Approval[Dry run or explicit --apply]
    Approval --> Broker
    Broker <--> DB[(SQLite jobs and audit)]
    Broker <-->|Leased tasks and results| Browser[Android / iOS browser]
    Broker <-->|Leased tasks and results| Desktop[Windows / macOS / Linux worker]
    Desktop --> Inference[vLLM / SGLang endpoint]
    Broker <-->|Approved training profiles| Gateway[Linux Slurm gateway]
    Gateway --> Slurm[Existing Slurm controller]
    Slurm --> CPU[Linux CPU nodes]
    Slurm --> GPU[Linux GPU nodes with configured GRES]

The optional oracle proposes exactly one bounded task per command invocation. It cannot alter Slurm, run shell tools, enroll devices or choose arbitrary scripts. The default is a printed proposal; --apply explicitly authorizes submission. This is not an autonomous agent takeover or a safety-certified policy engine.

open-compute oracle --oracle-url http://127.0.0.1:8000 \
  --oracle-model coordinator-model \
  --goal 'Propose a small CPU demonstration'
# Add --apply to authorize submission of this one validated proposal.

Use --allow-model gemma to permit a served chat model or --allow-profile smoke to permit an installed training profile. Oracle training parameters must remain empty; administrator-installed profiles own their resource and time limits. Set OPEN_COMPUTE_ORACLE_KEY only if the configured endpoint needs authentication. Only the goal, allowed names, worker count and job kinds/states go to that endpoint; do not put confidential content in the goal. Local validation rejects unsupported task kinds, excessive budgets and unapproved models/profiles even if the LLM asks.

Recovery state machine

stateDiagram-v2
    [*] --> Queued
    Queued --> Running: compatible atomic claim
    Running --> Running: confirmed heartbeat
    Running --> Queued: lease expires / attempts remain
    Running --> Failed: expires after third claim
    Running --> Outbox: computation finishes / save locally
    Outbox --> Outbox: transport failure / retry
    Outbox --> Completed: broker accepts current lease
    Completed --> Completed: identical retry / no extra credit
    Outbox --> Rejected: lease expired or cancelled
    Queued --> Cancelled: administrator
    Running --> Cancelled: administrator

Outbox is worker-side state; until acceptance the broker still records Running. Expiry is processed on the next claim. See durability for limits.