Cloud agents
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.
The short answer
Running an AI agent in the cloud means moving execution from your laptop to a server process that survives your session. Three approaches exist: keep your terminal agent alive on a rented box under tmux, drive an agent from CI on a trigger, or use a hosted runtime that owns the queue. Polaris takes the third approach, with a Postgres job queue and a worker process on Fly.io.
- Setup for the hosted path
- Assign a task
- Session deadline
- 8 minutes per job
- Shell access
- None
What people mean by this question
The search is usually not about hosting. It is about custody. Someone has a terminal agent that works well, and the constraint they have run into is that the agent belongs to one laptop and one person. They want the same quality of work to happen on a machine they do not have to babysit, and they want a colleague to be able to reach it.
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.
Anthropic ships Claude Code and changes what it offers on its own schedule. Check Anthropic's documentation for what is current there. The rest of this page is about the three architectures available to you regardless of which vendor's model is doing the thinking.
The three architectures
Pick by what you need to be true, not by what sounds modern.
| Terminal agent on a rented box | Agent driven from CI | Hosted runtime with a queue | |
|---|---|---|---|
| Setup | Provision, install, keep a session alive | Write a workflow file and a trigger | Assign a task to a worker |
| Repository and shell | Full | Full inside the runner | None |
| Who can start work | Whoever holds the SSH key | Whoever can push or dispatch | Anyone in the org, from the task |
| Where results land | That shell | Logs and artifacts | A comment, a file, a Docs page |
| Ops burden | Yours | Yours | None on your side |
| Fit | Solo engineer with a repo to work | Deterministic, repeatable pipelines | Teams handing work back and forth |
What one hosted job does, in order
This is the sequence in runtime/worker.mjs, not a marketing summary of it.
- 1
The queue row appears
Assigning a task to a member whose kind is agent fires a Postgres trigger that inserts a row into agent_jobs with status pending. Copilot members are excluded, and tasks already marked done are skipped.
- 2
The runtime claims it
A loop on the Fly machine polls every five seconds, takes the oldest pending row, and flips it to running with a conditional update that fails harmlessly if another process claimed it first.
- 3
Context is assembled
The worker's instructions, every attached skill document in full, the org's docs tree, the task's checklist, labels, bucket, due date and last ten comments are read in a handful of parallel queries and rendered into a system prompt and a brief.
- 4
The loop runs with real tools
Up to ten rounds against the Anthropic Messages API. Web search runs server-side with a cap of eight uses per session. Five further tools are implemented by the runtime and answered locally, whatever the stop reason.
- 5
The session ends
The worker calls deliver, which writes the final comment. If it never does, the runtime nudges once and then salvages the last block of text as the delivery, so a session that ran out of rounds still hands something back.
What the hosted runtime does not do
Read this before you decide. It is short and it matters.
No shell
There is no terminal in the session. The worker cannot run a build, a test suite or an arbitrary command.
No repository checkout
Nothing is cloned. Code work stays with your local agent, which is genuinely better at it.
No scheduler
Work starts because a human assigned a task or commented on one. There is no cron in the product today.
No unbounded session
One job is capped at ten model rounds and an eight-minute deadline. Long work is decomposed across sessions, on purpose.
Go deeper
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
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.
What keeps running after you close the lid
The honest version: nothing on your laptop survives, so the work has to not be on your laptop.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Task queue
The thing that lets a request survive the process that made it.
Questions people ask
+Can I point Polaris at my own machine instead of a hosted one?
The queue contract makes that possible in principle, because agent_jobs is an ordinary Postgres table and the runtime is one process reading it with a service-role key. Polaris does not ship a self-hosting path or documentation for it today, so treat this as an architectural property rather than a supported feature.
+Which model runs the session?
Each worker can carry its own model setting, and the runtime falls back to a current Claude Sonnet model when the worker is set to inherit. The call is a plain Anthropic Messages API request with a tools array, made server-side from the Fly machine.
+Does the agent see my whole workspace?
It sees the task it was assigned, that task's checklist and last ten comments, the bucket the task sits in, the titles of up to a hundred and twenty document pages so it knows where to file things, and its own skills and instructions. It does not receive the contents of other tasks or documents.
+How fast does work start after I assign it?
The trigger writes the queue row inside the same transaction as the assignment, and the runtime polls every five seconds, so a free machine picks the job up in seconds. If a job is already running, the next one waits its turn in created_at order.
+What does a session cost?
The software is free. A finished job stores a human-equivalent minute estimate on its own row, billed at roughly two dollars per hour, computed from counters such as searches run and characters written. A short research task typically lands in single-digit dollars, and a job that delivers nothing is not billed.
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.
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
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.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Task queue
The thing that lets a request survive the process that made it.
Web search in Polaris
Nothing to authorize, nothing to store, and every query a worker runs appears in the activity feed while it works.