What happened
On October 29, 2026, Amp announced macOS Satellites in beta. The feature gives an Amp thread access to a cloud Mac for work on iOS and Mac applications. Amp frames the feature as a way to ask the agent to build, test, and run an Apple-platform app while being able to watch the work or take over the machine.
The architecture is deliberately split across two machines. An Amp thread continues to run on a Linux “orb,” alongside its development server and toolchain. When Amp determines that work needs macOS, it can start a second machine: a fresh cloud Mac with Xcode and simulators installed. Amp says this boot takes about 30 seconds. The agent can run commands and read and write files on the Mac, but code remains synchronized with the orb: Amp still edits on the orb, while the Mac is used to build, run, and test.
Outputs from the Mac—including screenshots, logs, and builds—return to the thread. The application on the Mac can reach the backend on the orb through Amp’s portals. A Mac tab in the thread streams the Mac screen, letting a user observe the agent’s interaction with an app or take control and try it directly.
The Macs are ephemeral. Each starts fresh and nothing is saved on it. After Amp finishes, the Mac remains running for 20 minutes. A follow-up during that window reuses the same machine and its build cache; after the window, the Mac is deleted. Users can also remove it immediately by archiving the thread or asking Amp to stop it.
Amp says it previously tested “Morbs,” where an entire thread ran on a Mac, but found the approach unsuitable for wider rollout. Docker and backend startup took minutes, and retaining a Mac disk for every thread was expensive. Satellites instead keep Linux-suitable work on the orb and introduce a Mac only for macOS-specific work.
Pricing is $2 per hour for a mac.medium with six CPUs and 14 GB of memory, and $4 per hour for a mac.large with 12 CPUs and 28 GB. Satellite time comes from the plan’s included orb usage at a higher rate, then from Amp credits. Every Mac starts as mac.medium; users can request mac.large or disable mac.medium in settings. Access is currently through a waitlist in Settings → Experimental Features, with availability expanding as Amp adds Macs.
What the archive adds
This is a new product event, but it fits the broader argument in Agent work is moving into harnesses, factories, and accepted artifacts: agent work increasingly depends on an operating environment around the model. A separate earlier note, Google Cloud launches Agent Compute Engine for sandboxed agent runtimes, covered another provider’s runtime infrastructure for agents.
Trend signal
This supports Harness architecture outlives model choice. Amp’s release is not primarily a model claim: its value comes from routing work between a persistent Linux environment and a short-lived platform-specific machine, synchronizing code, returning artifacts, and retaining a cache briefly enough to support iteration. It also supports the assumption that scheduled, resumable, and subagent-based runs will account for more coding-agent usage, recorded at Goal-scoped agent loops.
Why it matters
For teams building iOS or macOS software, the practical constraint is often not code generation but access to the Apple-specific environment where a build, simulator run, and UI check can occur. Satellites make that environment an on-demand capability inside Amp’s existing workflow. The split also makes an explicit engineering trade-off: keep ordinary development activity on Linux, where the agent’s environment can start quickly, and pay for a Mac only at the stages that need it.
That can simplify remote agent workflows and reduce the need to provision a permanent Mac per active thread. It also makes runtime design more visible in cost planning. A team must account for hourly Mac use, cache-expiry behavior, waitlist access, and the boundary between what is safe or useful to run on the orb versus on the temporary Mac.
Limits and uncertainty
The announcement establishes Amp’s design and stated prices, not its reliability or economic performance in production. It does not quantify build times after synchronization, capacity on the waitlist, availability by region, concurrency limits, or the rate at which a real project consumes Mac hours. It also does not establish how the architecture performs with large repositories, complex signing and provisioning flows, physical-device testing, or teams that need persistent machine state. The beta status means access is still being expanded as Amp adds Macs.
Skill to build now
Map an Apple-platform agent workflow into two classes of steps this week: steps that can remain in a general Linux environment, and steps that require macOS, Xcode, or a simulator. For the latter, define the artifacts that must come back for review—build output, logs, screenshots, and a reproducible test result. Then decide whether a short cache window is sufficient for the iteration cycle. That exercise makes an on-demand Mac useful as a controlled test capability rather than an opaque remote desktop.
Reader takeaway
Amp is turning a cloud Mac into a temporary extension of its Linux coding-agent runtime. The important change is not merely remote Mac access: it is a workflow that invokes expensive, platform-specific compute for build and test steps while keeping the rest of the agent environment on Linux.