Product·Sessions

Start anywhere.
Continue anywhere.

Mac, web, and iPhone are three equal doors into the same session. Start a run from your desk, your browser, or your phone. Steer it, approve the plan, merge the PR from whichever screen is in front of you. A Mac or an enrolled device does the compute; every surface is a full control surface, and none of them is the "main" one.

Mac
new session
continuumcode.ai/appWeb
new session
iPhone
new session
One session pool0 live
01 · Three peers

No primary screen.

The native Mac app, the web app at continuumcode.ai/app, and the iPhone app are peers, not a hub and its remotes. Each one can start a session, steer it mid-turn, approve a plan, and merge a PR.

Compute lives on a Mac or an enrolled device. Everything else is a control surface with equal reach. Open a session on one, pick it up on another - same thread, same branch, same transcript.

Nothing forks, so nothing has to be reconciled. The host owns the agent process and writes the transcript; every other surface subscribes to it. No local copy drifts. Compare a worktree manager like Conductor, where the desk is the only door.

Macnative · hosts compute
Webany browser · zero install
iPhonein your pocket · full control
iPhonestarted here
Macidle
Webidle
São Paulo · worktree · sp-1
02 · Start on the Mac
ChatCodeUsageSettings
Continuum
São Paulo · claude fable-5worktree · sp-1

Type it at your desk.

Pick a repo, pick a model, type a prompt, send. The session spawns in a worktree on your Mac and starts streaming - plan, diff, terminal, PR, all in one thread. This is the native workbench, and it hosts the compute for the other two surfaces.

Send does real work before the first token appears. Continuum cuts a git worktree so the agent never edits your main checkout, names the run after a city so parallel sessions stay tellable apart, launches the CLI at your model and effort, and takes a rollback checkpoint. The Claude Code worktree guide covers the plain-git version.

Nothing here is Mac-only. The same start flow - repo, model, prompt, send - is one tap away in the browser and on your phone. Your last pick is sticky: the device and repo chips survive a sleeping laptop, a Wi-Fi switch, and a relaunch instead of resetting to whatever host happens to be awake.

03 · Start on the web

Start one in a browser tab.

Sign in at continuumcode.ai/app on any machine, click New session, pick a repo, type a prompt. The run spawns on your paired Mac or an enrolled device and streams straight into the tab. No download, no local install.

A borrowed laptop, a work desktop, a Linux box with just a browser - all of them are full session starters. The relay between the tab and the host is end-to-end encrypted and can't read a byte.

The browser is a client, never a host. It does not clone your repo, hold your provider keys, or run the agent, which is why a locked-down work machine can drive a run executing on a Mac at home. A different bargain from Claude Code on the web, where your repo has to go to them.

continuumcode.ai/app
+ New session pick a repo to begin
clawdmeter
defx-frontend
continuum-web
Lisbon · claude fable-5worktree · clawdmeter
04 · Start on the iPhone
9:41𝗅𝗍𝖾 ▮▮▮
Sessions
Start in
clawdmeter
defx-frontend
continuum-web
Osaka · clawdmeter

Kick one off from your pocket.

Tap , pick a repo, dictate or type the prompt, send. The session spawns on your Mac or an enrolled device and streams to the phone in real time - chat, plan, diff, terminal, PR, the whole workbench in your hand.

Start a refactor on the walk to lunch. It's a real session the instant you tap send, waiting for you on every other screen when you get back.

The phone is not a read-only mirror. Session detail carries Chat, Plan, Diff, PR, Terminal, and Files as tabs, so you can read a hunk or merge a PR from a bus seat. Rather finish at your desk? Open on Mac hands the draft over with repo, agent, model, and effort already set.

05 · One transcript

Live is pushed, not polled.

Most remote-control tools ask the host "anything new?" on a timer. The phone stays seconds behind and the battery pays for the question. Continuum inverts it: the host opens a socket per session and pushes the transcript the moment it changes, coalesced so a fast reply arrives as a handful of frames instead of one per token.

Networks still fail. Elevators, planes, hotel Wi-Fi. So the client is written assuming it will drop.

01 · push

Subscribe, don't poll

Each open session gets its own stream off the host. Updates are debounced before they leave, so a long answer lands as a few frames and the radio stays quiet between them.

02 · degrade

Reconnect, then fall back

