Sisyphus is a decentralized network for useful compute. Independent participants contribute CPU and GPU capacity, and users and AI agents submit computational work to the network. Its planned economic layer uses SISY to coordinate incentives, supply, and demand.

AI makes the network easier to use: describe a problem, and Sisyphus can plan the work, find suitable capacity, coordinate execution, inspect the results, and decide what to compute next.

Provide useful compute → earn SISY
Request compute        → spend SISY

Reason → Compute → Observe → Reason → Compute

The long-term goal is an open network where independent machines—from personal GPUs and homelabs to servers and cloud instances—contribute to shared computation. SISY and the network's economy are intended to reward useful contributions and coordinate access to capacity. The token serves the network; it is not the reason for building it.

Why Sisyphus

Cloud providers sell compute from infrastructure they control. Sisyphus aims to coordinate compute supplied by many independent participants across an open network. Providers can put otherwise idle hardware to work, while users can access capacity contributed by the network.

The AI orchestration layer turns a high-level request into work the network can execute. For example, a user might ask Sisyphus to screen 100,000 molecular candidates. Sisyphus could inspect available resources, plan and schedule the computation, collect results, and propose a more expensive follow-up run for promising candidates.

The network should support direct requests from users and AI agents. The AI is an important interface and coordinator, while the underlying compute network remains useful to other clients and tools too.

Proof of Useful Work

Sisyphus is working toward Proof of Useful Work (PoUW): providers are rewarded for useful computational work whose results can be validated, rather than for computation performed only to secure a ledger.

Work request
    ↓
Provider runs the workload
    ↓
Result is checked
    ↓
Provider receives a reward

Useful workloads may include scientific simulations, model inference, rendering, optimization, and data processing. Measuring runtime alone is not enough to prove useful work. A permissionless network will need verification methods suited to each workload, such as reproducible execution, result comparison, or replicated computation, along with reputation and dispute mechanisms.

PoUW is a long-term protocol goal, not a solved feature of the first version. V0 uses trusted machines and does not issue token rewards.

The compute economy

SISY is intended to connect compute supply and demand:

Users / agents ── request and pay for compute ──▶ Network
Providers      ◀── useful work and SISY rewards ─ Network

The token should have utility within the network, including paying for jobs and compensating providers. Supply, emissions, founder and contributor allocations, vesting, and governance need transparent rules. Early founders and contributors can help bootstrap the network by building it and providing its first compute, under rules that are visible and defined in advance.

Token design, trading, settlement, and governance are future protocol work. V0 has no token, blockchain, or open public network; it first tests whether independent machines can reliably contribute to one useful computation.

Architecture

Each participating computer runs one sisyphusd daemon. It discovers local hardware, manages workloads and resources, communicates with other nodes, and stores that node's local state. The same binary can run different capabilities: a machine may act as coordinator and worker, while a headless server may act only as a worker.

Web / Electron / agent clients
              │
       Sisyphus protocol
              │
       Coordinator node
       ├── local worker
       ├── remote worker
       └── remote worker

The coordinator plans and assigns work, tracks job state, handles retries, and aggregates results. Workers execute workloads using the resources their owners make available. These are roles inside sisyphusd, not necessarily separate services.

User-managed compute pools

Power users can group machines they control into a private compute pool. One sisyphusd runs the coordinator role and connects to the pool's other daemons as workers. The coordinator schedules work based on each node's capabilities, availability, and the workload's requirements.

Private compute pool
├── Coordinator + worker (`sisyphusd`)
├── GPU worker (`sisyphusd`)
└── CPU worker (`sisyphusd`)

Pools support two scheduling modes:

Distributed mode: split a workload into tasks and run them across multiple workers.
Full-worker mode: send the whole workload to one selected worker and let it use the resources allocated on that machine. The workload may still use multiple CPU cores or GPUs within that worker.

Full-worker mode suits workloads that cannot be split safely, need one machine's memory or attached data, or already parallelize internally. The worker owner controls resource limits and execution policy.

Web and desktop clients

The UI is a client, not a compute runtime. The daemon owns hardware access, workload execution, jobs, results, and node-local state.

