# Spool Adds Claude Code Cloud Loops: How It Works and What to Watch

Spool v0.6.0 moves Claude Code execution to Anthropic’s cloud, but operators still own the coordination, network setup and stopping controls.

By Paras Madan | 2026-10-26


Spool released v0.6.0 on October 26 with a cloud runtime for its persistent Claude Code loops. Developers can run the agent's work on Anthropic's machines while retaining Spool's coordination hub. The release changes where execution happens, but it does not turn Spool into a hosted service.

For someone running several recurring coding agents, that distinction is more useful than the word “cloud.” The work machine, the system coordinating the work and the controls for stopping it are not necessarily in the same place anymore.

## What changed in Spool v0.6.0

[Spool's release](https://github.com/enes-alatas/spool/releases/tag/v0.6.0) was published at 16:46 UTC on October 26. Spool is an independent open-source project, not an Anthropic product announcement.

Its basic unit is a loop: a Claude Code session that can wake for messages or scheduled work, retain context and coordinate with other loops. The hub provides a web control room and connections to chat surfaces including Slack and Telegram.

The new cloud runtime sits beside the existing contained Docker runtime and bare host-process option. A developer can choose where a loop executes rather than treating every worker as another process on the same machine.

The [project README](https://github.com/enes-alatas/spool/tree/v0.6.0) describes a pre-1.0 tool built around the Claude Code CLI and the user's Claude login. Claude subscription and session limits still apply. There is no basis here to describe cloud loops as unlimited or free compute.

## How Spool starts a Claude Code cloud loop

Spool's [cloud-runtime design](https://github.com/enes-alatas/spool/blob/v0.6.0/docs/adr/0059-cloud-loops-run-through-the-claude-cli.md) uses the Claude CLI to start and message remote sessions. It builds a small repository containing the loop's configuration and hooks, then starts the session through `claude --cloud`. Later wakes use `claude -p --cloud` to send another message into that session.

Hooks connect the remote work back to the hub. The start hook reports the session identity, and the stop hook returns information about the completed turn. This is how the same coordination interface can sit above execution on a different machine.

That integration has limits. The transcript format is not a published API, and starting a session involves the CLI's interactive interface. Changes to those surfaces can affect the integration. The design explicitly describes failure handling rather than promising a permanent compatibility contract.

Cloud sessions use the CLI's automatic permission mode. If a session requires a decision on claude.ai, the operator may still have to answer there. An unattended loop is not a promise that every possible action will proceed without intervention.

## Setup still includes a publicly reachable hub

The [operations guide](https://github.com/enes-alatas/spool/blob/v0.6.0/docs/OPERATIONS.md) requires the hub, a Claude CLI installation, a Claude login and a configured cloud environment. The cloud listener must be reachable through an HTTPS address, using a tunnel or TLS proxy.

This is a separate listener for the remote loops, not a reason to expose the entire control room. Network configuration is part of the product's operating model, not a detail that disappears because the worker is remote.

The operator also configures the environment's allowed domains. Spool cannot read that list back to verify it, so it relies on confirmation that the displayed configuration was applied. Changes to the hub's network rules are not automatically proof that a cloud session has matching restrictions.

For a small team, that introduces another configuration boundary to maintain. The benefit is less dependence on a locally running work machine. The cost is coordinating systems that no longer share the same execution environment.

## Stopping a loop is not the same as stopping its remote turn

**A stop in Spool can cut off the session's access to the hub without interrupting work already running in Anthropic's cloud.** The documented way to interrupt that remote turn is through its linked session on claude.ai.

That matters when the task has access to a repository or other external systems. Losing the messaging connection does not by itself revoke every capability the remote session already has.

The documentation also says attached environment-variable secrets remain on the remote session's disk until it is archived. Connection changes apply at the next session start, not simply the next turn. Those are reasons to keep credentials scoped and understand the remote session lifecycle before handing it important work.

## What the cost display cannot tell you

Cloud turn costs are estimates based on token counts and Spool's own model-price table. An unknown model produces an unknown cost, not a zero-cost turn.

More importantly, cloud turns do not supply the usage-limit events that Spool uses to observe plan consumption. A hub with only cloud loops has no plan-usage reading. **The existence of a spending display is not evidence that it can enforce a complete cloud usage budget.**

Spool's useful change is a new execution choice for an existing coordination model. For developers evaluating it, the meaningful test is whether remote sessions remain observable and controllable through real interruptions, permission requests and usage limits. Moving the worker is straightforward to describe. Preserving operational control is the harder part.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn complex product updates into clear launch stories that developers and founders can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).