Cloud agents
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
The short answer
A local agent runs in a process on your own machine with your filesystem, your shell and your credentials, and stops when that process stops. A cloud agent runs on a server, keeps working when your device sleeps, and writes its output somewhere a team can read. Local agents win on repository work and iteration speed. Cloud agents win on durability, shared access and record-keeping.
- Local strength
- Filesystem and shell
- Cloud strength
- Durability and shared access
- Common answer
- Run both
Row by row
Written from the Polaris runtime on the cloud side. Other cloud runtimes make different trade-offs.
| Property | Local agent | Cloud agent (Polaris runtime) |
|---|---|---|
| Execution host | Your machine | A Fly.io machine, region sin, shared CPU with 512MB |
| Survives a closed lid | No | Yes |
| Filesystem access | Your whole disk | None |
| Shell and build tools | Yes | No |
| Repository checkout | Yes | No |
| Live web search | Depends on the tool | Server-side, capped at 8 uses per session |
| Who can start work | The person at the keyboard | Any member, by assigning a task |
| Concurrency control | Whatever you remember | One live job per task, enforced by a unique index |
| Output destination | Terminal, and files you already own | Task comment, attachment with versions, Docs page |
| Record of the run | Scrollback | Ordered event stream plus an activity feed |
| Credential custody | Your local environment | Org-wide, server-side, no read path to a browser |
| Session bound | Your patience | 10 model rounds, 8-minute deadline, 2 retry attempts |
| Cost model | Your own API bill or plan | Free software, ~$2 per human-equivalent hour delivered |
Work that belongs on a local agent
This is not a concession. It is most engineering work.
Anything touching the repository
Refactors, test runs, migrations, dependency work. A cloud runtime with no checkout cannot compete and should not pretend to.
Tight iteration loops
When you want to see a result, adjust one word and try again, latency and immediacy beat everything else.
Work with local-only secrets
Things that depend on your machine's environment, VPN or device-bound credentials.
Exploration you will throw away
If the artifact is understanding rather than a deliverable, a durable record adds nothing.
Work that belongs on a cloud agent
Research with sources
Live search, cross-checking, and a brief that ends with the URLs it actually opened, delivered where a team can quote it.
Anything a second person must read
If the output has an audience beyond you, it needs a home with a version history rather than a paste.
Work that outlives your session
Long compilations, monitoring sweeps, batches you queue in the evening.
Work someone else should be able to start
A colleague assigning a task at midnight should not require you to be awake.
Anything that will be argued about later
Ticked acceptance criteria, an ordered event stream and stored effort counters exist precisely for the argument.
Names, precisely
Claude Code is Anthropic's coding agent, and it runs in your terminal on your machine. Polaris is a separate product, built by superstack.digital, with no affiliation with or endorsement by Anthropic. Polaris runs its own agent runtime on cloud machines and calls the Anthropic API to do the thinking. If what you want is Claude Code, use Claude Code. If what you want is the capability people describe when they say "Claude Code in the cloud for my team", that is what this page is about.
So the comparison on this page is architectural. It is local execution against server execution, not one vendor's product against another's.
Related reading
Running an AI agent in the cloud instead of on your laptop
Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.
How long an agent session can run, and what happens when it ends
Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.
How an AI worker gets tool access
The interesting part of tool access is not the list. It is where the credential lives and who can read it.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Cloud development environment
The compute, filesystem and toolchain live somewhere else, and are usually thrown away afterwards.
Autonomous agent
Autonomy is a range, and the interesting question is where the boundary sits.
Questions people ask
+Is a cloud agent slower than a local one?
Startup is slower and iteration is much slower, because you are writing a task rather than typing into a live session. Throughput on unattended work is higher, because the session continues without you. Choose by which of those two matters for the piece of work in front of you.
+Can a cloud agent read my codebase?
The Polaris runtime cannot, because it performs no checkout and has no filesystem access to your machine. GitHub is in the connection catalog as an org-wide credential, so repository access is a credential question rather than a checkout question, and code execution is not part of the session either way.
+Which is safer?
They fail differently. A local agent runs with whatever your shell can reach, which is broad and hard to audit after the fact. A cloud agent runs with credentials an admin authorised org-wide, stored in tables with no client read path, and writes an ordered record of every step it took.
+Do I have to pick one?
No, and most people who search for this end up running both. The practical division is that anything requiring a shell stays local and anything requiring an audience or durability moves to the queue.
+What limits a single cloud session?
Ten model rounds, an eight-minute deadline, eight web searches, a two-megabyte cap on any single attached file, and up to a hundred and twenty blocks in a drafted document. Longer work is decomposed into more tasks rather than one longer session.
Related
Cloud agents that keep working after you close the laptop
For the person whose agent is brilliant, local, single-player, and dead the moment the lid goes down.
Running an AI agent in the cloud instead of on your laptop
Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.
How long an agent session can run, and what happens when it ends
Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.
How an AI worker gets tool access
The interesting part of tool access is not the list. It is where the credential lives and who can read it.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Cloud development environment
The compute, filesystem and toolchain live somewhere else, and are usually thrown away afterwards.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.