Randomness is a useful shortcut in computing. A few coin flips can help a memory-starved algorithm explore possibilities without recording every step. For decades, theoretical computer scientists have asked whether those random bits provide genuine extra power when an algorithm has almost no working memory.
OpenAI says the answer is no.
In a 108-page manuscript dated September 23, 2026, OpenAI claims to prove L = RL = BPL, the central equality behind the derandomization of logarithmic space. If the argument survives independent scrutiny, every polynomial-time randomized algorithm using logarithmic workspace and bounded error can be replaced by a deterministic algorithm with the same asymptotic workspace limit and polynomial running time.
It’s a striking theoretical claim, not a promise of faster software. The challenge is removing randomness without spending more memory.
Table of Contents
1. Derandomization of Logarithmic Space: The Claim at a Glance
Derandomization of Logarithmic Space: Key Research Facts
| Key Fact | What It Means |
|---|---|
| Research | Exact Derandomization of Logarithmic Space: L = RL = BPL |
| Author and Date | OpenAI, September 23, 2026 |
| Public Release | Included in OpenAI’s October 6 mathematics collection |
| Central Claim | L, RL, and BPL describe the same decision problems |
| Resources Preserved | O(log n) working space and polynomial running time |
| Main Method | Estimate acceptance probabilities, then choose deterministically |
| Current Caution | A public manuscript is not the same as an independently validated proof |
In plain language, coin flips don’t add decision-making power for a tiny-memory computer with polynomial time and a fixed error margin.
The result concerns specific complexity classes, not every randomized program. It preserves an asymptotic memory bound, not actual implementation speed. And the paper’s word “exact” refers to the proposed equality of classes, not to calculating every probability with infinite precision.
2. L, RL, and BPL: Three Ways to Compute With Tiny Memory
A logarithmic-space algorithm uses O(log n) writable bits for an input of length n. It can reread input but cannot use it as a writable notebook. Even a counter consumes workspace.
Derandomization of Logarithmic Space: L vs. RL vs. BPL Explained
| Class | How It Computes | Correctness Requirement |
|---|---|---|
| L | Deterministic choices | Always returns the correct yes/no answer |
| RL | Random choices, one-sided error | Never accepts a no-instance, accepts a yes-instance with probability at least 1/2 |
| BPL | Random choices, two-sided error | Accepts yes-instances with probability at least 2/3 and no-instances with probability at most 1/3 |
All three models have logarithmic workspace and polynomial-time bounds. In RL and BPL, probabilities come from fresh random choices. L makes no random choices.
The BPL complexity class allows more kinds of mistakes than RL, so the natural inclusions are L ⊆ RL ⊆ BPL. OpenAI’s claimed equality would collapse those inclusions into equality. Any language decided under the BPL guarantee would also have a deterministic logarithmic-space decider.
Logarithmic space isn’t logarithmic time. An algorithm may repeatedly scan input while remembering few positions, performing many steps with little workspace.
3. What OpenAI’s Theorem Actually Promises
The manuscript’s headline theorem is short enough to fit on a T-shirt: L = RL = BPL. The supporting claims are more revealing.
First, the paper describes a deterministic algorithm that approximates the acceptance probability of a randomized logarithmic-space machine. An acceptance probability is the fraction of possible random executions that end in “yes.” For a bounded-error decision algorithm, it is enough to estimate that probability accurately enough to tell the two promised cases apart.
Second, the approximation is more general than that decision trick. The manuscript claims inverse-polynomial accuracy while retaining logarithmic workspace and polynomial time for any fixed accuracy exponent. Its parameterized statement uses O(log(n + 2) + q) space and time polynomial in n multiplied by an exponential factor in the requested precision q. More precision isn’t free.
The estimator also applies when an acceptance probability lies between the usual decision thresholds. That does not create a correct yes/no answer without a promised gap. It means the numerical result is broader than the decision theorem built on top of it.
Third, the paper gives an effective compiler. With a description of a randomized machine and valid supplied bounds on its time and space use, it claims a terminating procedure can produce a deterministic decider and explicit resource bounds. The compiler does not magically determine whether an arbitrary program obeys those supplied bounds.
That distinction matters: existence and an effective construction are different achievements.
4. Why This Problem Resisted Decades of Work
The question grew from randomized graph connectivity. A random walk navigates without keeping a large search history. Could a deterministic machine match that power within the same memory budget?
Researchers made substantial progress on special cases. Omer Reingold established deterministic logarithmic-space algorithms for undirected connectivity. That was a landmark, but undirected graphs have structure that arbitrary randomized computation graphs need not share.
Other work moved closer to the general case without reaching the same combination of time and memory guarantees. Noam Nisan’s pseudorandom-generator approach showed how short seeds can stand in for much longer random sequences. Saks and Zhou obtained a deterministic simulation using O(log^(3/2) n) space. Later research sharpened tradeoffs and improved particular bounds.
The difference between logarithmic and slightly larger space may look fussy. In complexity theory, a little extra memory is still extra memory.
5. A Simple Example: Random Decisions, Minimal Workspace
Imagine a tiny program that flips two fair coins and accepts unless both land tails. Three of its four possible coin sequences produce acceptance, so its acceptance probability is 3/4.
A deterministic analyst could list the outcomes, count the accepting ones and return the probability. With two coins, that’s easy. The challenge comes with polynomially many steps and fresh random bits. Recording every sequence, or even a large sample, would overwhelm logarithmic workspace.
Consider an input with one million positions. Naming a particular position takes roughly 20 bits. That isn’t an algorithm’s total budget: counters and temporary calculations also count. It does show why pointers can fit in logarithmic space even when a complete execution history cannot.
OpenAI’s proposal is not the trivial two-coin calculation scaled up. The target is learning enough about acceptance probability without storing every random path.
6. Inside the Proof: How the Random Bits Disappear

