← All posts

Comparison

Cloud coding agents compared: Jules, Codex Cloud, and Claude Code on the web

There is a category of coding agent that never touches your machine. You describe a task in a browser tab, a VM somewhere clones your repository, an agent works for ten minutes, and a pull request appears. No terminal, no laptop fan, no node_modules on your disk. Three products own this space right now: Google Jules, Codex Cloud from OpenAI, and Claude Code on the web from Anthropic.

They look nearly identical in a marketing screenshot and differ sharply in the places that decide whether they are usable: what the sandbox can reach, where your secrets end up, how the result comes back, and — the part almost nobody writes about — whether you can drive any of it from a script.

The shape they share

Strip the branding and all three run the same loop. It is worth having the shape in your head before the differences make sense.

The structural consequence of that middle box is the thing to internalise: you do not get a shell. Anthropic's docs say it outright — "You don't get a shell into the session VM. Claude runs every command for you." The same is true of the other two. Everything you want to happen in that VM has to be expressed either as a setup script written in advance, or as a sentence in the prompt. That single fact explains most of what cloud agents are good and bad at.

The three, side by side

How a task gets in

Jules — a plan you approve

You sign in with a Google account and grant GitHub access over OAuth, to all repositories or a chosen subset. Then you pick a repository and a branch, write the prompt, optionally attach a setup script, and ask for a plan. Jules produces the plan first and waits for you to approve it before it edits anything. It also reads an AGENTS.md at the repo root if you have one — the same file Codex and several other agents read.

That plan-approval step is the clearest philosophical difference in the group. Jules treats the plan as the artifact you review; the other two treat the diff as the artifact you review. The plan gate is also the one thing that disappears when you drive Jules over its API: the docs are explicit that "sessions created through the API will have their plans automatically approved" unless you set requirePlanApproval.

Codex Cloud — an environment you configured earlier

Codex Cloud is the most environment-centric of the three. Before a task, you set up a cloud environment per repository: dependencies, tools, variables and setup steps. Then you "choose your environment, and describe the result you want." Tasks can be started from chatgpt.com/codex, from the Codex CLI, from the IDE extension, or straight from a GitHub pull request, a GitHub issue, or a Slack thread.

Two things worth knowing before you start: the environment gets a setup script that runs when the container is created, and optionally a maintenance script that runs when a cached container resumes — a distinction the other two do not make. And Codex supports best-of-N: codex cloud exec --attempts takes 1 to 4, described as the "number of assistant attempts (best-of-N) Codex cloud should run."

Claude Code on the web — the local CLI is a first-class entry point

Anthropic's version is the one that assumes you already have a terminal open. You connect GitHub either by authorising the Claude GitHub App during web onboarding, or by running /web-setup in your terminal to sync your local gh token to your Claude account. Then claude --cloud "Fix the authentication bug in src/auth/login.ts" starts a cloud session from the command line.

One detail in that flow bites people: the VM clones from GitHub, not from your machine. The docs spell it out — the session "clones your current directory's GitHub remote at your current branch, so push first if you have local commits." There is a fallback for repos with no GitHub remote at all, where Claude Code bundles your local repository (under 100 MB, tracked files only) and uploads it, but a session created from a bundle "can't push back to a remote."

There is also a documented access subtlety that matters for teams. Installing the Claude GitHub App is not a permission boundary: "a cloud session can access any repository the connecting GitHub account can see, not just the repositories the Claude GitHub App is installed on." Restricting what cloud sessions can reach is a GitHub-side job, not a Claude-side one.

What the sandbox can and cannot reach

This is where the three genuinely diverge, and it is the section to read twice if you are evaluating any of them for a private repository.

Network

Codex's method restriction is a small feature with an outsized effect. An agent that can GET documentation but cannot POST anywhere has a meaningfully smaller exfiltration surface than one with a domain allowlist alone, because a permitted domain is still a permitted upload target. OpenAI's docs list the risk explicitly: prompt injection from untrusted web content, code and secret exfiltration, malware downloads.

