Remote orchestrators switcher: browse other machines' instances from one UI (version-skew-proof)

[web3dev1337]

Problem

With orchestrators running on multiple machines (laptop + PC, each controlling its own terminals), switching between them means juggling browser tabs with IPs. A natural extension of the workspace-tabs idea is tabs that point at different orchestrators — but naively pointing the loaded client at a remote backend breaks whenever the two machines run different code versions (client/server API skew).

Version-skew-proof approach

Never mix one instance's client with another instance's server. Instead:

• Add a Remotes registry (user setting: name + base URL, e.g. PC — http://192.168.0.20:2080).
• Each remote opens as that instance's own client: simplest = open in a new browser tab; richer = render in an iframe inside a workspace-tab-like chrome, so it feels native. Either way every instance serves its own matching client, so versions can differ freely.
• Optional later: a small read-only status strip (ping /api/agents or a lightweight health endpoint per remote) showing which remotes are up before switching.

Non-goal (for now)

True federation (one client multiplexing sessions from multiple backends). Possible, but requires versioned APIs and per-connection socket namespaces — not worth it while the iframe/link approach gives 90% of the value with zero skew risk.

[commandoperator]

The “never mix one instance’s client with another instance’s server” boundary is the right default. I would add one small contract to the Remotes registry: make the remote identity and capability/version handshake first-class, rather than treating the base URL as the identity.

For example, a remote entry could expose:

• stable remote_id and instance_epoch;
• client/API/protocol versions plus a capability hash;
• workspace/session summaries and a health/last-seen timestamp;
• a redirect or deep-link that preserves the remote_id and selected task, not just the current browser path.

That keeps the iframe/new-tab approach version-skew-proof while leaving a clean path to later federation. It also avoids a subtle failure mode: a machine can be reachable and return HTTP 200 while the selected task has moved, the daemon has restarted, or the client is talking to a stale instance. A status strip should distinguish “reachable” from “task/session resumable.”

I build cmdop, so I am biased — we work on the machine/contact side of this boundary. Stable machine identity, lease/epoch, and a separate event stream are the primitives I would want before adding cross-remote task switching.