Anthropic
Blogcast

Alex: Welcome back to Anthropic Blogcast, where we turn Anthropic posts into a conversation you can follow on a walk or a drive. I am Alex.

Jordan: And I am Jordan. Today we are looking at a developer guide from claude dot dev about running Claude Code in the cloud, and why that changes the way you hand off coding work.

Alex: The starting point is familiar to anyone who codes on a laptop. A local session shares your working files, it runs with your own credentials, and it stops when the lid closes or the Wi Fi drops.

Jordan: Right, and if you try to run two sessions on the same repository at once, they can easily get in each other's way. They might edit the same files, or both try to use the same port for a test server.

Alex: A cloud session flips that setup. Each task gets its own fresh virtual machine, with your repository copied onto a new branch and your environment already prepared.

Jordan: So you can start work from a browser, from your phone, from the desktop app, from a terminal, or even from Slack, and then check in on it from somewhere else entirely.

Alex: And when it finishes, what you get back is not a pile of changes on your laptop. You get a branch that is ready for you to review and turn into a pull request.

Jordan: The pricing point is worth noting too. The guide says cloud sessions are included with the Pro, Max, Team, and Enterprise plans, with no separate charge for the machine itself, and they draw on the same usage limits as the rest of Claude Code.

Alex: To show what that isolation buys you, the author ran three separate jobs against one small sample application, and started all three within sixteen seconds of each other.

Jordan: The three jobs were the kind of ordinary work every team knows well. One was hunting a flaky test, one was bringing out of date documentation back in line with the code, and one was switching a simple logger over to structured output.

Alex: All three finished in under ninety seconds total. On a single laptop, you would normally have run them one after another, or spent your own time keeping them apart.

Jordan: My favorite detail is what happened with that flaky test. The problem turned out to be a race in a cache, where the same value could be loaded twice if a second request arrived while the first load was still running.

Alex: And the fix was to remember the work already in progress, rather than starting it again, and then to prove the fix by running the whole test suite forty times in a row with zero failures.

Jordan: That word prove is doing a lot of work here. In the cloud, asking for thorough proof is cheap for you, because the repeated runs are not tying up the machine you are trying to work on.

Alex: The documentation job makes the same point in a different way. The agent started the server, tried every example for itself, and found several places where the written docs no longer matched what the code actually did.

Jordan: And the logger job is a nice honesty check. Its own testing ran into that same flaky cache problem, it recognized the likely cause, and it said plainly in its summary that the overall suite was not yet clean, instead of pretending everything was green.

Alex: That is the trade off of true isolation. Each session only sees its own copy, so one session will not automatically benefit from a fix another session is making at the same moment.

Jordan: Which is why the guide suggests splitting parallel work along clear file boundaries, and merging the resulting branches in a sensible order afterwards.

Alex: Let us talk about the security model, because that is where a lot of developers will pause before trying this. Your GitHub token does not go into the virtual machine.

Jordan: Instead, a proxy outside the machine holds that token, and the session itself only gets a short lived credential that can push to its own working branch.

Alex: The repository's own instructions travel with the code, things like the project guidance file, its rules, and its commands. Your personal settings folder on your laptop does not travel.

Jordan: And you also control how much network the machine can reach. You can narrow that right down, allow the common package sources and code hosts, or open it up only when a task truly needs the wider internet.

Alex: There is one more practical warning hidden in there. Idle machines get reclaimed, so if a session sits for a long time, you may come back to a fresh machine with the conversation restored, which means you should commit work you care about as you go.

Jordan: So when should you stay local? The guide is pretty clear that cloud is not a replacement for everything.

Alex: Stay local when the job needs something only your machine has, like a database with real local data, a service you can only reach over a virtual private network, a graphics processor, a phone simulator, or hardware sitting on your desk.

Jordan: Stay local also for those tight visual loops, where you want to see every change in your own browser within seconds. Cloud is better when the work can be described clearly, checked with a command, and left to run.

Alex: That leads neatly into the workflows the guide highlights. The first is simply clearing a backlog in parallel, five small unrelated fixes becoming five separate sessions and five branches to review.

Jordan: The second is letting the machine prove a fix, whether that is running a suite hundreds of times, or working through a long, slow set of integration tests you would never want to babysit.

Alex: A third pattern I like is planning at your desk, building in the cloud, and finishing in your terminal. You agree the plan together where conversation is cheap, save that plan in the repository, and then hand the execution off.

Jordan: Fifth, you can hand off the annoying follow up work from a pull request, like failing checks and review comments, and let a session push the clear fixes while flagging anything ambiguous for a human decision.

Jordan: And seventh, cloud sessions give you a safer place to run code you do not fully trust yet, like a new contributor's change or a new dependency's install steps, inside a disposable machine that does not sit next to your keys and browser profile.

Alex: The guide spends real time on GitHub setup, and for good reason. Signing in with GitHub and installing the Claude GitHub App are two separate steps, and private repositories need that second step on the account or organization that actually owns them.

Jordan: That explains the most common early frustration, where you connect successfully but a private repository simply does not show up in the picker. Usually the app is not installed where that repository lives, or single sign on was not completed for that organization.

Alex: The last big idea is giving a session a way to check its own work. A session that can run your tests, start your server, and try real examples will hand back work that has actually been exercised.

Alex: And it reminds you to write the important commands into the repository's own guidance, because your personal notes on your laptop do not reach the cloud machine.

Jordan: If I had to boil the habits down, it would be this. Keep one task per session, name the command that proves the job is done, push your own commits before you start a cloud run, and read the summary before you dive into the diff.

Alex: I would add one more, which is to watch your limits. Five parallel sessions will draw on your plan roughly five times as fast as one, so parallelism is powerful, but it is not free in that sense.

Alex: To get started, the guide says setup takes about five minutes. You sign in, connect GitHub and install the app where your repository lives, pick the repository and the default environment, and hand over one backlog task with a clear way to prove it is done.

Jordan: Then, and this is the part that still feels a little magical, you can close the tab, check in later from your phone, and come back to a branch that is ready for review.

Alex: That is the real shift here. It is not just Claude Code on a bigger computer. It is coding work that is no longer tied to one laptop being awake, in one place, doing one thing at a time.

Jordan: Thanks for listening. If you build with Claude, this is one of those guides that repays reading in full, especially the setup and environment sections, before your first real run.

Alex: We will be back with the next Anthropic post. Until then, happy building.