Why buy an M5 Max when you can control your beefy office rig from an iPad? Exploring the hardware implications of Claude
The local machine becomes the remote backend
Remote control of a development environment flips the usual hardware choice. You no longer need the same machine under your hands as the one that builds, tests, and runs heavy workloads. A light tablet or laptop becomes a thin client. The beefy office rig stays on the desk, powered on, with full local CPU, GPU, disk, and network access. Claude Remote Control sits in the middle: you issue intent from wherever you are, and the work runs on the hardware you already own.
That setup weakens the old binary of “local only” versus “cloud only.” Local still wins on latency to your files, private code, custom toolchains, and hardware you control. Cloud still wins when you need burst capacity or a machine you do not maintain. Remote control of a local workstation is a third path: keep the advantages of a real desktop, drop the requirement that you sit in front of it.
Why an M5 Max is no longer the default answer
Buying a top-tier portable machine often means paying for peak performance you only need in short bursts—compiles, containers, model runs, multi-service stacks. If those jobs can stay on a desk machine you already have, the portable device only needs good screen, keyboard comfort, battery life, and a reliable connection. An iPad (or any thin client) becomes enough for the human half of the loop: reading diffs, approving steps, steering Claude, and checking results.
The hardware decision shifts from “what is the strongest laptop I can carry” to “what is the strongest always-on box I can leave at home or in the office, and how thin can the device in my bag be.” Peak silicon still matters. It just does not have to live in your backpack.
What still has to work for this to be real
- A stable path from the remote device to the workstation—VPN, tunnel, or equivalent—so sessions do not die mid-task.
- Clear boundaries for what Claude may touch: repos, shells, secrets, and production credentials should be explicit, not assumed.
- Feedback you can trust: logs, test output, and file changes must surface on the thin client without forcing you to babysit a full desktop UI.
- A plan for when the office rig is offline, locked, or mid-update—remote control is only as good as the machine left running.
Without those pieces, remote control is a demo. With them, the local rig is a personal compute node you drive from anywhere, not a desk you have to occupy.
How to think about the next purchase
Spend first on the machine that stays put: cores, RAM, storage speed, and whatever accelerators your real workload uses. Treat the portable device as an interface budget—display quality, input comfort, and connectivity. Keep one strong local environment well maintained instead of maintaining two half-capable ones. Use the cloud when the desk machine is the wrong shape for the job, not as a default substitute for hardware you already own.
Claude Remote Control does not make local hardware obsolete. It separates “where the work runs” from “where you sit.” Once that split is reliable, the local-versus-cloud debate stops being a lifestyle choice and becomes a per-task routing problem: run here, run there, or hand the session to the agent on the box that already has the right tools.