I’ve been building an API for running Claude Code in the cloud, not on a local laptop.
The core idea is simple: each agent gets its own isolated cloud computer with a persistent workspace.
So instead of “chat request in, text out,” it’s “run real tasks, keep files/tools/state, continue later.”
What it does right now:
Start or resume long-lived agent threads via API
Run in isolated containers per environment
Persist files/state between runs (workspace survives sessions)
Stream execution events in real time (tool calls, logs, progress)
Trigger runs from schedules and webhooks
Access from web/iOS/Telegram + API/SDKs (TS + Python)
Why I built it:
Local agent workflows are powerful, but tied to one machine/session
Stateless LLM APIs are easy to call, but hard to turn into reliable “ongoing workers”
I wanted something that behaves more like a junior teammate with a desk/computer, not just a chat box
Things that were surprisingly hard:
Keeping runtime behavior aligned with docs/instructions over time
Avoiding ephemeral /tmp output issues and ensuring artifacts land in persistent workspace paths
Container warm/reuse logic without breaking thread continuity
Cost/usage visibility per run
If this sounds useful, I’d love feedback on:
API shape for thread/run lifecycle
What “production-ready” means for agent infrastructure
Which integrations you’d want first (GitHub, Slack, etc.)
If useful, I can share the exact API flow and architecture decisions in a follow-up comment.
janlucasandmann•1h ago
The core idea is simple: each agent gets its own isolated cloud computer with a persistent workspace. So instead of “chat request in, text out,” it’s “run real tasks, keep files/tools/state, continue later.”
What it does right now: Start or resume long-lived agent threads via API Run in isolated containers per environment Persist files/state between runs (workspace survives sessions) Stream execution events in real time (tool calls, logs, progress) Trigger runs from schedules and webhooks Access from web/iOS/Telegram + API/SDKs (TS + Python)
Why I built it: Local agent workflows are powerful, but tied to one machine/session Stateless LLM APIs are easy to call, but hard to turn into reliable “ongoing workers” I wanted something that behaves more like a junior teammate with a desk/computer, not just a chat box Things that were surprisingly hard:
Keeping runtime behavior aligned with docs/instructions over time Avoiding ephemeral /tmp output issues and ensuring artifacts land in persistent workspace paths Container warm/reuse logic without breaking thread continuity Cost/usage visibility per run If this sounds useful, I’d love feedback on:
API shape for thread/run lifecycle What “production-ready” means for agent infrastructure Which integrations you’d want first (GitHub, Slack, etc.) If useful, I can share the exact API flow and architecture decisions in a follow-up comment.