Sisyphus desktop: the Electron + React client connects to the local sisyphusd over gRPC. The Electron main process owns the gRPC connection and exposes a narrow, isolated bridge to the renderer. The first screen visualizes node identity, daemon connectivity, and live peer state.
Public Web UI: can show public network information without requiring a personal node.
Web UI with a linked node: can control the user's personal node over a direct connection when possible, with a relay as fallback.

Chats, model settings, and jobs belong to the relevant personal node. The Web UI presents and controls that state when connected; public visitors do not gain access to private node data.

For daemon-specific implementation and development details—including networking, storage, AI provider configuration, and run instructions—see apps/sisyphusd/README.md.

Workload portability and managed runtimes are longer-term goals. V0 uses a fixed environment across a small number of trusted machines; a universal runtime is not a prerequisite for proving the basic network loop.

V0: prove the loop

The first milestone is a working computation coordinated across two or three trusted machines:

User describes a problem
        ↓
AI creates a plan
        ↓
Coordinator schedules tasks
        ↓
Trusted nodes execute the work
        ↓
Results return and are aggregated
        ↓
AI observes results and chooses what to do next

V0 includes:

One coordinator role inside sisyphusd, with worker capability on the same or other nodes.
Private pools of a few trusted machines.
Distributed and full-worker scheduling modes.
A fixed environment and a small set of known workloads.
Job state, progress, logs, retries, result collection, and AI streaming.
Node-local model configuration, secure credential storage, and initial Ollama/OpenAI adapters.
Local persistence for chats, jobs, and node state.

V0 deliberately excludes:

Blockchain, SISY token, trading, and settlement.
Public permissionless workers and decentralized discovery.
Trustless result verification and PoUW rewards.
A universal runtime for arbitrary workloads.
IPFS, quantum workloads, and a large decentralized protocol stack.

Trying it

You need Go 1.27 or newer. Everything here runs on one machine.

Using Sisyphus is a walk through it with pictures: the desktop app, asking the planner a question, running jobs, storing files and adding a second machine.

The one-minute version. Starts three nodes, runs a few jobs across them and shuts them down:

make demo

A pool to play with. With tmux, in one terminal:

examples/tmux-pool.sh

That starts a coordinator and two workers in the left pane and gives you a shell in the right pane that is already pointed at them. Without tmux, run examples/local-pool.sh in one terminal, and in a second paste the export line it prints. Then:

examples/primes.sh                # the same job split across the pool, then on one worker
examples/wordcount.sh             # store a file, count its words across the pool
examples/wordcount.sh my.txt 20   # your own file, the top 20 words
examples/private-wordcount.sh     # the same, with the data sealed from the rest of the pool

A primes run looks like this, here on one 32-core machine with two workers of four task slots each:

counting the primes below 2000000000
  split into 8 tasks     1.307816647s     {"count":98222287}
  as a single task       9.163948934s     {"count":98222287}

With IPFS. If the ipfs program (Kubo) is installed, examples/local-pool.sh --kubo gives every node a Kubo daemon and the pool a private IPFS network of its own. Anything stored is then an ordinary IPFS file:

IPFS_PATH=sisyphus-pool/alpha/ipfs ipfs cat <a CID that wordcount.sh printed>

By hand. What the scripts do, a command at a time:

make build
bin/sisyphusd run --name alpha                      # a coordinator that is also a worker
bin/sisyphusd pool invite                           # prints an invitation for one worker
bin/sisyphusd run --role worker --coordinator 127.0.0.1:7700 --join <invitation> \
    --name beta --data-dir ~/.sisyphus-beta
bin/sisyphusd nodes
bin/sisyphusd job submit --params '{"from":0,"to":3000000000}'

On more than one machine. docs/multi-machine-test.md is a step-by-step test of a pool across two or three machines, including what to break and what should happen when you do. Nobody has run it yet; if you do, the results belong on #18.

Repository layout

