Mesh v1EXPERIMENTAL
Mesh connects your T3 Code machines on one T3 Connect account. Agents can work on the other machines. Your phone or browser prefers a route through one of them, called the captain. PR #24863.
Manage it in Settings → Connections → Mesh (mobile: Settings → Environments), or with t3 mesh.
1. How it fits together
Every machine keeps one socket to the relay. The relay knows who is in the mesh and picks the captain.
As captain, it only forwards. Each machine still checks the phone's own sign-in, so the captain gives no extra access. If no captain answers, the phone goes direct to each machine, as today.
2. An agent works on another machine
T3 finds the machine that owns the thread and forwards the call once. It calls that machine directly, not through the captain, so losing the captain never stops agent work. The agent's modes still apply: a plan-mode agent stays in plan mode there.
Tools that start work take machine: t3_thread_launch, delegate_task, t3_project_clone, t3_project_create. Launching work in an existing project needs a checkout of the same repository on the destination machine. t3_thread_search also searches this repository on the other machines. A remote delegate_task wakes the parent with its result, like a local one.
3. How machines get access to each other
The relay checks both machines are yours and signs a short grant. The home server checks the grant and issues the session itself, so the relay never holds one.
A session is renewed on the next use after 30 minutes. Leaving the mesh or changing Connect account ends access.
4. Which machine is captain
A captain must be online, support captain forwarding, and have a ready Connect tunnel.
An eligible pinned machine wins. Otherwise, the current captain stays while eligible. When a new captain is needed, these rules are compared in order:
- Runs as a background service.
- Not on battery or low power.
- Machine kind: server, cloud, Mac mini, Mac Studio, desktop, WSL, unknown, then laptop.
- Longest-running T3 server.
5. How machines reach each other
Preference: LAN, then Tailscale, then the Connect tunnel. All routes are checked at the same time. Preferred routes get a shared 500 ms window to answer. A slower preferred route can lose to one that has already answered as that machine.
6. Limits in v1
| Limit | What it means |
|---|---|
| Off by default | Only accounts on the relay allowlist get a mesh. |
| Connect only | Machines join through one T3 Connect account. |
| Offline machine | Work on it fails with a clear error. Nothing is queued. |
| Sockets | A phone still opens one socket per machine. Most go to the captain. |
| Captain load | Video, previews and uploads pass through it. Heavy streams can share its connection limit. |
| Some traffic stays direct | Sign-in, its renewal, and WebRTC device video go to each machine, as today. |
| Desktop app | Listens locally by default, so others reach it through its tunnel. Turn on Network access for LAN. |
| No handoff | Threads stay on their machine. To use code changes elsewhere, commit and push them, then fetch them there. |
| Not live-tested | The relay object has not run on real Cloudflare, and the Mesh UI has not been used with real machines. |
7. What stays the same
- Outside the allowlist: no persistent mesh sockets or mesh timers.
- Each machine still owns its threads, files and providers.
- Forwarding does not copy other machines' threads or files.