What cloud coding agents are, and what self-hosting one takes

A cloud coding agent takes a task from outside the editor—an Issue, a chat mention, a prompt box—runs it in an environment you did not set up on your own laptop, and returns a branch, a diff, or a pull request for review. GitHub, Cursor, OpenAI, Anthropic, Cognition, and xAI all sell some version of it now, under names like cloud agent, background agent, cloud session, or autonomous software engineer.

The engineering problem is not the model call. That part is a base URL, a key, and a model ID. The hard part is everything around it: a trigger that works with the laptop closed, an environment that can clone and build the repository, a credential boundary, and an output a person can review. This article maps the category, walks the loop, names where it breaks, and then looks at DeepSeek’s open-source Super-agent prototype, which moves the control plane to a machine you operate.

The category is three parts

Every product in this category shares the same shape:

• A trigger that does not need an open editor. Work arrives as an Issue assignment, an @mention in Slack or Feishu, a prompt in a web app, an API call, or a CLI handoff.
• An environment outside your machine. The agent clones the repository, installs what it needs, and works in a sandbox or workspace managed by the vendor or your organization.
• A reviewable result. It ends with a branch, a diff, a draft PR, or a comment—something a person can review and act on.

That separates the category from two neighbours. A local IDE agent runs on your laptop while you watch; a chat assistant answers questions without touching the repository. A cloud coding agent sits between them: it has real tools and a real checkout, but the human is meant to leave.

The word bot describes the chat-native shape of the same idea. Instead of assigning an Issue, you mention the agent in Slack, Teams, or Feishu. The trigger changes; the remote environment does not. The output can be a PR, a diff, or a set of finished files.

The product map

Product	Starts from	Runs in	Returns
GitHub Copilot cloud agent	Issue, @, Agents panel	Cloud sandbox or Actions	Branch or PR
Cursor Cloud Agents	Desktop, web, Slack, Linear	Isolated cloud VM	PR
OpenAI Codex Cloud	ChatGPT web, desktop, mobile	Cloud workspace	Changes or PR
Claude Code cloud sessions	Browser, mobile, desktop, terminal	Anthropic-managed VM or self-hosted environment	Branch or PR
Devin	Slack, Teams, web, CLI, API	Workspace with terminal, editor, browser	Draft PR
Grok Bot	Desktop/mobile chat, @bot on X	Cloud machine (Cursor-hosted)	Files or drafts

The “Runs in” column follows each vendor’s own wording. Isolation details differ, and Devin’s documentation does not describe its VM architecture or isolation guarantees.

Grok Bot is the broadest entry: xAI describes it as a persistent AI teammate, started from desktop or mobile chat, or by mentioning @bot on X when the accounts are linked. It runs on an account-level cloud machine hosted by Cursor, with browser, storage, and command-line access. Its documentation describes finished files and drafts, not a repository workflow; branch and PR creation are not documented. That places it at the bot end of the spectrum.

Four differences matter more than the table:

Where the trigger lives. GitHub Copilot cloud agent and OpenAI Codex Cloud are designed around work that already lives in GitHub or the ChatGPT app. Cursor Cloud Agents and Devin lean chat-native: a Slack or Teams thread is the front door. Claude Code cloud sessions accept the trigger from a browser, a phone, the desktop app, or claude --cloud in a terminal, and can also run on a schedule.

How much the vendor shows you. Claude Code documents its isolation in detail: in Anthropic-hosted environments, each session runs in an isolated VM, network access is limited by default, and git credentials stay outside the sandbox, with a proxy authenticating on the session’s behalf. Organizations can route sessions to a self-hosted environment instead, where isolation is their responsibility. Cloud sessions share the plan’s rate limits, with no separate VM charge; they require a claude.ai sign-in and are not available when Claude Code is configured for Amazon Bedrock, Google Cloud’s Agent Platform, or another third-party provider. The other vendors publish less about the internals; “sandbox” or “VM” is often the end of the public description.

What the agent is allowed to touch. Some products are scoped to a single repository; others advertise organization-wide or multi-repository work. This is the first thing to check against your own setup, because a capable agent with the wrong repository scope is either useless or dangerous.

What kind of work it is for. Most of this list is repo-scoped coding. Grok Bot is a general cloud teammate: its docs describe files and drafts, not a repository workflow. Read “cloud agent” as a spectrum, not a single product shape.

How the loop runs

Strip away the branding and the loop is similar everywhere:

1. Intake. A trigger arrives. The product decides whether it is a real task, sometimes asks one clarifying question, and queues a session.
2. Environment. The agent clones the repository at the right branch, runs a setup script or image, and installs the toolchain. Network access and secrets are configured here, not later.
3. Work. The agent reads code, edits files, runs tests and commands, and occasionally opens a browser. Long tasks continue after your laptop sleeps.
4. Output. It pushes a branch and opens a PR, or leaves a diff and a written summary. Some products return draft PRs because the agent is expected to stop before merge.
5. Review. A person reads the diff, comments, and either merges, asks for changes, or takes the work back into a local session. Some products can also watch the PR and push fixes when CI fails.

