Turbo Link

Point one TurboLLM at another and the second machine's models show up in the first one's model picker, tagged with the machine they live on. You pick one, chat normally, and the generation happens over there — on its GPU, its VRAM, its engine.

What it's for

The common shape is a workstation with a real GPU and a laptop without one. Run TurboLLM on both, link the laptop to the workstation, and the laptop gets the workstation's 70B as an ordinary entry in its own model list — no SSH, no port-forwarding, no second UI. The same works for a home server, or for a rented cloud box that only exists for an afternoon (see Running the host in the cloud below).

Both ends must be running TurboLLM. That's the only requirement — Turbo Link connects TurboLLM to TurboLLM, not TurboLLM to an arbitrary inference server.

Vocabulary

• Host — the machine that owns the GPU and does the work. It hands out link strings and can revoke them.
• Peer — the machine you're sitting at, borrowing the host's models.

A link is one-way. If you want each machine to be able to use the other's models, link it in both directions — that's two links, each with its own grant.

Linking two machines

On the host — Settings → Turbo Link:

1. Give the machine a name (the field defaults to its hostname). This name is what prefixes its models on the peer, so make it something you'll recognise: workstation, server, kaggle-t4.
2. Choose what the link is allowed to do:
   • Inference only — use models to generate, nothing else.
   • Server box — use, wake, load, and unload models.
   • Full control — everything above, plus downloading models onto this machine and changing its settings.
   • Customize — the raw capability checkboxes, if none of the three fit.
3. Optionally restrict it to specific models. Blank means every local model.
4. Mint it. You get a link string starting tllink_, shown once. Copy it then — the host only stores a hash, so it cannot show it to you again.

On the peer — Settings → Turbo Link → paste the link string. That's it. The peer handshakes, learns the host's name, models and granted capabilities, and the host's models start appearing in your lists.

What actually federates

• The chat model picker, showing remote models with the machine they're on.
• Your OpenAI/Anthropic-compatible API — remote models appear in /v1/models and can be named in a request.
• turbollm launch — --model takes a remote id, so you can point Claude Code at another machine's GPU.
• Code sessions — a Code session can generate on a linked machine, and the choice survives leaving the screen.
• Models, Downloads and Engines merge both machines' rows into one list. Engine rows from a host are read-only — see below.

Remote models carry a machine-prefixed id — workstation/Qwen3-35B. Your local model ids are untouched, so nothing you already scripted changes.

Live stats are first-class, not approximated: tokens/sec, time-to-first-token, prefill percentage and the context meter all render on the peer, reported by the host that's doing the work. For the same reason, a federated generation is attributed to the host in stats — the machine that actually burned the GPU time.

What a link can't do

• Engine management is never grantable. Adding or scanning an engine runs a binary path the caller supplies, so no remote caller gets it — with any token, under any preset. Remote Engines rows are visible and never actionable.
• Links don't chain. A peer sees the host's own local models, never models the host is itself borrowing from a third machine.
• Waking a busy host doesn't happen. Auto-swapping a cold model is a capability you grant, and even then it only applies while the host is idle. If someone is using the host locally, the peer is told "in use locally" rather than yanking the model out from under them.

Security model

Possession of the link string is the entire gate. There's no IP allowlist and no pairing approval — over a tunnel every request arrives from localhost anyway, so an address list would prove nothing. Treat a tllink_ string like a password.

The link endpoint always demands a valid link token. It exempts nothing — not loopback, not "require API key" being switched off, not a full-access key from elsewhere in the app. It fails closed and is independent of your other network settings, so opening LAN access for convenience can't accidentally hand a peer the run of your machine.

Revoke from the host, in the same panel, at any time. The peer notices on its next poll. Capabilities are re-reported on every poll too, so if you narrow a grant, the peer's controls tighten within seconds rather than lying until it reconnects.

One thing worth knowing: the peer stores the link string on disk in order to reconnect. Keep the grant as small as the job needs — Inference only is the right default, and Full control genuinely means the other machine can download multi-gigabyte files onto this one and change its settings.

Running the host in the cloud (Kaggle + Turbo Link)

A host doesn't have to be a machine you own. Kaggle gives every free account two Tesla T4s — about 30 GB of pooled VRAM — and TurboLLM runs there from a one-click notebook with a public URL. Make that box the host and your laptop the peer, and you're running a model your own hardware can't hold, from your normal local UI, for free.

The shape of it:

1. Bring up TurboLLM on Kaggle and note its public URL and token — How to use TurboLLM with Kaggle walks through the whole thing.
2. On the Kaggle box, turn on Settings → Experimental → Turbo Link, name the machine, and mint an Inference only link.
3. On your laptop, turn the same flag on and paste the link string.
4. The Kaggle T4s' models now appear in your local picker, prefixed with the name you gave.

Getting started

Run that on both machines, then Settings → Experimental → Turbo Link on each. If you're new to TurboLLM, start with Install & first run and Load your first model instead.