Anthropic's honesty about the None level deserves the same credit. "None" does not mean airgapped; it means no outbound connections through the session's network, while Claude Code still talks to the Anthropic API. If your threat model is "this code must not leave the building," a cloud agent is not the tool, whatever the network dial says.

Jules is the gap. Its environment docs cover the Ubuntu image, the preinstalled toolchains, setup scripts and snapshotting, but state no network policy for the agent phase. That is not evidence of an absence — it is an absence of evidence, and it is the single biggest documentation gap across the three products.

Secrets

Codex Cloud is alone in having a real answer here, and it is a good one. Environment variables persist through the session; secrets are "stored with an additional layer of encryption and are only decrypted for task execution," and — the important part — they "are only available to setup scripts. For security reasons, secrets are removed before the agent phase starts." Your private registry token can install dependencies and then be gone before the model sees a single file.

Claude Code on the web has no equivalent yet, and its docs are blunt about it: "cloud environments have no dedicated secrets store, so don't add API keys or other credentials," and anyone who uses the environment can read the values. What it does instead is remove the need for the most common secret — GitHub credentials never enter the VM at all. A proxy swaps a scoped credential for your real token on the way out, and GH_TOKEN literally reads as the string proxy-injected inside the container. It also constrains what the proxy will do: git push works only against the session's current working branch.

Jules documents environment variable support in its changelog but its environment page does not describe a secrets model. Assume anything you put there is readable.

Setup, snapshots and the five-minute rule

All three cache. Jules captures an environment snapshot after a successful "Run and Snapshot" and reuses it for later tasks on that repository. Codex caches container state for up to 12 hours and invalidates automatically when you change the setup script, the maintenance script, environment variables or secrets. Claude snapshots the filesystem after the setup script succeeds and reuses it for roughly seven days, re-running the script when you change it or the allowed hosts.

Anthropic publishes the constraints that actually trip people up, so borrow them as a checklist for all three:

• Exit zero. A non-zero setup script means the session fails to start. Append || true to anything non-critical.
• Finish in about five minutes, or the cache does not build and you pay the setup cost on every session forever.
• The cache is a filesystem snapshot. Installed packages and pulled Docker images survive; a database you started does not. Start services per session.

Resource ceilings are published only by Anthropic: roughly 4 vCPUs, 16 GB RAM, 30 GB disk per session, with the note that memory-hungry builds may be killed. Jules' changelog mentions a 20 GB VM disk. Codex publishes no numbers, though its docs note that ChatGPT Business gets larger cloud VMs.

How the result comes back — and what review it needs

All three end in the same place: a branch, a diff, and a pull request you open. The differences are in how much ceremony sits around it.

• Jules can create the PR for you without being asked. Set "automationMode": "AUTO_CREATE_PR" on the session and the PR URL turns up in the session's outputs. Left unset, no PR is created automatically.
• Codex Cloud hands you a summary and a diff first: "Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready."
• Claude Code on the web shows a diff indicator like +42 -18, opens a diff view where you can leave inline comments and send them back as your next message, and creates the PR from the web UI. Commits carry a Claude-Session: <url> git trailer and PR bodies include the session URL, so a reviewer can open the transcript that produced the change. Turn that off with attribution.sessionUrl: false if your team would rather not.

Two review habits are worth forming immediately. First, a green run is not a correct run. Anthropic says it plainly about routine runs and it generalises: a green status "means the session started and exited without an infrastructure error. It does not mean the task in your prompt succeeded." Blocked network requests and failing tests surface in the transcript, not in the status pill.

Second, read the diff, not the summary. The agent wrote both. The summary is the agent's account of its own work, produced by the same process that produced the bug you are looking for. A cloud agent's PR needs the same review a contractor's PR needs, and arguably more, because you were not present for any of the intermediate decisions.

Claude also has the most interesting escape hatch from review-by-browser-tab: teleport. claude --teleport, /teleport inside a session, or t from the /tasks list pulls a cloud session down to your terminal with the branch checked out and the full conversation history loaded. It needs a clean working tree, the same repository (not a fork), the branch pushed, and the same claude.ai account. When the cloud agent gets 80% of the way and then needs your local database, this is the exit.

Programmatic access: the part nobody documents

