I built a just-for-fun project using Claude Cowork to run a newsletter and build a brand. It runs eight scheduled agents that research, draft, edit, and publish a weekly newsletter on a set cadence. It works, as long as my MacBook is awake, logged in, and signed into my accounts. The minute I close the lid, the whole operation stops and my scheduled tasks don't run, until I remember to open my personal computer again. Is it a matter of a simple habit of keeping my laptop awake 24 hours a day? Probably, but I wanted to see how to get the agents off my laptop and avoid the missed scheduled runs.
The bottleneck is browser login
The models were never stuck on my Mac; the API calls run anywhere. What is stuck on my Mac is the publishing step. Six of the eight agents post through a browser that is already logged in, a Substack and my LinkedIn company page, driven by the Claude in Chrome extension, and seven agents read or write a local Articles folder. Substack has no publishing API. LinkedIn company-page posting through the official API needs partner approval a solo publisher effectively can't get. So the challenge isn't "where do the agents run," it's "where does an authenticated browser session live."
I researched different hosting options, listed below, and every one is a different answer to that question. That's the general lesson I'd pull out of this before any of the specifics: when you audit an agent system for portability, start by finding the step that only works because you're logged in as you. Otherwise, it really depends on how much time you want to invest in rebuilding your agents, your budget, and your technical savviness.
Six ways towards portable agents
| Option | What it is | Off my laptop? | Rebuild? | Cost | The catch |
|---|---|---|---|---|---|
| 1. Always-on Mac | Leave a Mac running, auto-login, sleep disabled | No | None | ~$600 used Mac mini | Physical box; silent misses |
| 2. Cloud Mac | Rent a hosted macOS instance, clone the setup | Yes | None | ~$470/mo on AWS; less on specialists | Still babysitting a Mac |
| 3. Beehiiv API + automation | Re-platform onto Beehiiv's Create Post API, trigger from n8n/Make/Zapier | Yes | Full | Low | Beta, Enterprise-gated; no LinkedIn; drops Substack |
| 4. Code on a VPS | Port the prompts to code, drive browsers with Playwright + saved cookies | Yes | Full | $5–20/mo | I own every 4am cookie-refresh failure |
| 5. Cloud-browser hybrid | Move the logged-in browser to the cloud (Browserbase "Contexts"), drive on schedule | Yes | Partial | Usage-based | Newer moving part to trust |
| 6. Hermes | Move to Nous Research's open-source agent; its skills system mirrors my SKILL.md files | Yes | Full | Self-hosted | Orchestrator, not publisher; still needs one of the above underneath |
Comparing the porting options
The simplest option is clearly the always-on Mac: auto-login, sleep disabled, and hope. A power cut or an OS update can cause a silent miss, and I find out after the fact. Fine for a month or so, not the reliable option, but it makes sense for a side project just for fun.
The full rebuilds, Beehiiv and the VPS and Hermes, all have the same publishing challenge. Beehiiv does have a real Create Post API, but it's beta and gated to Enterprise plans, and it does nothing for LinkedIn. Porting everything to code on a $5 VPS is the cheapest to run and the most expensive to own: headless cookie refresh is the brittle part, and when it breaks at 4am, I'm the one who has to fix it. Hermes is the most natural conceptual migration, its skills system maps almost directly onto the SKILL.md files I already have, but it's an orchestrator, not a publisher. It still needs one of the other options underneath it to post the articles.
The two that fix my problem the most are the two that leave the working system alone. The cloud Mac is the only option that is both truly off my machine and zero rebuild: the identical setup, hosted, logged in once. AWS EC2 Mac runs about $470 a month, largely because Apple imposes a 24-hour minimum billing window on Mac instances; Mac-specialist hosts charge a fraction of that. The cloud-browser hybrid is the more complex option. Browserbase persists logged-in sessions as "contexts" in the cloud, and a scheduler drives them. It solves the underlying problem of having an authenticated browser stuck on my Mac, without needing Beehiiv Enterprise and without giving up Substack.
One publishing strategy question changes the answer
Underneath the six options is a decision I have to make that isn't technical: am I staying on Substack, or committing to Beehiiv? If I'm moving to Beehiiv, the publish layer eventually gets a real API, and the rebuild becomes worth planning toward instead of avoiding. If Substack stays, no amount of engineering fixes an API that doesn't exist, and the real choice collapses to two: cloud Mac versus cloud browser. I've watched teams spend weeks comparing orchestrators when the binding constraint was a vendor's missing API the whole time.
Now comes Claude Cowork
While I was working through this, the tool I run these agents in delivered the thing I thought I needed. Claude's Cowork now runs scheduled tasks in the cloud, with the laptop closed. It looks like that kills the premise of this whole piece.
But it doesn't. Cloud execution runs the agents with no device online, but local file access and browser automation still require the desktop app to be open. The two things my agents actually depend on, the local Articles folder and the logged-in Substack and LinkedIn sessions, are exactly what cloud mode still leaves tied to an open Mac.
Where I landed
I haven't rebuilt anything yet, and I won't rebuild eight working agents to fix what is, underneath, a "my laptop sleeps" problem. If I want them off my machine tomorrow, the cloud Mac is the pragmatic answer: the same system, hosted. If I want something cloud-native for the long run, the cloud-browser hybrid is the more comprehensive choice, because it moves the session and nothing else.
Eight agents that write a weekly newsletter turned out to be the easy part. Keeping a browser login alive without me is the part that took research. The platform dependency, not the agent framework, set the ceiling the whole time, and the step that only works because I'm logged in is the one thing I was ever really hosting.