Alibaba Cloud Snapshot Charges Starting Next Month

Alibaba Cloud Cloud Sandbox Snapshot to Begin Charging on September 7

Alibaba Cloud announced today that the Cloud Sandbox Snapshot feature will officially begin commercial billing at 00:00 Beijing time on September 7, 2026.

The core of this feature is not a traditional “disk backup,” but a complete freeze of a running sandbox, including both its memory state and disk state. Users can then restore the original sandbox from the snapshot in seconds, or clone multiple new sandbox instances from it at once.

For the growing number of Agent tasks that need to run for minutes, hours, or even longer, this means tasks no longer need to start from environment initialization, dependency installation, and context loading every time. An Agent can pause at a state where it has already reached a critical stage and continue later, or copy the same state into multiple branches for parallel exploration.

It Solves an Agent Runtime Problem, Not a “Backup” Problem

Traditional cloud host snapshots are generally closer to disk-level restoration mechanisms. They are suitable for preserving system disks and data disks, or rebuilding a machine after a failure, but they do not necessarily preserve the complete execution state of processes at a given moment. For ordinary Web services, the cost of restarting a process may not be high; for Agents, the situation is completely different.

An Agent in the middle of execution may have already completed Web searches, code analysis, file modifications, or tool calls. Its memory may still contain task context, temporary variables, browser sessions, and intermediate results. If only the disk is restored, the process still needs to be restarted, and the task context may need to be reconstructed. Restoration takes longer, and may also result in repeated tool calls, repeated consumption of model quotas, or even different results because the external environment has changed.

The value of Snapshot is that it advances “restoring an environment” to “restoring an execution.” It can be understood as pressing the pause button on an Agent’s execution: the sandbox’s memory, disk, and runtime state are saved together, and restoration takes the Agent directly back to roughly where it was paused.

This is particularly useful for the following types of tasks:

• Long-running Agent tasks: Create a snapshot partway through execution, then continue from the checkpoint after a timeout, resource reclamation, or human intervention.
• Development environment warm-up: Start an environment with many dependencies in advance, completing dependency installation, service startup, cache loading, and other steps ahead of time so that subsequent instances can be launched quickly from the snapshot.
• Multi-path exploration: Have one Agent complete an initial analysis, then clone multiple sandboxes from the same snapshot to try different code changes, search paths, or reasoning approaches.
• Reproducible task execution: Save a specific runtime state for testing, regression validation, and troubleshooting, reducing environmental variation that can cause “the same input” to produce different results.

From a product-positioning perspective, Snapshot is more like a runtime checkpoint in Agent infrastructure than a simple storage feature. If Agent applications are to evolve from one-off scripts into systems that can run continuously and repeatedly try different approaches, this type of capability will gradually become standard at the infrastructure layer.

Billing: Memory Is Counted at Twice Its Size, So Costs Cannot Be Judged by Disk Alone

Alibaba Cloud has announced the following billing rules:

Snapshot storage usage = Memory size × 2 + Disk size

Cost = Snapshot storage usage × Disk unit price × Usage duration

The disk unit price is RMB 0.0021 / GiB / hour in mainland China and RMB 0.001672 / GiB / hour overseas.

The most important point here is that the billable storage space for a Snapshot is not equal to the sandbox’s disk size. The memory size is first multiplied by 2 and then added to the disk size. This reflects the resource cost of full-state snapshots, and also means that long-term retention of snapshots for Agent sandboxes with large amounts of memory may cost more than expected.

For a simple example, if a sandbox is configured with 8 GiB of memory and a 50 GiB disk, its billable Snapshot space is:

8 × 2 + 50 = 66 GiB

At the mainland China price, the hourly cost is approximately:

66 × 0.0021 = RMB 0.1386 / hour

If it is retained continuously for 30 days, using an estimate of 720 hours, the cost is approximately RMB 99.79. If the sandbox is configured with 32 GiB of memory and a 100 GiB disk, the billable space is 164 GiB, costing approximately RMB 0.3444 per hour, or approximately RMB 247.97 for 30 days of retention.

A single snapshot may not appear expensive, but Agent platforms often retain multiple versions at the same time: one at the start of a task, one after a tool call, one for each different exploration branch, plus test environments and leftovers from failed tasks. The number of snapshots can grow quickly. For sandboxes that need large amounts of memory to run browsers, code interpreters, or multiple tool services, costs will accumulate rapidly as the number of snapshots and retention periods increase.

Snapshot is therefore better suited to lifecycle-based task management than to being treated as an unlimited archive. After a task is completed, retain only key checkpoints needed for regression testing or auditing; temporary branches and snapshots generated by failed tasks should have cleanup policies configured.

What Actually Changes for Agent Developers

In the past, resuming an Agent from a checkpoint generally depended on the application saving its own state. Developers had to persist conversation context, tool-call records, file changes, task queues, and various intermediate variables separately, then reassemble them during restoration. This approach is flexible, but costly to implement, and it is difficult to cover every aspect of runtime state.

Full-state snapshots provide another approach: the application layer saves business state, while the infrastructure layer saves the execution environment. When the two are combined, an Agent can resume from a location closer to the actual execution scene.

This does not mean application-level state management can be completely omitted. External databases, third-party API calls, message queues, and cloud file systems may not roll back along with a sandbox snapshot. If an Agent has already written to an external system before a snapshot is created, executing the operation again after restoration may result in duplicate writes. Irreversible operations such as payments, sending emails, submitting code, or creating cloud resources still require idempotent design and operation logs.

