TITinyBox Network0.5.477-swallowed · 2026-09-17

One agent account, lent to the machines that need it.

A donor machine lends the coding agent it is already signed in to. A consumer machine borrows it and runs that agent in its own terminal, in its own working directory. The relay in between is this project: the thing that matches them, carries the terminal, and keeps the record of what was used.

Download 0.5.477 tinybox-network-0.5.477-swallowed.tar.gz · 48.7 MB · Node.js 20+
includes the relay, its console, and the TinyBox donor/consumer binaries for Linux and Windows
Read the deployment manual →

What it is — and what it deliberately is not

Three things, and nothing else:

AccountsRegister by invitation, sign in, roles and tokens. An account is a donor, a consumer, or both. An administrator approves, edits rights, and issues codes.

Run itOne command installs the consumer or donor on a machine and keeps it up to date. Your own sessions are listed while they run, with the machine, the working directory and the traffic.

NetworkNodes federate over a shared key. A machine reaches the node nearest to it and still finds capacity donated anywhere on the network.

There is no marketplace, no artifact hosting, no net disk, no agent storefront and no chat widget in the corner. It is a console for an operator who wants to know which machines are lending, which are borrowing, and whether any of it is working.

Run one node

tar xzf tinybox-network-0.5.477-swallowed.tar.gz
cd tinybox-network-0.5.477-swallowed
cp config.example.json config.json      # edit domain, port, data dir
cd server && npm ci --omit=dev
AMERC_CONFIG=../config.json AMERC_PORT=5320 \
  AMERC_DATA_DIR=/var/lib/tinybox-network node app.js

Open it, create the first administrator at /setup, and hand out an invitation code. Put a TLS terminator in front of it. The deployment manual has the proxy block, the systemd unit, federation, and what to do when a donor reads BAD.

Add a machine

Sign in, open TinyBox → Donor (or Consumer), and copy the single line it shows. The address carries that account's own token, so nothing has to be typed into the machine — which is what makes it usable over SSH on a box nobody is sitting in front of.

curl -fsSL 'https://<your node>/donor.sh?k=<token>&config=claude' | sh
irm 'https://<your node>/donor.ps1?k=<token>&config=claude' | iex

It installs the package, starts the donor's supervisor — which keeps the binary up to date from the node by itself — and prints the pid, the folder, the log, and how to stop it.

One donor program per agent per machine, per network. Two copies on the same relay replace each other's connection every few seconds, forever: sessions never start and both copies look healthy from the machine itself. The installer refuses to be the second copy, and the console names the fault instead of showing a symptom.

Form a network

Give every node the same federation.serverKey and list them all in federation.peers. Each node then advertises its own donors to the others, and a consumer elects the node that answers it fastest.

Running now

Node	Address	Where
tbx-us	tinybox.chuade.com	United States
tbx-cn	tinybox.lessokaji.com	China

The two are one network: each sees the other's donors, and a consumer that reaches either one can be served by capacity on the other.

Requirements

Relay: Node.js 20 or newer, a TLS terminator, a writable data directory. Three npm dependencies.
Donor machine: the coding agent installed and signed in as its owner. Linux or Windows.
Consumer machine: nothing but the one command. Linux, macOS or Windows.

The relay never holds anyone's provider credentials. A donor lends its own login, in place, on its own machine; a session can refresh it, and a session that signs it out signs it out. That is a trust boundary, not a file permission, and it belongs with who you lend to.