A quantum computer's raw qubits are unreliable, error-prone, noisy. To get one qubit you can actually trust, a "logical" qubit, you have to bundle dozens or hundreds of the noisy physical ones together and continuously error-correct them. Every hardware team, algorithm designer, and investor evaluating quantum computing eventually asks the same question, and it has an exact answer: given how error-prone your hardware actually is, and an algorithm that needs a certain number of these reliable logical qubits running for a certain number of steps, how many raw physical qubits do you actually need, and how long will the whole thing take to run.
Get this number wrong and the consequences aren't abstract. A startup pitching a five-year path to a useful quantum computer, when the honest math says fifty, isn't lying, they may genuinely not have run the calculation. An investor who takes the pitch deck's qubit count at face value can be off by two orders of magnitude and never know it until the money's gone. A hardware team sizing a chip against the wrong error-correction overhead can miss its own budget by 100x. This number is the single most-cited back-of-the-envelope calculation in fault-tolerant quantum computing precisely because getting it wrong is expensive and easy to do quietly.
The math itself is standard and well established. The tools that compute it are not. They're either heavyweight frameworks that need a whole toolchain installed to answer one question, or the formula is buried inside a chemistry package built for something else entirely. There was no small, exact, transparent tool that just answered the question. So we built one.
The number that decides everything
The surface code is the leading way to do this bundling, and its entire behavior hinges on a single number: the threshold.
The logical error rate per correction cycle follows the standard approximation from Fowler et al. (2012):
P_L ≈ A · (p / p_th) ^ ((d + 1) / 2)
where p is your hardware's physical error rate, p_th is the threshold (about 0.57%, Fowler's circuit-level value), and d is the code distance, roughly how much redundancy you're throwing at the problem.
Here's the part that surprises people who haven't sat with this formula before. Below threshold, increasing the code distance suppresses the logical error rate exponentially. More qubits genuinely buy you more reliability. Above threshold, increasing the code distance makes things worse, not better. No amount of error correction helps until the hardware itself improves. Adding redundancy to a system that hasn't crossed the threshold doesn't stabilize it. It amplifies the noise you're trying to correct.
That's not an edge case. That's the entire reason the threshold theorem is the number every roadmap in this field is actually built around, and it's why "just add more qubits" is sometimes the correct engineering answer and sometimes the exact opposite of it, depending entirely on which side of 0.57% your hardware sits.
What a reliable qubit actually costs
A rotated surface code of distance d uses roughly 2 · d² physical qubits per logical qubit. The cost is quadratic, which is the real reason reliability is expensive: pushing the logical error rate down by another order of magnitude doesn't cost you a little more hardware, it costs you the square of a little more.
For a full algorithm needing Q logical qubits running C cycles, the total error is bounded by Q · C · P_L. Given a target total error, the tool works backward: find the smallest odd distance that meets the per-cycle budget, then report the total physical qubit count, the runtime, and the space-time volume.
Run it on a single logical qubit at a physical error rate of 0.001 with a target logical error of one in a billion, and the answer comes back as a code distance of 21, an achieved logical error of 4.85e-10, and 882 physical qubits per logical qubit. Run it on a full algorithm, 100 logical qubits over a billion cycles, and you get a code distance of 31 and a total physical qubit count of 192,200. Those aren't estimates pulled from a chart. They're the exact output of the same closed-form arithmetic every published paper in this space cites.
To make that concrete: 882 physical qubits, just for one reliable logical qubit at a billion-to-one error rate, is more than five of IBM's current 156-qubit Heron production chips combined. The full algorithm's 192,200 physical qubits runs roughly 170 times larger than IBM's own Condor, the largest gate-model superconducting chip anyone has built to date at 1,121 qubits, and it's still bigger than the roughly 100,000-qubit system IBM's own public roadmap targets for Blue Jay, its most ambitious announced machine, not expected until 2033. The formula isn't describing a hypothetical inconvenience. It's describing hardware that doesn't exist yet, on any currently announced roadmap.
Checked against a real chip, not just against itself
A tool like this is worthless if it only agrees with its own assumptions. So the test suite checks it against something external: Google's actual published Willow chip results. A distance-7 rotated surface code, by this tool's formula, uses approximately 100 physical qubits. Google's own distance-7 memory experiment, published in Nature in 2025, used 101.
That's the number that matters more than any of the closed-form math on its own. The formula isn't just internally consistent, it lands within one qubit of a real, physically built, published quantum memory. Fourteen tests bind the rest of the behavior to the field's known results: logical error falling monotonically with distance below threshold and rising above it, no effect at threshold itself, the widely cited mid-tens distance and roughly-1000-qubits-per-logical figure at the common 10⁻³ physical error, 10⁻⁹ target regime.
The constants stay visible on purpose
The literature actually uses more than one exponent convention for this formula, because different papers fit their prefactor and threshold slightly differently. Most tools pick one and hide it. This one exposes the prefactor and the threshold as documented, overridable parameters, defaulting to Fowler's published values, so you can match whichever paper you're citing instead of silently inheriting someone else's assumption.
That transparency was a deliberate design choice, not a missing feature. A tool that hides its constants behind one magic formula is asking you to trust a number without showing you where it came from. A tool that shows you the constant and lets you swap it is asking something more honest: verify this against the source you actually care about, don't just believe it because the tool says so.
What it refuses to claim
The README says this directly, and it's worth repeating rather than softening: these are the standard surface-code approximations the field cites, not exact hardware truth. Real qubit counts depend on layout, decoder performance, connectivity, magic-state distillation, and hardware specifics no closed form captures. This is an order-of-magnitude planning tool, a feasibility check, a teaching reference. It is explicitly not a substitute for full circuit-level simulation, and the README says exactly where to go for that instead, Stim, PyMatching, the Azure Quantum Resource Estimator.
Within that stated scope, the arithmetic is exact and reproducible. Outside it, the tool tells you plainly that you've left the territory it can speak to, instead of quietly producing a number that looks equally confident either way.
Where this actually gets used
Hardware roadmapping: how many physical qubits does a target algorithm need at your team's current error rate. Algorithm feasibility: is this even runnable on near-term hardware, or is it a decade away. Technical due diligence: sanity-checking a quantum startup's qubit-count and timeline claims against the same formula the whole field cites, rather than taking the pitch deck's number on faith. Teaching: a transparent, testable reference for the threshold theorem that a student can actually read the source of.
The pattern by now should be familiar if you've read anything else we've built. A tool is trustworthy when it's honest about the edge of what it knows, states its assumptions in the open, and gets checked against something real rather than just against itself. That's true whether the domain is solar telemetry, legacy financial systems, or the physical qubit count on a chip that doesn't exist in most labs yet. The domain changes. The discipline doesn't.
The tool is live on GitHub under MIT: github.com/Tech4Biz-Solutions-Pvt-Ltd/qec-overhead. If you're working on QEC resource planning, decoder or control hardware, or need a custom model for a quantum-systems problem, get in touch.
Top comments (0)