What you need
- An Allternit plan with a cloud computer, paired to your account. It shows up as a runtime in Settings → Computers.
- A vendor account connected with Browser sign-in (see Vendor bots). API-key accounts do not use a browser and cannot move.
Move an account to the cloud computer
Each account has one host:this_device (the computer running Allternit, today’s behaviour) or cloud_computer. Moving the host never copies your sign-in. A session is tied to the machine that made it, and Allternit does not copy cookies between machines. After a move the account shows Needs sign-in and its bots wait until you sign in on the new host.
- Choose the cloud computer as the account’s host (
POST /api/v1/gateway/provider-accounts/:id/host, below). - Start the sign-in. Allternit opens the vendor’s login page in the cloud computer’s browser and returns its viewer.
- In the viewer, sign in to the vendor yourself, including any code or bot check. Allternit never sees your password and never completes a check for you.
- Check the session. When the vendor reports it ready, the account becomes Connected and its bots resume.
While it runs
- Status:
GET /api/v1/gateway/provider-accounts/:idincludes ahostblock withkind,runtimeId,online,lastSeen,needsSignInandwakeable.online: falsewithwakeable: truemeans the computer is asleep and will wake on the next message. - Needs sign-in: if the vendor signs you out, the account moves to Expired and its bots show Needs sign-in. Sign in again from step 2.
- A vendor check or restriction (a bot check, a limited account) is never worked around. The account stays blocked until you resolve it in the viewer.
- Vendor terms still apply. Running a subscription in a browser can conflict with a vendor’s terms, exactly as it can on your own computer. See the disclosure in Vendor bots.
For developers
Everything lives incmd/allternit-api/src/gateway_vendor_host.rs (runtime side, migration V221__vendor_account_host.sql). The cloud API needs no change: it already relays to a runtime and wakes a sleeping cloud computer.
Data
provider_account_bindings gains host_kind (this_device | cloud_computer), host_runtime_id, host_state (ready | needs_sign_in | signing_in), host_remote_account_id, host_last_seen_at, host_changed_at. They surface camelCase on every account (hostKind, hostRuntimeId, hostState, …).
Dispatch
HostRoutedTransport wraps the runner’s AaiTransport (outside the channel-lane and subscription transports). For a binding whose account has host_kind = cloud_computer it relays the call to the cloud computer’s gateway:
503 runtime_warming → retryable GATEWAY_UNAVAILABLE with retryAfterMs, 503 runtime_offline → retryable GATEWAY_OFFLINE. If host_state is not ready the call fails with AUTH_REQUIRED and never reaches (or wakes) the computer. Every other account passes straight through, and a runtime started with ALLTERNIT_PROVISIONED=1 (the cloud computer itself) always runs locally. The cloud call uses the caller’s own bearer when there is one, else ALLTERNIT_CLOUD_API_TOKEN; the base URL is ALLTERNIT_CLOUD_API_URL (default https://api.allternit.com).
Routes (under /api/v1/gateway)
Moving host sets
host_state = needs_sign_in, drops a CONNECTED/DEGRADED account to EXPIRED (which cascades dependent bots to NEEDS_AUTH) and writes a host.moved row to connection_audit. A move off a cloud computer deletes that gateway account (its browser profiles) best-effort.
The gateway provider id sent for an account is its vendor mapped by gateway_provider (openai→chatgpt, anthropic→claude, xai→grok, google, microsoft).
Not done yet
- Nothing sweeps cloud-hosted accounts in the background: a periodic check would wake the computer and defeat its sleep. Checks run when you ask (or after a sign-in).
- Settings UI for choosing the host and showing the viewer ships separately in allternit-ai.