One-Tape Computations Can Be Simulated in Two-Fifths-Power Space
An OpenAI preprint argues that a fixed deterministic machine with one writable tape, running for at most \(T\) steps, can be simulated in roughly \(T^{2/5}\) space, up to polylogarithmic factors. The bound improves on the square-root exponent for this setting, but the simulator may use vastly more time and need only determine the machine’s state and whether it has halted—not reproduce its final tape. The proof gets the space reduction by checking and recomputing local portions of the run rather than storing its full history.

The bound concerns the outcome, not the full computation
A deterministic machine with one writable tape can be simulated using about (T^0.4) times a polylogarithmic factor in (T+2) working space, according to the manuscript’s theorem. This improves the square-root exponent for the specified one-tape setting. The trade-off is time: the simulator may take enormously longer than the original computation. It need not produce the final tape; it determines the control state and whether the machine has halted by a given time cap.
The distinction is between retaining a run and reconstructing enough of it to answer a particular question. A computation lasting a trillion steps need not be remembered as a trillion-step history if the simulator can recompute local parts when needed. The theorem is a memory bound, not a faster way to compute.
The model’s restrictions are part of the claim. The machine is fixed and deterministic, with finitely many states and symbols, one writable tape and head, and a fixed number of read-only heads. Heads move at most one cell per step and start at fixed origins. The input and a binary time cap (T\ge 2) are supplied; input storage is not counted as work space. Initial tape contents cannot depend on (T), and a fixed accessor must provide every initial symbol within distance (T) of each head’s origin in polylogarithmic space—including symbols needed in speculative local runs.
A shifted partition guarantees a low-crossing boundary
The proof’s first step is to divide the writable tape into blocks of width (b). A visit to a block lasts until the head leaves it, the machine halts, or the time cap is reached. The simulator will replay visits to individual blocks rather than store the entire tape history.
The boundary placement matters. There are (b) possible offsets for the block partition. For any move between neighboring cells, exactly one offset puts a boundary between those cells; a stationary move crosses none. The source’s 13-step example illustrates the count for four offsets:
| Offset | Crossings |
|---|---|
| 0 | 7 |
| 1 | 2 |
| 2 | 2 |
| 3 | 2 |
Summing the crossing counts over all offsets therefore counts each moving step exactly once, for at most (T) crossings in total. At least one offset has no more than (T/b) crossings, and thus at most one plus (T/b) visits.
The simulator does not know which offset is best in advance, so it tries offsets. The averaging argument applies to every allowed trajectory; it is not an inference from a favorable example.
Local replay certifies a proposed transcript
For a chosen partition, the simulator can propose a sequence of controller records: state, head position, elapsed time, and whether the run has terminated. Each record identifies the writable block involved in the next visit. To check a block, the simulator starts with that block’s initial contents, scans the proposed records, and replays only the visits that select it. It compares each computed outgoing record with the proposal and retains the block’s updates for later visits to the same block.
If every block’s checks pass, the proposed records must describe the real run. The reason is induction: if the records so far match the real run, the next incoming controller state selects the correct block. Its replay has exactly the updates from its earlier visits, and determinism fixes the next record. The block check forces the proposal to match that record. The convention at the boundary of a visit is important: the machine writes the old block before moving away.
Keeping the whole transcript would still cost too much. Instead, the construction groups (b) visits into an epoch. The epoch history takes about (b\log T) bits. It also refers to the blocks’ contents at the epoch’s start, but these are dependencies to be reconstructed, not a stored array of checkpoints.
Each epoch is divided into rounds of (k) visits, with (k) about (\sqrt b). For a round, the simulator enumerates candidate suffixes of (k) controller records. A candidate survives only if every block’s replay accepts the proposed epoch prefix. On the true inputs, exactly one suffix survives. The remaining challenge is to evaluate this large search without accumulating its intermediate histories in memory.
Recomputation works only with a careful storage contract
The manuscript’s technical evaluator turns finite Boolean checks into homogeneous polynomials over a finite field and uses interpolation to recover the desired value. Its stated contract is exact: add a scaled true word to one chosen register while restoring every other register, even when a register begins with unrelated contents. That lets a child computation reuse a small pool of storage, including a partly filled output, and lets a reverse call cancel a temporary change.
For the application, the paper uses three vector registers along with reusable scratch space and a stack. The account here omits the polynomial and register-invariant proof; the point is not that needed information disappears, but that it can be recomputed while other storage is restored as required.
The order of recursive calls controls the stack cost. An earlier-history call happens outside the loop over candidate suffixes, so a large candidate need not be retained across it. A call to reconstruct an epoch-start block does retain the candidate, costing about (k\log T) bits. But that block depends only on the preceding epoch. Along one dependency path, within an epoch, there are at most (k) short history edges and one such retained candidate. With about (1+T/b^2) epochs, the stack cost is roughly ((1+T/b^2)\sqrt b), apart from logarithmic factors.
Balancing the costs gives the two-fifths exponent
Ignoring logarithms and rounding, the working-space terms are approximately (b+\sqrt b+T/b^1.5). The (\sqrt b) term is smaller, so balance (b) against (T/b^1.5). This gives (b^2.5=T), or (b=T^0.4); the two main terms then have the same exponent.
The manuscript handles integer choices with (k=\lceil T^0.2\rceil) and (b=k^2), retaining polylogarithmic factors.
Two writable tapes break this factorization
The one-tape restriction is structural. With two writable tapes, a transition could inspect one bit on each and accept exactly when they agree: the accepted pairs are (00) and (11). Separate predicates on each bit cannot represent that set. If both diagonal pairs pass, each predicate must allow both bit values, which also admits the off-diagonal pairs. The block-by-block factorization used in the one-tape argument therefore does not transfer directly.
This is not an impossibility result for better multi-tape simulations. The manuscript gives a separate square-root-space comparison for a fixed number of writable tapes under the same access assumptions.
The result also does not promise to store the final tape, provide a useful running-time guarantee, or remove the logarithmic factor. If the accessor condition holds at every cap and the machine eventually halts, repeated doubling of the cap can find its outcome within the corresponding space bound. The general theorem rests on the manuscript’s evaluator proof; finite checks of examples test the illustrations, not the theorem itself. The central distinction remains: reconstructing a computation’s consequences can require less memory than retaining its full history.