The proof doesn’t replace coin flips with one favorite sequence. It models the computation mathematically, builds estimators, then examines a controlled family of compact descriptions.
6.1. Turn a Randomized Machine Into a Graph
The authors represent a machine’s possible configurations as vertices in a time-layered graph. Edges carry transition probabilities. Because each edge moves time forward, the corresponding transition matrix has a finite inverse expansion.
From this representation, the machine’s acceptance probability becomes a value associated with its starting configuration. The graph may be large, but naming one vertex takes logarithmically many bits, far less than storing the graph.
6.2. Build a Correction-and-Copy Hierarchy
Next comes the most unusual ingredient. A sequence of correction and copy operations progressively makes the remaining transition weights small while transporting probability information into accumulated rewards.
The correction step redistributes contributions algebraically. The copy step spreads large transition entries among controlled copies of vertices. Relevant vertex identifiers still fit within logarithmic space.
After logarithmically many stages, the accumulated reward at a designated copy of the starting configuration is close to its original acceptance probability. The full matrices define what must be calculated, but the algorithm does not store them.
6.3. Estimate Without Saving Everything
To estimate that reward, the construction uses sparse, sample-dependent tables, conditional averaging and short fingerprints. The analysis explicitly handles dependent estimates.
The key claim is that a sufficiently large fraction of compact estimator descriptions give good approximations. Each description occupies only O(log n) bits, and evaluating it always terminates within the same workspace bound, even when that particular estimate is inaccurate.
6.4. Enumerate the Descriptions and Take a Median
Here is the derandomizing move. If most estimates are close to the right answer, their median is close too. The deterministic simulator enumerates the short descriptions, evaluates their estimates and finds the median without keeping the entire list in memory.
Repeated passes trade time for storage. Logarithmic description lengths yield polynomially many candidates, each polynomial-time evaluable. Conceptually, the simulator can revisit the candidates and count how many estimates lie below a given value. It need not preserve a sorted array of answers.
That is how the argument aims to remove randomness without replacing it with a forbidden memory-hungry search.
For BPL, a sufficiently accurate median can be compared with 1/2, separating acceptance probabilities of at most 1/3 from those of at least 2/3. This is the proposed bridge from probability estimation to a deterministic yes/no decision.
7. The Hidden Challenge: Every Bit of Workspace Counts

