Drums is a question, not a product. The question is whether many computer-use training attempts can share one running computer, each with its own private state, at a lower cost per useful attempt than giving each one its own virtual machine. We do not know the answer. This note states the question precisely so that the rest of the site can be checked against it.
The hypothesis, 2026-10-15 form
This is how the baseline document stated it:
Many computer-use RL environments can share one already-booted operating system and application runtime, each with private copy-on-write state, at a lower end-to-end cost per valid rollout than one virtual machine per environment, with zero observed cross-contamination between environments, measured next to a positive control that fired.
The same document opened with a framing we keep:
The need for many interactive environments is real in published systems. The case that Drums must exist is not established. Shared runtimes are already research prior art; microVMs already have sharing and reclamation paths; cheap Linux sandboxes and synthetic environments set a harder competitive bar. The missing number is end-to-end cost per verified useful rollout, including inference, failures and integration work.
The hypothesis, 2026-10-23 narrowed form
After a full read of the papers in the prior-art map (see prior art), we withdrew every claim that a mechanism was new. The current statement has three parts.
| Part | Statement | Status |
|---|---|---|
| Withdrawn | "VM-free desktop" and "shared runtime plus copy-on-write branching, including a mid-trajectory fork" are published mechanisms (CUA-Lite, CUA-Sandbox). Drums claims neither as new. | withdrawn |
| Narrowed | A licensed, runnable integration (VM-free desktop, private state capsules, an RL-training socket) with better measured economics than the strongest runnable baseline. An engineering-and-evidence claim, not an invention claim. | narrowed, defensible position, unmeasured |
| Candidate bet | Desktop state branching integrated into training: rollouts served from a branch that shares an executed prefix. The mechanism is published; its training-integrated economics are untested in every source we reviewed. | candidate bet, hypothesis not finding |
The macOS form of the same bet (experiment 1, designed 2026-10-20) is narrower still: on one Mac Studio, how many independent environments run with no VMs, at what cost per valid rollout, with zero observed cross-contamination, next to the same number from one Linux VM on the same Mac running N virtual displays. The fallback answer is written into the design in advance: "macOS N_max = 0 on build X, reason Y; Linux on the same Mac gives N." See desktop isolation on macOS.
What "valid rollout" means
A rollout is one attempt at one task by an agent in one environment, from reset to final state. A rollout is valid when all of the following hold:
- The reset was verified before the first action: the work tree matched the golden manifest, the clipboard was empty, no leftover application was running.
- Every action was applied under the correct generation number. An action from a stale generation was refused, and the log shows it was never applied.
- Nothing timed out.
- The verifier ran and returned a result.
- Every isolation check that was active during the rollout stayed clean.
A verifier that says "task not done" is a task failure, and the rollout is still valid. An environment that could not be used (dirty tree, black screenshot, stale generation applied, verifier unreachable, a contamination event) is an environment failure: it gets its own line in the record, with a reason, and it is never scored as reward zero. See the rollout loop for why that distinction is the whole point.
What we are not claiming
- Not that Drums is faster or cheaper than QEMU/KVM, containers, or any published system. No matched comparison has been run (see benchmarks).
- Not that any mechanism here is new. The mechanisms are published prior art; see the corrections in prior art.
- Not that sharing is a security boundary. One kernel, one window server, one root. We measure accidental cross-talk over stated environment-hours; we do not defend against a hostile agent.
- Not that the shared runtime restores faithfully today. On Linux, a POSIX lock on a mapped file is lost across a CRIU restore and that failure is unresolved (EXP-009).
- Not that any isolation number exists. Zero contamination is printed only next to a positive control that fired, and none has fired (EXP-003).
- Not model quality, not an RL result, not a license opinion, not a hosted service.
- Not that the market exists at a size that matters. Several of the eight falsification questions in open questions point the other way.