BunshinRL cuts AI training memory by sharing live workspaces

The workspace behind the agent

An AI agent learning to use a browser or desktop does more than generate text. It alternates between reasoning and actions: opening a page, editing a document or clicking a control. Each training attempt needs a persistent workspace containing its applications, files and running processes.

Running many attempts simultaneously can therefore demand substantial CPU memory, separate from the GPU memory used by the model. Meanwhile, a slow tool operation can hold up an entire training batch when the training procedure waits for every attempt to finish.

In a November 2026 preprint, Yutong Huang, Vikranth Srivatsa, Alex Asch and Yiying Zhang introduce BunshinRL, a system designed to reduce both costs. Its contribution concerns training infrastructure, not a new method for making agents reason better.

Share first, copy when necessary

The underlying mechanism, BunshinFork, creates branches of a live container workspace. Containers isolate applications while sharing the host operating-system kernel.

Rather than immediately copying all application memory into every branch, BunshinFork shares unchanged memory pages. When a branch writes to a shared page, it receives a private copy. This technique, called copy-on-write, lets related attempts share their common starting state without sharing subsequent edits.

Branching a workspace requires more than duplicating files. BunshinFork briefly freezes the source, records its state and reconstructs the process hierarchy in an isolated container. It also handles files, internal communication and the graphical desktop. Writing durable snapshots to storage happens separately, so the source need not wait for all that disk work before resuming.

The implementation requires a Linux kernel module and modifications to CRIU, an existing checkpoint-and-restore system. It is therefore more than a scheduling change that can simply be switched on in any training setup.

Reuse actions, then predict the slow ones

BunshinRL builds two additional techniques on this branching mechanism.

First, it caches repeated tool-call sequences. If a training attempt follows a previously seen sequence from the same starting context, the system can reuse both the observations and the workspace state those actions produced. Matching an individual command is insufficient: the preceding sequence, tool names and arguments must match too. The model still generates its reasoning; the system avoids repeating matched tool execution.

Snapshots form a tree, with branches storing changes relative to earlier states. Selected snapshots remain in memory, while others can be reconstructed from storage or by replaying actions.

Second, a small trained classifier predicts upcoming tool calls from historical calls. BunshinRL executes predictions in a separate workspace while the main model continues reasoning. A matching prediction supplies its resulting observation and state. A mismatch causes the speculative branch to be discarded, and the actual action runs from the preceding valid state.

Because speculation itself consumes resources, the system targets historically slow attempts and long tool calls rather than speculating everywhere.

What the experiments showed

The researchers evaluated Qwen3-VL-8B using subsets of OSWorld desktop tasks and WebArena shopping-site tasks. Their setup used one H100 GPU server and a separate workspace server with 256 GB of memory. Comparisons included CRIU-based containers and AgentENV microvirtual machines; the memory comparison replayed the same recorded trajectories.

On OSWorld, BunshinRL reduced peak workspace memory by 30% relative to CRIU and 26% relative to AgentENV. On WebArena, it reduced peak memory by 43% relative to AgentENV. CRIU could not fit the full WebArena batch into memory, so that comparison used a smaller CRIU batch—an important qualification when interpreting performance differences.

In a separate OSWorld comparison, adding caching and speculation to BunshinRL’s memory-sharing baseline reduced an epoch from 20.8 to 17.0 minutes, about an 18% reduction. Peak memory increased from 69 to 70 GiB. Across five training epochs, the authors report the same average rewards for the tested configurations.

Where the boundaries remain

These results do not establish universal speedups or unchanged learning behavior across all tasks. Sharing saves less as workspaces overwrite common state, and reusing stochastic tool outcomes can affect training semantics.

Most importantly, rolling back a local workspace cannot undo an action on an external service. Such effects need confinement or deferral. Containers also provide a weaker isolation boundary than virtual machines, and privileged workloads may favor the latter.

The work remains a preprint. Its experiments support a specific infrastructure opportunity: repeated agent workspaces contain reusable state, provided branching and reuse preserve the task’s execution boundaries.