In other words, Snapshot can freeze the state inside a sandbox, but it cannot automatically freeze the world outside the sandbox. Developers need to clearly distinguish between two types of data:

• Runtime state inside the sandbox that can be restored with the snapshot, such as processes, memory, temporary files, and local services.
• Side effects outside the sandbox that will not be rolled back automatically, such as database writes, remote commits, message delivery, and third-party service calls.

Without this awareness of the boundary, second-level restoration may instead amplify the risk of duplicate execution. This is especially true in multi-branch parallel cloning scenarios: every cloned instance continues running from the same state, so external side effects must have a unique request ID, an idempotency key, or an isolated target.

The Value of Parallel Cloning May Be Greater Than Simple Restoration

“Second-level restoration” solves the waiting problem, while “parallel cloning” solves the problem of exploration efficiency.

Take a coding Agent as an example. The main task can first scan the repository, analyze dependencies, and prepare the testing environment, then create a Snapshot. Next, multiple cloned sandboxes can try different fixes: one can modify database queries, another can adjust the caching strategy, and a third can focus on running regression tests. Developers do not need to reinstall the environment for each path or load the context from scratch.

This capability is equally valuable for browser Agents and research Agents. A snapshot can preserve an already logged-in browser environment, downloaded materials, and completed preliminary analysis, after which multiple branches can verify different hypotheses. For tasks that require extensive trial and error, the savings involve not only startup time, but also repeated model calls and tool calls.

However, parallel cloning also introduces resource and governance issues. The more clones there are, the greater the consumption of CPU, memory, network resources, and external API quotas. If every branch can write to the same working directory or access the same production credentials, isolation risks will also increase. Snapshot is therefore best used together with quota controls, credential isolation, task timeouts, and automatic reclamation mechanisms.

Snapshots Created Before Commercialization Will Also Begin Incurring Charges

Alibaba Cloud specifically reminds users that Snapshots created before commercialization takes effect will also officially begin incurring charges at 00:00 on September 7, 2026.

This means developers cannot focus only on snapshots created after September 7. Resources previously used for testing, stress testing, or feature verification will also incur charges after commercialization begins if they are still retained. Before launch, teams should review their snapshot inventory, delete resources that are no longer in use, and confirm which snapshots genuinely need to be retained long term.

At a minimum, the following items should be checked:

1. Are there Agent tasks that have already ended but still retain snapshots?
2. Have multiple snapshots with similar contents been repeatedly created for the same environment?
3. Are there Snapshots left over from test accounts, temporary projects, or decommissioned services?
4. Should each snapshot have a clearly defined retention period and automatic cleanup rule?
5. Will the restored instance repeat external write operations?

If a team incorporates Snapshot into its production workflow, it is best to record the task ID, code version, dependency version, creation time, and purpose associated with each snapshot at the same time. Otherwise, as the number of snapshots increases, they will quickly become a collection of runtime assets that no one dares to delete and no one can clearly explain.

Assessment: A Key Missing Piece in Agent Cloud Infrastructure, but Not Free Performance Magic

The significance of Alibaba Cloud’s commercialization is that Cloud Sandbox is evolving from an “isolated execution environment” into an “Agent runtime platform that can be paused, restored, and forked.” For developers who need long-running tasks, browser operations, code execution, and multi-path trial and error, Snapshot can indeed reduce the waste caused by cold starts and environment reconstruction.

However, its value depends heavily on the type of task. For short-lived, stateless Agents that can complete in a few seconds, using snapshots may instead increase management complexity. Only when environment initialization is expensive, task execution is long, or the same intermediate state needs to be reused multiple times will the snapshot cost more easily be offset by the saved startup time and reduced cost of repeated calls.

In terms of billing, counting memory at twice its size is a point developers must pay close attention to. When evaluating costs in the future, it is not enough to look only at disk capacity; “memory size × 2 + disk size” must be calculated as a whole. For browser and code sandboxes that require large amounts of memory, the number of snapshots, retention duration, and ability to clean them up automatically will directly determine whether this feature is cost-effective.

Overall, Snapshot is worth watching, but it is more like a foundational capability that needs to be incorporated into architectural design than an acceleration button that automatically delivers benefits when switched on. After Alibaba Cloud completes commercialization on September 7, the questions developers will actually need to validate are threefold: whether restoration speed is stable, how usable snapshots are under high-concurrency cloning, and whether the initialization costs saved in real workflows can cover the storage fees.

For development teams that use OpenAI Hub to uniformly call models such as GPT, Claude, Gemini, and DeepSeek, the model-calling layer can retain an OpenAI-compatible interface, while sandbox snapshots handle the task execution environment. Together, the two allow model routing, tool execution, and checkpoint-based resumption for long-running Agents to be governed separately, reducing the pressure to put all state into a single application service. The final outcome will still depend on task orchestration, external side-effect controls, and resource reclamation strategies—not merely on the speed of the snapshots themselves.

Timeline

• August 25, 2026: Alibaba Cloud announces that Cloud Sandbox Snapshot will begin commercial billing.
• 00:00 on September 7, 2026: Snapshot officially begins billing.
• At the same time: Snapshots created before commercialization that are still retained will also be included in the billing scope.
• Mainland China price: RMB 0.0021 / GiB / hour.
• Overseas price: RMB 0.001672 / GiB / hour.

What developers should do now is not blindly create snapshots, but first manage snapshots as runtime resources with a lifecycle: when to create them, how many times to restore them, how many copies to make, and when to delete them should all become part of the Agent platform’s resource strategy.