A dropped socket retries on a widening backoff with jitter. If it keeps refusing - a network that blocks sockets outright - the client drops to ordinary requests so you get updates instead of a frozen screen.

03 · commit

Sends survive the tunnel

Every write - send, approve, interrupt, merge - carries an idempotency key. A retry replays the receipt instead of re-running the command, so a flaky connection can't merge a PR twice.

The queue is visible, not magic. Anything pending or permanently failed shows up on the session, so you retry or cancel it by hand instead of guessing whether your approval landed. That's what makes it safe to run several agents in parallel.

06 · Approve from anywhere

The decision lands where you are.

A session started on any surface keeps running while you move. The host keeps streaming while you're away from it. When the agent needs a call, the notification finds you - a banner with the session's city name and the reason it's waiting. Tap it and the same thread opens, mid-run, wherever you are.

Approve the plan from the train. Kill a runaway turn from the elevator. The session doesn't restart, doesn't fork, doesn't care which screen answered - it's one conversation on many screens.

The banner says why it fired, not just that something happened: which session, which repo, how long the turn ran, what it wants. A plan waiting for approval reads differently from a finished run, so you decide from the lock screen whether it's worth opening. See how plan mode works, then Plan & review.

9:41𝗅𝗍𝖾 ▮▮▮
São Paulo worktree · sp-1
Plan ready - 4 steps to migrate the parser to actor isolation.
Migration planplan ready
Make parsers nonisolated static
Move cache writes onto the actor
Bypass mtime cache for newest file
Re-run 800+ tests
@@ UsageHistoryLoader.swift @@
- func parse(_ url: URL) {
+ nonisolated static func parse(
+ _ url: URL) async {
… 14 hunks · +212 −96
PR #214 merged
+212 −96 · checks ✓
$0.31 · 38.2k tok · live
07 · Reach per surface

Equal doors, honest edges.

"Peer" means every surface can start, steer, approve, and ship. It does not mean every surface renders every pane. Here is the actual shape.

The Mac is the reference host, the densest UI, and the only place the Spawn terminal grid lives. Web and the Windows/Linux desktop client render the same dashboard, so fixing one fixes both. iPhone carries the workbench tabs. Watch isn't an IDE: limits, waiting plans, approve, interrupt, voice reply.

Something always has to host. If you have been solving that with Claude Code over SSH and tmux, this is the same idea with a real client on the other end instead of a scrollback buffer. The peer model is agent-agnostic: a Codex session steers from the phone exactly like a Claude one.

Machost · full workbench · spawn grid
web · desktopsame dashboard · zero install
iPhonechat · plan · diff · pr · terminal · files
Watchlimits · approve · interrupt · voice

every surface starts sessions · the host runs them

08 · Questions

The honest fine print.

Short answers here, long answers in the docs.

Something has to host the compute, but it doesn't have to be a Mac you're sitting at. A Mac or any enrolled device - an old laptop, a Linux box, an EC2 instance, or a serverless burst - hosts the session; the Mac app, the web app, and the iPhone app are all full control surfaces onto whatever is hosting. Start on the phone against an enrolled device and the Mac never needs to be open at all.

Yes. New session, pick a repo, type or dictate a prompt - the full start flow lives on all three surfaces, not just the Mac. The run spawns on your paired host and streams back to whichever surface you started from, and to every other one at the same time.

Yes. Pair once by QR; traffic rides an end-to-end-encrypted relay (XChaCha20-Poly1305 - the relay sees envelope lengths, not contents) or your own Tailscale tailnet if you'd rather have zero third parties in the path. Every remote command is rate-limited and audit-logged on the host.

Yes - it's the same session, live everywhere. Type on the Mac, approve on the phone, watch it stream in the browser, all against one thread and one branch. Whichever screen you touch, you're driving the same run on the same host.

The write is queued locally with an idempotency key and retried on a widening backoff. If it lands twice the host replays the original receipt instead of running the command again, so no double prompt and no double merge. Anything undeliverable is parked and shown to you, never silently dropped.

The run lives on the host, so it stops only if the host stops. Close the laptop you were watching from and nothing changes; close the laptop that is the host and the session pauses with it. That's what enrolled devices and Cloud solve.

10 · Begin

One session.
Every screen you own.

Five minutes from download to your first session - started wherever you happen to be.

requires an apple silicon mac or enrolled device to host · web & iphone are first-class