We wired all three of these into Backgrind's session watcher, so this section is written from integration work rather than from reading a landing page. It is also where the three products are least alike, and where the marketing gives you no signal at all.

Jules: the only real API in the group

Jules ships a documented REST API at https://jules.googleapis.com/v1alpha/, authenticated with an API key in an X-Goog-Api-Key header. It is labelled experimental — Google's own words are that "specifications, API keys, and definitions" may change — but it is a complete CRUD-shaped surface, not a webhook with delusions of grandeur.

# 1. find the repository you connected
curl 'https://jules.googleapis.com/v1alpha/sources' \
  -H "X-Goog-Api-Key: $JULES_API_KEY"

# 2. start a session that will open its own PR
curl 'https://jules.googleapis.com/v1alpha/sessions' \
  -X POST -H 'Content-Type: application/json' \
  -H "X-Goog-Api-Key: $JULES_API_KEY" \
  -d '{
    "prompt": "Add a regression test for the empty-cart case",
    "sourceContext": {
      "source": "sources/github/acme/storefront",
      "githubRepoContext": { "startingBranch": "main" }
    },
    "automationMode": "AUTO_CREATE_PR",
    "title": "Empty cart regression test"
  }'

# 3. poll everything you have running
curl 'https://jules.googleapis.com/v1alpha/sessions?pageSize=50' \
  -H "X-Goog-Api-Key: $JULES_API_KEY"

The state field on a session is the useful one, and the enum is small enough to handle exhaustively: QUEUED, PLANNING, AWAITING_PLAN_APPROVAL, AWAITING_USER_FEEDBACK, IN_PROGRESS, PAUSED, COMPLETED, FAILED. Two of those eight — the two AWAITING_ states — mean the agent has stopped and is waiting for a human. That distinction is the whole reason a polling integration is worth building: a task that is running needs nothing from you, and a task that is blocked needs you right now.

There are two more session-level verbs, both POST with the Google-style colon suffix: /sessions/{id}:approvePlan and /sessions/{id}:sendMessage. Between them you can run an entire Jules task from a script without ever opening jules.google.

Jules also has a CLI, Jules Tools, which is a thin client over the same ideas: jules remote new --repo acme/storefront --session "write unit tests", jules remote list --session, jules remote pull --session <id>, and a --parallel flag that fans the same prompt out into several sessions at once.

Codex Cloud: no REST API, but the CLI is scriptable

There is no public REST API for Codex Cloud. What there is, and what is genuinely under-advertised, is a codex cloud subcommand in the Codex CLI whose own description is "Browse or execute Codex cloud chats from the terminal without opening the TUI." It has two subcommands, exec and list, and list speaks JSON:

# start a cloud task in a named environment, best-of-3
codex cloud exec --env env_abc123 --attempts 3 \
  "Port the retry helper to the new transport and add tests"

# machine-readable listing of your recent cloud chats
codex cloud list --json --limit 20

--json is documented as "Emit machine-readable JSON instead of plain text" and --limit accepts 1 to 20. The payload is a tasks array plus an optional pagination cursor, with each entry carrying id, url, title, status, updated_at and environment_id. That is enough to build a status watcher — it is exactly what we do — but be clear-eyed about the trade-off: you are shelling out to a binary that must be installed and logged in on the same machine, at a cost of one process spawn per poll. That is not an API, it is an API-shaped workaround, and it will break the day the JSON shape changes.

Claude Code on the web: a write-only door

Anthropic publishes exactly one HTTP endpoint that touches cloud sessions, and it is not a listing endpoint. A routine — a saved prompt plus repositories plus connectors — can be given an API trigger, which mints a per-routine bearer token and a URL:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "CI failed on main: 3 tests in auth.spec.ts"}'

It returns a session id and URL and nothing else:

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

The limitations are explicit and, to Anthropic's credit, documented rather than discovered. The token's scope is "one routine only; no read access." SDK support: "None." The beta header experimental-cc-routine-2026-04-01 is mandatory and requests without it return 400. And there is no idempotency key, so a retrying webhook creates duplicate sessions.

