Claude Code in the Cloud Anthropic's Claude Code now runs cloud sessions on a fresh virtual machine per task, cloning the repository onto a new branch with the environment preconfigured, available at no additional cost on Pro, Max, Team, and Enterprise plans. Existing individual Pro and Max subscribers can claim a one-time bonus credit of $100 on Pro and $250 on Max by October 7 at claude.ai/code/claim-credit or via /claim-credit in Claude Code, expiring November 4. In a four-session test against a sample Node API repository called tidepool, three sessions started within 16 seconds of each other ran for 61, 65, and 72 seconds and all finished 87 seconds after the first started, with repository recreation consuming roughly a third to just over half of each run. What changes when Claude Code runs on its own machine, the workflows where that pays off, and how to connect GitHub on the first try. You probably run Claude Code in a terminal on your own laptop. That session depends on the laptop in three ways: A cloud session https://code.claude.com/docs/en/claude-code-on-the-web runs Claude Code on a machine of its own. Each task gets a fresh virtual machine with your repository cloned onto a new branch and your environment's setup already done. You can start one from claude.ai/code https://code.claude.com/docs/en/web-quickstart , the Claude mobile app https://code.claude.com/docs/en/mobile , the Desktop app https://code.claude.com/docs/en/desktop run-long-running-tasks-in-the-cloud , your terminal https://code.claude.com/docs/en/claude-code-on-the-web from-terminal-to-cloud , and Slack https://code.claude.com/docs/en/slack . You can then follow it from the browser, the mobile app, and Desktop. When the work is done, it sits on a branch you can turn into a pull request. Cloud sessions come with your Pro, Max, Team, or Enterprise plan at no additional cost: there's no separate charge for the cloud machine, and sessions draw on the same usage limits as the rest of Claude Code. Depending on your plan, an organization owner may need to turn on cloud sessions https://claude.ai/admin-settings/claude-code first. Bonus credit for cloud sessions. Existing individual Pro and Max subscribers can claim a one-time bonus credit for cloud sessions, on top of their plan limits: $100 on Pro and $250 on Max. Claim it by October 7 at claude.ai/code/claim-credit or with /claim-credit in Claude Code. The credit expires on November 4. After it's used or expires, your plan's regular usage applies. It isn't eligible for Projects or Routines. See the Promotional Credit Offer Terms https://www.anthropic.com/legal/promotion-credit-terms . For this guide I ran four real cloud sessions against a small sample repository. Their transcripts, diffs, and timings appear throughout. The repository and the user in the screenshots are made up. The work, the output, and the numbers come from those sessions. One of the main advantages of cloud sessions is that you can run several tasks at once without them getting in each other's way. Here are three I started within 16 seconds of each other, each on its own machine. On my laptop, I'd have run these one after another, or spent my time keeping them out of each other's way. The sample repository is tidepool , a small Node API that predicts tides for three fictional harbors. It had three ordinary problems: one test failed about one run in four, the API docs described parameters the code no longer read, and the logger built its lines by concatenating strings. I started three cloud sessions within 16 seconds of each other, one per problem. I started them programmatically, and because tidepool isn't on GitHub, each session first recreated the repository from files in its prompt. With a real repository you'd skip that step, and from a terminal each session is one claude --cloud command. Shortened, the three prompts were: claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code not the test , and prove it by running the suite at least 30 times in a row." claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it." claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG LEVEL, and log method, path, status and duration ms as fields. Add a test for the logger." The sessions ran for 61, 65 and 72 seconds, and all three were done 87 seconds after the first one started. Recreating the repository took roughly a third to just over half of each run. Here are the results. TtlCache.get . The cache stored a value only after the loader finished, so a second get for the same key during a load called the loader again. Claude changed the cache to store the in-flight promise, dropped the entry when a load fails, and ran npm test 40 times in a row with zero failures. days parameter the code ignores, gave heights in feet when they are metres, skipped the /next-high endpoint, and left out the error responses. It also found that a malformed from= value returns an empty list with a 200, and documented that as a caveat instead of changing server code it wasn't asked to touch. The logger result shows why cloud sessions suit parallel work. Each session had its own copy of the repository, its own processes and its own branch. The docs session and the logger session each started the API server to test against it, and neither affected the other. On a single laptop, two agents working in one checkout would edit the same files, and would collide on a port unless each picked its own. Because of that isolation, the logger session had no access to the cache fix the first session was making. Split parallel tasks along file boundaries, merge the branches in a sensible order, and expect a session to report problems that another session is already fixing. A cloud session is a Claude Code session running on Anthropic-managed infrastructure, or on your organization's own machines with a self-hosted environment https://code.claude.com/docs/en/self-hosted-environments . The figure shows the parts. The four takeaways after it are the ones that change how you work. CLAUDE.md , rules, skills, agents, and commands travel with the repo, and your ~/.claude stays on your laptop. See For specs, permission modes https://code.claude.com/docs/en/permission-modes , and network levels, see the cloud environments docs https://code.claude.com/docs/en/cloud-environments . Cloud sessions don't replace local ones, and most people use both. The table shows where they differ, and the paragraphs after it say when each one fits. | | Local session | Cloud session | |---|---|---| | Runs on | Your machine | A fresh VM for each task | | Laptop asleep or offline | The session stops | The session keeps going | | Several tasks on one repo | Separate worktrees, ports and care | One VM and one branch per task | | What the agent can reach | Anything your user account can, including SSH keys, cloud CLIs and ~/.claude | The repository, the network level you set, the connectors you enable, and a session-scoped GitHub credential | | Start or follow from | That machine, or your phone through remote control | Browser, phone, Desktop, terminal, Slack, an API call or a schedule | | Approvals | Any mode, including per-command | Auto, Accept edits or Plan | | Ends with | Changes in your working tree | A branch, and a pull request when you want one | | Compute | Your machine | No separate compute charge; uses your plan's limits | Stay local when the task needs something only your machine has. That covers a database with real local data, a service you reach over VPN, a GPU, a phone simulator, or hardware on your desk. Stay local too for tight visual loops where you want to see each change in your own browser within seconds, and when your organization runs with Zero Data Retention https://code.claude.com/docs/en/zero-data-retention , which turns cloud sessions off. Two features sit between the options. Remote control keeps the session on your machine and lets you steer it from your phone or browser. Self-hosted environments https://code.claude.com/docs/en/self-hosted-environments , in beta for Team and Enterprise, run cloud sessions on your organization's own infrastructure, so they can reach private networks. If none of that applies, the task is a good candidate for the cloud. The next section covers the workflows where that pays off most. These workflows put the differences in the table to work: a separate machine for each task, sessions that keep running while you're away, and a branch at the end for you to review. Let's say you have five small, unrelated fixes. Locally, you'd do them one after another, or set up five worktrees and keep their ports and installs apart. In the cloud, you'd start five sessions and review five branches. claude --cloud "Fix the flaky test in auth.spec.ts" claude --cloud "Update the API documentation" claude --cloud "Refactor the logger to use structured output" claude --cloud clones your GitHub remote at your current branch, so push your local commits first. While the VM starts, the CLI shows a live checklist of setup steps and queues anything you type. Write each task as a self-contained ticket that states what's wrong, what done looks like, and how to prove it. The flaky-test prompt named its proof: running the suite at least 30 times in a row. The session ran it 40 times. When the tasks belong to one larger effort, a project https://claude.com/blog/projects-redesigned public beta for Pro and Max runs a coordinator conversation that starts and tracks the cloud sessions for you. It then groups them by state: working, waiting on you, and ready for review. A flaky test is the clearest case of work that needs repeated proof: you have to run the suite again and again, and you don't want that loop tying up the machine you're working on. In the cloud, Claude patched the cache and ran the whole suite 40 times in one command. The VM has no compute charge and its CPU isn't yours, so ask for thorough proof. Run the suite 200 times, bisect a regression across 50 commits, run the slow integration tier, or start the app and hit it with curl the way the docs session did. Each of Claude's turns still counts toward your plan, but a long test run inside one command costs little. Foreground commands https://code.claude.com/docs/en/cloud-environments time out after 2 minutes by default 10 at most and then keep running in the background for up to 30 more. You can raise the defaults with BASH DEFAULT TIMEOUT MS and BASH MAX TIMEOUT MS in the environment's variables. For a larger change, agree on the approach first where back-and-forth is cheap. Start Claude in plan mode, work out the plan together, commit the plan, and push it. claude --permission-mode plan ...agree on the plan, save it to docs/migration-plan.md, commit and push... claude --cloud "Execute the migration plan in docs/migration-plan.md" While the cloud session builds, your terminal is free for other work. When it's done, pull the session down to finish it by hand. claude --teleport pick a cloud session claude --teleport