The most treacherous part of logspace derandomization is accounting. It is easy to describe a recursive estimator that “uses small memory” at each level while overlooking the stack of suspended calls above it. Add a few counters, saved graph locations and numerical registers, and the budget is gone.
OpenAI’s manuscript devotes substantial machinery to exactly this issue. It uses compact fingerprint comparisons to avoid retaining full endpoint identifiers at every recursive level. It requests numerical results a digit at a time. Graph traversals recover information when needed rather than preserving a large trail of addresses.
The controller also assigns decreasing resource allowances to nested calls. Local storage costs are charged against the reductions in those allowances, so the costs telescope along the active call chain instead of accumulating unchecked.
That bookkeeping is central. A proof that derandomizes the answer while secretly using O(log² n) space would not establish L = BPL. For this problem, careful bookkeeping is the mathematics.
8. Why Pseudorandom Generators Weren’t Enough
Pseudorandom generators create sequences that look random to a limited class of algorithms using a shorter seed. They’re a major tool in space-bounded derandomization, but “short” has to be measured against the available memory.
For a logarithmic-space computation using polynomially many random bits, Nisan’s classic construction produces a seed of O(log² n) bits. That’s dramatically smaller than the original random tape, but storing the seed is still beyond the O(log n) target. Enumerating all seeds also creates an unfavorable running-time bound in the straightforward approach.
This explains the appeal of the OpenAI derandomization method. Rather than rely only on a pseudorandom sequence short enough to enumerate, it proposes a new route through acceptance-probability estimates and compact deterministic enumeration.
The paper builds on decades of small-space algorithms, random walks, matrix computations and probability estimation. Its shoulders are crowded.
9. Verification: Has the L = RL = BPL Proof Been Checked?
This is the question readers should ask before repeating the headline as settled mathematics.
OpenAI published the manuscript in its October 6, 2026 mathematics release, alongside many other results from an internal frontier model. The company also shared Lean formalizations for a number of results. Lean is a proof assistant that can check formal statements and their logical derivations against explicitly defined rules.
But a badge attached to another paper does not validate this one. As of October 8, 2026, the public result catalogue does not show a Lean-formalized main theorem for family 103, the logarithmic-space derandomization result. The manuscript’s appearance in a repository is not itself an independent, complete proof check.
The formalization catalogue includes the manuscript among its source papers, but that listing should not be confused with a linked Lean target checking its main theorem.
Researchers must check the model, technical lemmas, live-register accounting and reproducibility of the arguments.
The discussion among computer scientists has rightly focused on those questions. The appropriate verdict for now is precise: OpenAI has published a detailed proof claim, and its full independent verification should not be assumed.
10. What Would This Change for Real-World Computing?
If validated, the theorem would close a fundamental gap in our understanding of randomized logarithmic space. It would say that bounded-error randomness offers no additional decision power under the specified tiny-memory, polynomial-time limits.
For developers, that doesn’t mean faster graph libraries or a production-ready compiler. A polynomial-time simulation may have large constants and an impractical exponent. Its theoretical guarantee says little about the wall-clock performance of an optimized randomized implementation.
It also assumes the theoretical model of a read-only input and carefully counted writable workspace, not a typical application’s memory management.
Still, theoretical limits shape algorithm design. They clarify which resources are essential and which are conveniences. The paper’s constructive features, including acceptance-probability approximation and deterministic witness generation under stated promises, could also give researchers techniques to investigate in other settings.
The useful engineering question is not “Can I remove every random number generator?” It’s “Does this proof suggest a simpler deterministic method for the specific constrained computation I care about?” That requires algorithms and experiments, not just an equality.
11. What This Result Does Not Prove
The mathematics has boundaries.
L = RL = BPL would not establish P = NP. It does not settle L = NL, which concerns nondeterminism rather than bounded-error randomness. Nor does it by itself prove the broader equality P = BPP, where polynomial-time randomized machines are not restricted to logarithmic working space.
It also does not say randomness disappears from simulations, sampling, machine learning or cryptography. Many tasks are about producing random-looking outputs or sampling distributions, not deciding a language with a bounded error gap. Those are different questions.
Finally, “exact derandomization” should not be read as exact evaluation of every acceptance probability. The paper approximates probabilities to a controlled accuracy, which is enough to make a correct deterministic decision when the accepted error gap is promised.
A good breakthrough expands what we can rigorously claim. It doesn’t need us to enlarge the claim for it.
12. Why the Derandomization of Logarithmic Space Matters
OpenAI’s manuscript proposes an answer to a stubborn question: when memory is measured in mere logarithms, are random bits an essential computational resource or just a useful shortcut? Its answer is sweeping, and its construction is much more substantial than a slogan about L = RL = BPL.
The next milestone is independent scrutiny, especially of the estimator and the painstaking memory accounting. If those arguments hold, derandomization of logarithmic space will become a landmark result in complexity theory. Even revisions would leave concrete claims to test.
Read the original OpenAI manuscript, follow the verification debate, and visit Binary Verse AI for rigorous, readable explanations of what the latest AI research actually establishes.
1. What is the RL complexity class, and how does it differ from L and BPL?
RL contains decision problems solvable using randomized logarithmic space and polynomial time with one-sided error: incorrect acceptance of a no-instance has probability zero. L uses deterministic logarithmic space, while BPL allows bounded two-sided error. OpenAI’s manuscript claims that all three classes are equal.
2. What is logarithmic space complexity, and how is it different from logarithmic time?
Logarithmic space means an algorithm uses O(log n) working memory for an input of size n. It can repeatedly read the input without storing it entirely. Unlike logarithmic time, which limits execution steps, logarithmic space limits memory consumption; an algorithm may still require polynomial running time.
3. How does derandomization turn a randomized algorithm into a deterministic one?
Derandomization replaces random choices with a deterministic procedure while preserving the relevant correctness guarantees. OpenAI’s proposed construction approximates a machine’s acceptance probability using carefully controlled estimators and deterministic enumeration, rather than simply storing and testing every random sequence.
4. Has OpenAI’s L = RL = BPL proof been independently verified or formalized in Lean?
As of October 8, 2026, the publicly indexed OpenAI catalogue does not identify a Lean-formalized main result for family 103. The manuscript is available, but its publication alone does not establish independent verification. Expert scrutiny and any subsequent formalization remain important*
5. Will OpenAI’s logarithmic-space derandomization result make real-world algorithms faster?
Not necessarily. The claimed result concerns the ability to remove randomness without exceeding logarithmic workspace while retaining polynomial running time. It does not guarantee faster execution or a practical replacement for every randomized algorithm. Its immediate importance would be theoretical rather than a demonstrated software speedup.