sisyphus/
├── apps/
│   ├── sisyphusd/        # the node daemon and command-line client, in Go:
│   │                     #   coordinator, worker, storage, security, node API
│   └── sisyphus/         # Sisyphus Electron + React desktop client
├── packages/
│   ├── protocol/         # Go code generated from proto/
│   ├── identity/         # node key pairs and IDs
│   ├── job-model/        # job and task state machines
│   ├── kubo/             # running and calling a Kubo (IPFS) daemon
│   ├── ipfscluster/      # running and calling an IPFS Cluster peer beside it
│   ├── names/            # the signed records behind names (IPNS)
│   ├── runtime/          # the Workload interface and built-in workloads
│   ├── sealed/           # encryption of a private job's blobs
│   ├── storage/          # content-addressed blob store, pins, garbage collection
│   └── planner/          # planning interfaces and schemas (not started)
├── proto/                # versioned Protocol Buffer API definitions
├── examples/             # sample input and scripts to run against a pool
├── scripts/              # demo, release build, coverage check
├── docs/                 # developer guide; security model; multi-machine test guide
└── README.md

This is one product and one repository: Sisyphus is the product and desktop app; sisyphusd is the headless node daemon. Clients use the daemon's protocol to observe and control nodes. Daemon guidance lives in apps/sisyphusd/README.md, and desktop development details in apps/sisyphus/README.md.

