TetherNexus

How it works

It starts with a request, not an address.

Four steps run for every job. Each one is bounded, and each one can decline. A decline is an answer: the job stays where it is and says why.

The four steps

  1. Announce

    Each machine reports what it can do right now: free cores, memory, GPU, the tools it has installed, and how fast the link to it is. A capability it cannot back with a measurement is reported as unknown, never as a guess.

  2. Ask

    A request names a capability, not a host: a GPU with enough memory, ffmpeg, the fastest free cores. The resolver answers with candidates and a reason for each score.

  3. Plan

    The planner prices every path — run here, ship the whole input, ship only the delta, move the computation, or pre-position state — and picks the cheapest one that can be completed. When it cannot price a path, that path is out.

  4. Run and seal

    The job runs, the result is compared against what the plan expected, and a receipt is written with the wall time, the machine, and a digest of the output. Any doubt at any step falls back to local execution.

In this wave

Five decisions, printed by name.

The Nexus planner does not describe its choice in prose. It writes one of five names into the plan, so a later reader can see what it decided and check whether that was right.

local

Run here. The planner declined every outbound path, usually because the fixed cost of starting a job elsewhere is larger than the job.

ship_full

Send the whole input and run there. Chosen when compute saved beats the bytes moved, with both costs measured rather than assumed.

ship_delta

Send only what changed. Chosen when the target already holds a prior version, so the transfer is a fraction of the input.

move_compute

Do not move the data at all. The job goes to the machine that already holds it, and only the result comes back.

prestage

Move state before the job exists, at a moment when the link is cheap. Chosen only when a session pattern makes the next job predictable.

Receipted, either way

Every one of the five ends the same way: one receipt naming the decision that was taken, so the choice can be audited after the fact.

What was measured

The numbers, with the runs that did not help.

All figures below are read from the repository's own measurement files. Rounded to the precision shown; the source line under the table names each file.

Paired runs, local-only against one donor. Identical outputs were required.
Run Local only With a donor Result
One job, split 27.16 s 21.15 s 1.28× faster
A machine already saturated 309.65 s 108.29 s 2.86× faster
A quiet machine 46.93 s 92.2 s 1.96× slower — stayed local
Qualification, p95 45.20 s 18.62 s qualified, outputs exact
Product path, one donor 4.523 s 1.911 s identical output

Sources: web/landing/replay.json, web/landing/measured-not-claimed.json, evidence/w1/mac-studio-2-qualify/20261010T2038Z/qualify.json, web/landing/pull-split-product-path.json.

The saturated and quiet rows ran on a contended Mac; the numbers describe those machines on those days, not a clean benchmark.

The rules that decide

Four constants, each read from code.

150 load ceiling

A machine whose one-minute load is above this is not asked to take work. The same guard protects the machine you are typing on.

2.0 load span

If the load rose by more than this while a job ran, the win is recorded without a headline. A measurement that measures its own load is printed as a measurement, not a promise.

3 sync samples

Fewer than this many measured sync-ups and the peer is treated as unmeasured. The plan then falls back rather than guessing a transfer rate.

6.0 seconds of fixed cost

Sending a stage to a donor costs this much before the first unit runs — raised from 4.0 after every measured push of the real 24.71 MB stage took longer. A higher fixed cost makes the planner decline more small jobs, not fewer.

Refusals

What it will not do.

A refusal is a first-class outcome. It carries the reason and the command that would change it.

  • It will not treat a stale receipt as a live one. A capacity receipt that has lapsed is history. It still explains what happened; it authorizes nothing.
  • It will not send work to a peer measured slower. A peer whose own measurement loses to the local prediction is refused before a job is sent, not after a slow run.
  • It will not guess a number. Unknown capacity prints as unknown, never as zero and never as a figure from another machine.
  • It will not run at all when a path is unproven. If a path cannot be priced, it is removed from the plan. The job then runs locally, and the plan says that is what it decided.

Where this is

What works today, and what this wave adds.

Today, in the code. Pairing over SSH, the capacity pool, qualification, split runs, receipts, the MCP surface, and local fallback on any doubt. The docs page prints the commands that exist.

In this wave. Capability records, the five-decision planner, the console, and the public site you are reading. These are being built now; the changelog says which commits landed.

Nothing on this page claims that a wave feature is shipped. When one lands, it lands with a test and a changelog line.

Read the commands, then try one job.

The docs page has the install, pairing and MCP commands, each one copied from the code that implements it.

Open the docs What is signed