Personal Cloud Quickstart (DOCS-02)

Run yaarbal seeder on your own GPU machine once, and you can chat with it from a second device, a phone or a laptop, even while the GPU sits behind NAT with no port forwarding. Zero marketplace liquidity required.

This takes two identities and two invite codes: the seeder identity on the GPU machine, and a spender identity in the browser on the second device. Invites are self-serve, one code per identity, 25 a day network-wide, and waitlisted in order after that. The split is required because a seeder can never bill itself, so your GPU serves your spender identity like any other peer on the network, and the ordinary network tax applies to those credits.

The desktop earn app exists in the repository but is not shipped in this beta (it is unsigned and has no updater), so the earning node here is the CLI seeder.

1. Install the CLI

Python 3.11 or newer is the only prerequisite. The wheel, the installers and a SHA256SUMS file are on the download page, https://docs.yaarbal.app/dl/. Follow CLI Quickstart section 1 for macOS, Windows or Linux/WSL.

2. Claim your grant and join the network

Create the seeder identity as described in CLI Quickstart section 2, then pull a model (section 3 of the same guide):

yaarbal models pull llama-3.2-1b-instruct-q4_k_m

Now ask for this identity's invite code and redeem it in one command:

yaarbal seeder --request-invite --claim-benchmark --tos-version <version> --tracker-url https://rmg-tracker-oracle.yaarbal.app

It requests the self-serve code for this identity and claims your welcome grant with it. When the day's 25 codes are gone it prints a waitlist position and exits with code 2; re-run it on a later day and the identity keeps its place. If the claim fails, the command prints the tracker's error code as the top-level error key (invite_invalid, invite_already_used), and the web app shows the same two cases as exact messages: "That invite code isn't valid. Check for typos, or ask your inviter for a new one." and "This invite code has already been redeemed by a different identity." Request a fresh code for this identity; a code another identity has redeemed cannot be reused. The two-step alternative is in CLI Quickstart section 4.

Then start serving:

yaarbal seeder --model llama-3.2-1b-instruct-q4_k_m --tracker-url https://rmg-tracker-oracle.yaarbal.app

qwen3.5-9b-q4_k_m (Qwen3.5 9B) is the newest catalog entry and the model the operator's own public node usually serves (best-effort); any catalog model that fits your GPU works. The seeder sends its first signed announce to the tracker, which puts your GPU on the network.

3. Verify you're sharing

The seeder's log shows its announce accepted (no announce.rejected), and https://rmg-tracker-oracle.yaarbal.app/models lists the model you serve. Credits earned show under GET /credits/<peer_id> on the tracker, and later in the web app if you sign in with the seeder identity. Treat that as read-only and never chat from it.

4. Chat from a second device

Your second device gets its own spender identity, separate from the seeder's. Do not sign the browser into the seeder identity; a seeder cannot bill itself, so a chat job submitted under your seeder's own identity is rejected by the tracker and fails outright. The two-identity split is what makes chatting against your own GPU actually work.

1. On your second device, open https://rmg-web.yaarbal.app in any browser. The moment the page loads it generates a private, unclaimed spender identity for that browser. There is nothing to sign into and nothing to import.
2. On the welcome-grant card that appears, press Request an invite (one code per identity; if the day's 25 are gone you get a waitlist position and the code on a following day), then redeem it there (fields: Invite code, the Terms of Service checkbox; button: Claim Your Welcome Credits). This mints a one-time welcome grant of credits onto this browser's spender identity.
3. Pick your model in the chat surface and start typing. Tokens stream back to you over the WAN pull-dispatch relay. This works even though your seeder has no forwarded port, because the tracker relays the stream for you. Your own GPU serves the request like it would for any other peer: the network tax still applies, same as any other spender.

5. Disclosures

• Prompts sent to your own seeder are visible to you, as its owner. This is the same honesty the Terms of Service state from the other direction: the coordinator cannot read prompts routed through the relay, but whoever's GPU actually runs a job can see what was sent to it — including your own seeder, running a job for your own spender identity.
• The network tax applies to your own seeder's earnings too — chatting against your own GPU is not free of the tax the network takes on every settlement.
• Rate limits apply to all requests.
• Credits and access may reset during the beta.
• Terms of Service: https://rmg-web.yaarbal.app/tos

Operator appendix (not the user path)

This section is for the operator provisioning access, not for someone following the quickstart above. Self-serve codes come from POST /invites/request (one per requesting identity, RENTMYGPU_INVITE_SELF_SERVE_PER_DAY = 25 a day, waitlist after). The personal-cloud flow needs two codes because a code is consumed by the first identity that claims it: the seeder identity's code is spent claiming the benchmark grant, so a fresh browser identity redeeming the same code would find it invite_already_used. POST /admin/invites still exists for an operator to mint a code for someone stuck on the waitlist.