So: you can start a Claude cloud session from a script, and you cannot ask which ones are running. The only listing surface is /tasks inside the Claude Code CLI — a human interface, not a machine one. Anything that wants to watch your Claude cloud sessions from outside would have to scrape a private endpoint, which is why we did not build that integration and why nobody else honestly can either. If a tool claims to monitor your Claude Code web sessions today, ask it which documented endpoint it calls.

Pricing and limits, as of August 2, 2026

Read the date on this heading before you quote any of it. All three vendors have changed these numbers within the last year.

Two honest gaps. Google's plan pages render in local currency by region and the one we hit did not show USD, so we are not quoting a Google AI Pro or Ultra price — check jules.google/docs/usage-limits and your own Google One page. And Jules' usage-limits page does not say whether API-created sessions draw on the same daily task allowance as web ones; we could not verify that either way, so budget as if they do.

The metering models are more different than the prices. Jules counts tasks, which makes cost trivially predictable and makes a wasted task expensive. Codex and Claude count tokens against a window you are also spending locally, which means an afternoon of cloud tasks quietly eats the budget for your interactive session. If you are used to firing off local work all day, the first surprise with cloud agents is usually a rate limit, not a bill.

The honest framing

Cloud agents are excellent at a narrower band of work than the demos suggest, and the band has a shape you can predict.

What they are genuinely good at

• Bounded, well-specified tasks. "Add a regression test for the empty-cart case." "Port this change to the Python SDK." "Bump the dependency and fix the three call sites it breaks." Anything you could write as a ticket a competent stranger could close.
• Work that parallelises. Five independent tasks across five VMs finish in the time of the slowest one, and none of them fight over your working tree. This is the strongest argument for the category — it is what you would otherwise be doing with worktrees, without the reconciliation.
• Work you do not want on your machine. A dependency upgrade that pulls half of npm, a build that eats 12 GB, a task on a repository you would rather not clone locally.
• Event-driven chores. CI failed, so fix it. A PR opened, so review it. This is the reason routines, auto-fix and Jules' CI Fixer all exist, and it is the most underrated use of the category.

What they are bad at, and will stay bad at

• Anything needing your local environment. A staging database on your VPN, a simulator, a device, an unpushed branch, a service running on localhost:3000. The VM cannot see any of it, and no prompt fixes that.
• Conversation. The loop is slow by construction: you write, you leave, you come back, you read a diff. Exploratory work where you would normally say "no, not like that" six times in two minutes is miserable through a browser tab. Do that locally and send the result to the cloud — plan mode locally, commit the plan, then claude --cloud "Execute the migration plan in docs/migration-plan.md" is a pattern Anthropic recommends and it is the right instinct.
• Anything under-specified. A local agent that misunderstands you wastes thirty seconds. A cloud agent that misunderstands you wastes a task, a rate-limit slice and ten minutes, and you find out at the end. The cost of a vague prompt is much higher here.
• Work with real secrets in the loop, unless you are on Codex and can confine them to the setup phase. "No dedicated secrets store" is a straight quote from Anthropic's own docs, not a criticism smuggled in from outside.

Where this leaves a working setup

Nobody who uses these seriously uses only one. The realistic shape is a local agent for the conversation, cloud agents for the fan-out, and a review queue that mixes both. Which creates a dull, real problem: three products, three tabs, three notification systems, and no single place where "something needs you" shows up. Jules has two of its eight states meaning "blocked on a human," Codex surfaces a status in a list you have to open, and Claude tells your browser.

That is the gap Backgrind was built for, and it is why the API question above was not academic for us. Backgrind is an always-on-top overlay that runs your own agent CLIs locally and pings you only when one needs a decision — and it polls Jules over its REST API and Codex Cloud over codex cloud list --json so remote tasks raise the same toast as local ones. Claude Code on the web is the one we cannot include, for the reason spelled out above: there is no endpoint to poll. If you want the local half of that today, see running Claude Code in the background; if the interruptions are what you are trying to kill, pre-approval policies are the other half of the answer.

And if you are still choosing which agent to run locally in the first place, that is a different question with a different answer — Claude Code vs Codex CLI covers it.

Frequently asked questions