Cowork, or roll my own? ☁️
Cowork has been around a while now: Claude Code with the plumbing handled for you — sessions that run in the cloud, connectors and plugins already wired up, an isolated place (a whole desktop, even) to let an agent loose. I’ve kicked the tyres a few times. I’ve never actually stuck with it. Which leaves a question I keep not answering: do I need it?
Because I already run most of this myself.
What I already have
I’ve spent a while building the stack Cowork packages. Scheduled loops that re-run a prompt against a spec until it converges — that’s loop engineering, and on my machine it’s a cron line and a stopping condition. Orchestration for when the steps have to be reliable — agents as planners sitting on top of boring, durable executors. And when I want a fleet instead of one session, there’s a whole self-hosted crowd to pick from — OpenHands, Hermes, openclaw, take your pick — running on hardware I control.
None of that came free. It’s evenings of yak-shaving. But it exists, it’s mine, and I understand every moving part, which was the point of building it.
The isolated-environment argument
The strongest case for Cowork, for me, is the sandbox — and its sharper cousin, a
whole desktop the agent can drive, not just a shell. Somewhere it can open apps,
click around, and rm -rf its own mistakes while I don’t flinch.
That last part lands close to home. The last few posts have been me coming at app control from the other side: teaching an agent to drive a native UI by its accessibility tree and to debug over DAP, on my own machine. Cowork rents the machine and the environment; I’ve been building the part that makes an agent useful once it’s inside one. Different halves of the same problem — and I care more about the half I don’t get handed.
The environment itself, though, is reproducible. A Docker container, a fresh VM,
a disposable branch — I can hand an agent somewhere it can’t hurt anything. On a
Mac there’s an even neater option now: Apple’s own
container runs each Linux image in its own
lightweight VM. More effort than clicking a button, sure. But not a capability
I’m missing.
The part that’s actually annoying to reproduce
The session runs online, on someone else’s hardware, and keeps going after I close the lid. That’s the piece I can’t cheaply fake.
My local setup has a tax I rarely mention: the tool calls run on my machine.
The model thinks in the cloud, but every bash, every file read, every build
happens in front of me — so the laptop has to stay awake and reachable for the
loop to make any progress. Cowork moves the whole thing off my desk. Kick off a
task, walk away, shut the lid, come back to a result. Reproducing that isn’t a
weekend project; it’s standing up real remote workers and keeping them alive.
So who’s it for?
Not me, mostly — at least not for the small stuff. I’m the person who wants to play with the stack and know it, and I’ve already paid that tuition. Cowork doesn’t sell me a capability I lack; it sells convenience I chose to build instead.
The target — la cible — is whoever doesn’t want any of that. Who’d rather not learn what a stopping condition is, keep a VM warm, or babysit a self-hosted orchestrator at 1am. For them the managed infra isn’t a nice-to-have, it’s the whole reason to show up. Fair product.
So: do I need Cowork? For little things, not today — I’m not the cible. But I keep opening it, and I expect I’ll keep trying: the day I want a dozen sessions running online while my laptop’s shut, the maths tips over. More a bookmark than a verdict. Ask me again when I’m tired of keeping the machine awake. ☁️
← Back to all writing