One daemon, in Go. apps/sisyphusd is the node: the job loop, storage, security, IPFS, discovery and the local API the desktop client uses. An earlier daemon in Rust, which the desktop client was first built on, was retired once the Go daemon did everything it did (#90); a node that ran it carries its key, address book and trusted peers over on first start.

Start the development environment from the repository root:

nix develop
make build
bin/sisyphusd run --api-listen 127.0.0.1:50051

The development shell includes Go, gopls, Delve, lint tools, Protocol Buffer generators, Kubo and Node.js for Electron. Go selects the compiler version required by go.mod automatically. The local API listens on loopback for the Electron client; pool connections use the separate --listen address.

Project status

Sisyphus is an early prototype. The network loop works without AI: a coordinator splits a job, workers on other nodes run the tasks, and the results are combined. It has run across physically separate machines on a home network, a Linux server and a Windows laptop with a graphics card, splitting a job between them and serving a language model from the card (#18, #87).

Working today, in sisyphusd, written in Go:

One binary that runs as coordinator, worker or both, with a command-line client.
Distributed and full-worker scheduling, with tasks retried when a worker fails or disconnects.
Content-addressed storage for job data. Files are named by the same CID that ipfs add --cid-version=1 gives them. Nodes never join the public IPFS network.
Jobs that pass large inputs and outputs by CID; workers fetch them from the coordinator or from each other, verify and cache them.
Pins, retention periods, garbage collection and disk limits, so a node keeps data only as long as something needs it.
Optionally, a Kubo (IPFS) daemon run beside each node, as the same peer as the node. A pool's daemons form a private IPFS network that only its members can join, and workers fetch job data over it from whichever member has it.
Optionally again, an IPFS Cluster peer beside each Kubo. Whatever the coordinator pins is then held by several of the pool's nodes, and moved to another when one of them goes. Only the coordinator can change what is pinned.
Or the store kept in an S3-compatible bucket in place of a directory.
Copies on other nodes without Kubo: storage followers each hold what the coordinator has pinned, and a coordinator that loses its disk and keeps its key takes its data back from them by itself, on the strength of lists it signed.
The IPFS Pinning Service API, served by a node and used by one, and a read-only HTTP gateway for what a node stores.
Names for what changes: a node's ID stands for whichever stored file the node last pointed it at, in a signed IPNS record that a coordinator keeps for itself and its members and that anyone can check.
One open port per pool, on the coordinator. Workers connect outwards only, so they run behind home routers and firewalls as they are. Every node is a libp2p host under its own ID; the coordinator relays between workers that cannot reach each other, as does any worker that opens a port for it, and those that can connect directly do.
Private jobs, whose inputs, intermediate data and results are sealed with a key held only by the submitter and the nodes working on the job.
Encrypted connections between nodes, each identified by its own key; nodes join a pool by invitation, as a worker or a client, and can be removed.
Nodes that find each other: on one network by multicast DNS, beyond it through a distributed hash table, and from an address book. A node can be trusted for compute straight from the list of those found, or admitted by invitation, Trust has two sides, giving a node work and taking its work, and work starts between two nodes wherever one gives and the other takes, without either being restarted.
Jobs kept in a SQLite database, so a coordinator that is restarted takes up its unfinished jobs where they were. A task that fails on a worker is tried next on another.
A planner: ask a node a question in plain words, and a language model (from Ollama, Anthropic, OpenAI or anything that speaks as OpenAI does) decides what to compute, has the pool compute it, and answers from the result.
Thinking on the pool: workers with Ollama offer their models, and the coordinator offers them all as one OpenAI-style service, which the planner or any agent can use. Replies are spread across the workers serving a model, nearest a graphics card first, and each worker shows which models it has loaded and how much of each is on its card. A worker's owner chooses which models the pool may use and how they may use the machine: how much of a model goes on the card, threads, context, how long it stays loaded.
An MCP server and an agent skill: sisyphusd mcp offers the pool to any AI agent that speaks the Model Context Protocol, and skills/sisyphus teaches one to use it.
Jobs that can be followed as they run, with progress, logs and a record of what happened to them, and cancelled or given a time limit.
A finished job's record: its history as linked data under one CID, which anyone can check against the job. A private job's record commits to its results without naming them.
Jobs made of steps, each a job of its own that can use the results of those before it.
Opt-in verification by replication: a job can ask that each of its tasks be run by several different workers and take a result only when they agree. A worker that returns something else is outvoted and named. It is for deterministic work, and does not stop workers that agree to lie. With spot checks only a share of the tasks, picked at random, is verified, and a worker that is caught has its other tasks in the job verified after all. A coordinator can count workers at one address as one, and can check a share of any job's tasks by running them again itself, which needs no second worker.
The node's local API over Connect and gRPC-Web as well as gRPC, so that a page in a browser can use it.
The desktop app's interface served by a node to a browser, which is paired with the node once by a one-time code and can be revoked device by device.
Several named model providers kept by a node, each with its own key, which never leaves the node.
A desktop app that shows a node and its pool, plans with it and admits or removes workers, packaged with the logo as a Windows installer, a macOS disk image and a Linux AppImage.
A first real workload, transcode: a video is cut into stretches, encoded by ffmpeg on different workers, and joined.
Container images as jobs: a worker whose owner allows it runs any image, one copy for each task, with its output stored and its log followed live.
Two stand-in workloads, primes and wordcount, that exercise the network rather than compute anything valuable.
Tests that execute every statement of hand-written code, enforced in CI, and release builds of the node for Linux, macOS, Windows, the BSDs and Android, beside the desktop app's packages.

Not built yet: more real workloads than the first (transcode). Unless a job asks for its tasks to be run by several workers and compared, a coordinator accepts whatever result a worker returns; and that comparison is the first step only (#19): it works for deterministic jobs that are not private, believes workers that agree, and costs a worker that is caught lying nothing but a probation, during which jobs that verify only some of their tasks verify all of its. So a pool is still only as trustworthy as the workers admitted to it. There is no blockchain, token or public network.

Try it with make demo, or see Trying it below. apps/sisyphusd/README.md is the full guide to running nodes, and docs/development.md covers building, testing and contributing. docs/security-model.md says what is protected today, what is not, and whom each party has to trust. The plan, in order, is in the roadmap issue. What is still being thought through, the chain, the token, verification beyond what is built, and paid storage, is in docs/research: surveys and proposals, not decisions.

Two things in this section go beyond what the sections above describe and are still open for discussion: the choice of Go (#1), and building storage on IPFS formats while V0 lists IPFS as out of scope (#25).

Community

Discussions: questions, ideas, and what you have run on a pool.
Issues: bugs and planned work. The board shows what is in progress.
Contributing, the code of conduct, and reporting a vulnerability.

License

Sisyphus is licensed under the Apache License, Version 2.0. Contributions are accepted under the same license.