#35023 Cloud start: read a new machine's state 1 s apart and stop waiting as soon as it runs

Leo-ask: ask-e09ceb4656

Leo, 2026-11-04: "why is it taking so long to start a chat "in cloud"?"

Why it takes long

Every first send from a Mac workspace that has no Cloud machine yet makes a new machine (one workspace per small Cloud machine, #30020), so the wait is mostly that machine starting. On top of that, the client wasted time:

• While a new machine provisioned, CloudMove.connected slept 3 s before every read, the first included, then did a full list read. A machine that came up just after a read was seen up to 3 s late.

This change

• The first 20 reads are 1 s apart, then 3 s (80 reads, about 3 min, up from 60 × 3 s).
• Each pause ends as soon as any other read (the change tracker's refresh, a list read) shows the machine running, and then no extra list read is made.
• Cancelling the start still ends the wait at once.

Expected saving: about 1–3 s per first send that makes a machine (average lag after the machine runs goes from ~1.5 s + the 3 s first sleep to ~0.5 s). Not measured on a real start yet; the larger fixes for this ask are the prewarm PRs already open (#34974 prewarm while typing, #34487 warm on composer select), which start the machine before Send.

Risk: low. One wait loop's pacing; a provisioning machine now costs up to 20 extra list reads in its first 20 s.

Test: CloudMachineChangeStateTests.aStartWaitsForANewMachineToRun gains a case: a machine seen running during a pause is not read again.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Speeds up the first send from a Mac workspace that provisions a new Cloud machine. Previously CloudMove slept 3 s before every state read (the first included), so a machine that came up just after a read was seen up to 3 s late.

• Reads 1 s apart for the first 20 reads, then 3 s (80 reads, about 3 min) instead of 60 reads at 3 s.
• Stops waiting as soon as any read shows the machine running, with no extra list read; cancelling still ends the wait immediately.