The differences that bite are in steps 2 and 5. A setup script that takes too long, a repository the agent cannot clone, a network policy that blocks a package registry, or a credential the sandbox cannot see will stop a task that looked simple. And “reviewable output” still means a human reviews it: none of these products removes the review step, they move the typing.

Why this wave is happening now

Three conditions had to line up. Models became reliable enough to run long tool loops without constant supervision. Sandboxes and setup scripts became cheap enough to give every task its own environment. And the pull request became the default interface between an agent and a reviewer, which means teams did not have to invent a new review process.

There is also an attention argument. DeepSeek’s companion design essay makes it explicitly: a single task is limited by the model, but a person’s throughput across many tasks is limited by attention. A cloud agent moves session management, context switching, and waiting off the person. That claim comes from DeepSeek’s essay, not from an independent study, but it describes why the category feels useful.

Where it breaks

Every hosted product trades control for convenience:

• Trust boundary. Your code, and sometimes your credentials, leave your machine. Vendors publish different levels of detail about isolation, retention, and network access; read them per product rather than assuming the category is uniform.
• Isolation. A managed VM is designed to contain the agent, but it is still the vendor’s environment. “Sandbox” can mean anything from a hardened VM to a container with broad network access.
• Customization. Hosted agents expose settings, not source code. If your workflow needs a different trigger, a different review rule, or a different model, you are limited to what the product offers.
• Cost model. Most of these products bill through a subscription or plan with usage limits; the agent’s time is not a line item you control directly. Budget by plan, not by token.
• Scope and lock-in. Multi-repository support, chat integrations, and enterprise controls vary by vendor, and moving a workflow from one to another is not free.

The self-hosted example: DeepSeek’s Super-agent

DeepSeek’s release is interesting because it asks what the same loop looks like when the control plane stays with you. The repository is deepseek-ai/dsh-superagent-prototype, an MIT TypeScript plugin for DeepSeek Harness (DSH), version 0.1.0, published as a research prototype. The README is explicit: it is adapted for publication, it is not identical to DeepSeek’s internal version, and it does not implement every idea in the design essay.

Its shape is a long-lived Router session and a Worker session per ticket. Events flow through Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. A team authorizes work through a policy; explicit @mentions from allowed people are accepted, while proactive work starts in observe mode, which records what the agent would have done without opening tickets. Each Ticket gets its own session and directory; a prepare command can create a git worktree per ticket.

The operating model is the opposite of a vendor sandbox. It listens to one github.com repository (no GitHub Enterprise Server) and optionally Feishu. Both Router and Worker presets run with danger-full-access as the operator’s OS user; account wrappers choose the agent’s credentials but do not isolate the process. The deployment guide’s advice is a dedicated OS account that holds only the agent’s credentials. State lives in SQLite under a configured stateDir. The philosophy is written as a budget: take as little human attention as possible, and give as much value as possible.

The prototype does not hard-code a model. It uses the Harness profile default unless Eval or Execution overrides it, so a team can put a lighter model on the Router and a stronger one on Workers.

The design essay reports scheduling numbers from a synthetic workload—about 300 messages and 20 work requests, simulated tools, five runs—with a p50/p95 around 12.4 / 15.7 minutes against about 29.5 minutes p95 for a single-session baseline that made no subagent calls. Those are the essay’s own measurements under simulated tools, not an independent coding-quality benchmark.

What is not reproduced or verified

• No live end-to-end ticket. This article does not report a Super-agent ticket executed from trigger to PR.
• No independent performance result. The scheduling figures above are the design essay’s self-reported measurements under simulated tools, not coding-quality results.
• No reproduction of the hosted products. Capabilities for Copilot, Cursor, Codex Cloud, Claude Code, Devin, and Grok Bot come from their official documentation, not from tests run here.
• Research software with no default sandbox. The README calls the plugin a research prototype, and its presets run with danger-full-access. A team trying it should use a dedicated OS account and a dedicated agent GitHub account.

Models, hosting, and what stays yours

AIHubMix connects DeepSeek Harness through an OpenAI-compatible endpoint at https://aihubmix.com/v1; the example in the DeepSeek Harness guide uses provider aihubmix and model auto. The guide covers the base DSH connection, not the Super-agent plugin. AIHubMix does not host the Super-agent process: the Router, state, polling, and shell run where DSH was installed. The hosted products above manage their own model selection.

Sources

1. deepseek-ai/dsh-superagent-prototype — README, the design essay it cites, and docs/000–008
2. Connect DeepSeek Harness to AIHubMix — AIHubMix
3. GitHub Copilot cloud agent — GitHub Docs
4. Claude Code in the cloud — Anthropic
5. Grok Bot documentation — xAI