Quantum computing questions, answered honestly

The free access is real and it is not a trial. IBM's Open Plan gives anyone with an IBM ID unlimited access to publicly available quantum systems with a 10-minute-per-month allowance of actual QPU time. That sounds restrictive, but most research circuits run in milliseconds of QPU time, so individual developers rarely hit the limit. Queue waits are the more practical constraint — typically 10–60 minutes on a 127-qubit Eagle system, longer on newer Heron devices.

Local simulators are free with no limits at all. Qiskit Aer, Cirq, PennyLane and CUDA-Q all install with pip and run on your own machine. Amazon Braket's local simulator is free; running Braket circuits on cloud hardware is the one place where you pay.

What you are not getting for free is a machine that solves problems your laptop cannot. Free hardware access is genuinely useful for learning, for testing that your circuit transpiles and runs, and for seeing real device noise. It is not useful for production workloads, and no free tier changes that — the limitation is physics, not billing.

The path is short. Install Python 3.9 or newer, `pip install qiskit qiskit-ibm-runtime`, create a free IBM Quantum account, paste your API token, and pick a backend. A two-qubit Bell state is about ten lines of code and returns something like {'00': 503, '11': 497} over 1000 shots.

IBM's free tier currently exposes Eagle (127 qubits), Heron r1 (133 qubits) and smaller Falcon (27 qubit) systems, though IBM regularly retires and adds machines, so check what is live rather than trusting any published list including ours.

Two expectations worth setting. First, your job goes into a shared queue — plan for minutes to hours, not seconds. Second, your results will not be clean. Real devices have two-qubit gate error rates around 0.5–1% and readout errors of 1–5% per qubit, so a circuit that should return a perfect 50/50 split will leak counts into outcomes that should be impossible. That is not a bug in your code; it is what NISQ-era hardware looks like, and learning to read those results is most of the value of running on real hardware at all.

The honest split: there are several distinct jobs hiding under "quantum computing", and they have very different entry requirements.

Using an SDK to build circuits, run them on a simulator or real device, and interpret results is a software task. If you can follow a NumPy tutorial you can follow a Qiskit tutorial. The quantum-specific concepts — superposition, entanglement, measurement, interference — are genuinely learnable from good free material without a formal course.

Designing new algorithms with provable speedups, or doing error-correction theory, is a research job and effectively requires graduate-level physics or CS. Building the hardware requires experimental physics or electrical engineering. Neither of those is where most people start.

The trap is going too deep too early. Plenty of people spend six months on quantum mechanics formalism and never run a circuit. The faster path is to build things first — a Bell state, a Grover search, a small VQE — and pull in the mathematics when a specific result stops making sense. Keep the glossary open while you work; most of the confusion is vocabulary rather than difficulty.

Statevector simulation stores 2ⁿ complex amplitudes, so memory is the binding constraint: 30 qubits needs around 16 GB of RAM. Below that, CPU simulation on a normal machine is fine. Qiskit Aer and PennyLane's lightning.qubit both handle about 30 qubits; Cirq and Braket's local simulator sit closer to 25; PennyLane's pure-Python default.qubit runs out around 20.

Where a GPU helps is speed rather than reach. On a 28-qubit GHZ circuit at 1000 shots, Qiskit Aer on CPU takes roughly 45 seconds and PennyLane lightning.qubit about 30, while CUDA-Q on an A100 finishes in around 0.8 seconds. For large circuits CUDA-Q can be 100–10,000× faster than CPU simulators, and a single GPU stretches to 34+ qubits.

If you want more qubits than statevector allows, the answer is usually a different simulation method rather than better hardware. Matrix product state simulation handles hundreds of qubits when entanglement stays low, and stabilizer simulation scales to thousands of qubits — but only for Clifford circuits, which excludes most interesting algorithms. Choose the method to fit the circuit, not the hardware to fit the method.

The recommendation is about ecosystem, not about which library is better designed. When you hit an error at 11pm, Qiskit is the one with a Stack Overflow answer already written. It also connects straight to IBM's free QPUs, so the gap between "circuit on my laptop" and "circuit on real hardware" is an API token rather than a new SDK.

PennyLane's genuine advantage is that circuits are differentiable and it interoperates with PyTorch, TensorFlow and JAX. If your goal is VQE, QAOA or quantum machine learning, PennyLane's model fits the work better and its Codebook is one of the best free interactive resources in the field. Its lightning.qubit backend is also roughly 10× faster than the default one.

The other options have narrower cases. Cirq is worth knowing if you are working with Google hardware or care about precise gate-level scheduling. Braket makes sense when you want to compare multiple vendors' hardware behind one API. CUDA-Q is for large GPU-accelerated simulation.

None of this is a permanent commitment. The concepts transfer almost completely, and porting a circuit between SDKs is a mechanical exercise — abstraction layers like HLQuantum exist precisely because the differences are mostly syntactic.

Use a simulator for almost all development. It gives you the correct answer to compare against, it runs instantly with no queue, and you can inspect the full statevector — something physically impossible on real hardware, where measurement collapses the state. Debug on a simulator; you cannot debug on a QPU.

Real hardware is where you go when the question is about noise. Two-qubit gate errors of 0.5–1%, readout misreads of 1–5% per qubit, and finite coherence times mean a circuit that is exact in simulation returns a smeared distribution on-device. That is the actual research frontier, and it is why error mitigation exists as a discipline.

The middle ground matters more than people expect: most simulators can inject a noise model, so you can reproduce device-like behaviour locally without queueing. Qiskit Aer's density-matrix and qasm methods do this well.

The comparison is also not permanent. Classical simulation keeps improving — a 2026 result reproduced Rydberg-atom-array experiments that had been thought beyond classical reach. Any claim that a quantum device has beaten classical computation is only as durable as the best classical algorithm someone has bothered to write.

Diagnose in order. First reproduce on a noiseless simulator — that separates "my circuit is wrong" from "the device is noisy". Then check shot count: statistical scatter shrinks only as 1/√shots, so a distribution that looks rough at 100 shots may be fine at 4000.

If it is device noise, the mitigation ladder goes readout correction, then dynamical decoupling, then twirling, then zero-noise extrapolation, then probabilistic error cancellation. The order matters and the costs escalate sharply — DD is free in shots and typically buys 5–20% fidelity, while PEC needs 100–10,000× more shots.

Readout mitigation is the highest-value first step. In a measured run with 5% readout error, 10.3% of counts leaked into forbidden outcomes; after mitigation that fell to 0.8%, a 13× reduction. Note that full calibration matrices scale as 2ⁿ and become impractical above about 10 qubits.

One critical warning: the size of an improvement never validates a mitigation result. Zero-noise extrapolation applied to a badly degraded signal produced an estimate of 0.581 against an exact value of 1.000 while appearing to recover 76% more signal. Published work in 2026 found negative-control "garbage" folding producing larger apparent improvements than legitimate folding. Always run controls.

The decisive difference is the pricing model. IBM's Open Plan gives free QPU access with a monthly quantum-time allowance. Braket's local simulator is free, but running on the cloud hardware it brokers costs money per task and per shot. For learning, that makes IBM the default.

Braket earns its place when hardware diversity matters. IBM only offers superconducting transmon devices. Braket fronts multiple modalities, and since no modality has clearly won — superconducting leads on gate speed and fabrication scale, trapped ions on fidelity and all-to-all connectivity, neutral atoms on qubit count, photonics on room-temperature operation — being able to run the same circuit across them is a real capability.

That diversity point generalises into career advice: do not over-specialise in one vendor's stack. The 2026 executive order on quantum benchmarking pointedly named no modality, which is a fair reading of where the field stands.

If you genuinely want both, an abstraction layer lets you write once and dispatch to either backend, which is cheaper than maintaining two implementations of the same circuit.

Concrete per-tool ceilings on CPU: Qiskit Aer around 30 qubits, PennyLane lightning.qubit around 30, Cirq around 25, Braket's LocalSimulator around 25, PennyLane's default.qubit around 20. NVIDIA CUDA-Q reaches 34+ on a single GPU.

Every one of those is an exact-simulation number, and the doubling is brutal — 40 qubits would need about 16 TB. No consumer hardware upgrade gets you meaningfully further, which is why the answer to "I need more qubits" is a different algorithm rather than a bigger machine.

Approximate and specialised methods break the ceiling in exchange for restrictions. Matrix product state simulation reaches hundreds of qubits when the circuit keeps entanglement low. Stabilizer simulation scales to thousands of qubits in polynomial time, but only for Clifford circuits — which, by the Gottesman-Knill theorem, are precisely the circuits that offer no quantum advantage. That tradeoff is the point: the circuits that are easy to simulate classically are the ones that are not worth running on a quantum computer.

For learning purposes none of this constrains you. Almost every tutorial algorithm — Bell states, Grover, QFT, VQE, QAOA — is demonstrated on fewer than 10 qubits.

Qubit count alone is nearly meaningless, and this is the clearest example of why. A headline of 1,000 physical qubits with mediocre fidelity is compatible with zero logical qubits — not few, zero. Below the error-correction threshold of roughly 1% for the surface code, adding qubits makes things worse, not better.

Above threshold the arithmetic is punishing but at least it works. Shor's 1995 code used 9 physical qubits per logical one; modern surface-code estimates run to hundreds or a few thousand, and that ratio is a function of hardware quality rather than a constant. This is why fidelity improvements compound so favourably: halving the physical error rate can quarter the logical error rate, so a 2× hardware win becomes a 4× or 8× win after encoding.

For a specific benchmark, breaking RSA-2048 needs roughly 6,200 logical qubits — which the 2019 Gidney–Ekerå estimate translated to 20 million physical qubits over 8 hours, and a 2025 refinement brought down to under a million physical qubits over under a week.

The encouraging counterweight: Google's 2024 below-threshold result on the 105-qubit Willow processor showed each surface-code distance increase roughly halving the logical error rate. That converted fault tolerance from an open physics question into a scaling and engineering problem.

The distinction exists because physical qubits decohere. Encoding one logical qubit across many physical qubits lets you detect and correct errors mid-computation via syndrome measurement, without measuring — and thereby destroying — the logical state itself.

The overhead is not fixed. It depends entirely on physical error rates: better hardware means fewer physical qubits per logical qubit, and the relationship is superlinear. IonQ has argued that 100 physical qubits at 99.99% two-qubit fidelity would likely outperform a 10,000-qubit lower-quality system encoding 100 logical qubits — a vendor claim, but the underlying compounding argument is sound.

Encoding alone is also not sufficient for fault tolerance. You additionally need fault-tolerant gate implementations, continuous syndrome extraction, magic state distillation (whose factories consume a large fraction of the total qubit budget), and real-time decoding at microsecond latency. That last one is an under-appreciated bottleneck: the classical decoder has to keep up with the quantum device in real time.

Where things actually stand: logical qubits are real, demonstrated, and few. Google has run surface codes at distances 3, 5 and 7 and shown an encoded logical qubit outliving the best individual physical qubit. That is a genuine milestone and it is also a very long way from hundreds of logical qubits running millions of operations.

Executive Order 14413, signed June 2026, directed the Department of Energy to stand up a national center for assessing quantum computing performance within 180 days. Roughly forty-five years after Feynman proposed quantum computers and seven years after the first supremacy claim, a government found it necessary to build an institution because nobody can reliably answer "is this machine any good?"

Each metric fails differently. Qubit count is nearly meaningless alone. Quantum Volume saturates. Gate fidelity is usually quoted for isolated gates, which systematically flatters a chip by ignoring crosstalk and parallel-gate compounding. Error-mitigated results can be inflated by the mitigation itself. CLOPS measures speed, not accuracy. "Algorithmic qubits" are not comparable across vendors, which is frequently the point of the metric.

Summary statistics also hide enormous variation: the spread between the best and worst qubit on the same chip is often a factor of five or more in readout error.

Tellingly, the executive order named no modality. As of mid-2026, none has clearly won — superconducting leads on gate speed and fabrication, trapped ions on fidelity and connectivity, neutral atoms on raw qubit count, photonics on room-temperature operation and networking. The practical takeaway is to benchmark your own workload and avoid over-specialising in one vendor's stack.

The gap is not a matter of waiting for a bigger free tier. It is three orders of magnitude, and it is in error-corrected qubits rather than raw ones.

The resource estimates are worth knowing precisely. Gidney and Ekerå's 2019 paper put RSA-2048 at 8 hours using 20 million noisy physical qubits. Gidney's 2025 refinement cut that to fewer than one million physical qubits running for under a week — roughly a 20× reduction, traded for longer runtime. Crucially, the hardware assumptions barely changed between them (0.1% gate error, 1 microsecond surface-code cycle, 10 microsecond control reaction time); the algorithms and codes improved. Quoting a qubit count without a runtime is meaningless.

What you can do at home is educational and real: run Shor's period-finding on a simulator for small semiprimes, implement the quantum Fourier transform it depends on, and understand why the modular exponentiation circuit — not the QFT — is the expensive part. That builds genuine understanding of why the scaling is what it is.

What you cannot do is anything with cryptographic consequence, on free hardware or paid, today or in the near term. Anyone claiming otherwise is selling something.

The reason dates are unreliable is that the estimates have moved consistently downward for three decades and have never stopped falling. Planning against a number with that history is not planning. The target also matters: NIST P-256, which secures far more traffic and underpins Bitcoin signatures, is an easier target than RSA-2048, so "Q-Day" is ambiguous unless someone says which primitive they mean.

What makes the timing question less important than it looks is harvest-now-decrypt-later. An adversary can record encrypted traffic today and decrypt it whenever a cryptographically relevant quantum computer arrives. If your data must stay confidential for fifteen years, your exposure has already started. Mosca's inequality formalises this: if migration time plus required secrecy lifetime exceeds time-to-Q-Day, you are already late.

The migration itself is not speculative. NIST has standardised post-quantum algorithms, government deadlines exist, and symmetric cryptography is comparatively fine — Grover only halves effective key length, which is why AES-256 rather than AES-128 is the recommendation.

Treat vendor timelines with particular scepticism. One prominent 2024 vendor post on Q-Day cited no qubit count or resource estimate for RSA-2048 at all.

Being precise about this matters more than being negative or positive. Quantum computers exist, they run circuits, and specific algorithms have provable asymptotic advantages. What has not happened is a case where running a real problem on real quantum hardware produced a better answer, faster or cheaper, than the best available classical method.

Claimed advantage demonstrations have a recurring failure mode: they get overturned by better classical algorithms. A 2026 classical simulation reproduced Rydberg-atom-array experiments that had been thought beyond classical reach. Claims of quantum advantage are only as durable as the best classical algorithm anyone has bothered to write, and classical algorithms keep getting written.

Where the near-term optimism is best founded is quantum simulation of quantum systems — chemistry and materials — because that is the problem Feynman originally posed and the one where the mapping is natural rather than forced. Notably, the 2026 US executive order framed its goals as discovery science rather than commercial advantage, which is a fair reading of where the field is.

That is not an argument against learning it. The workforce shortage is real and described as a first-order bottleneck. It is an argument against believing timelines from people who profit from them.

Three structural problems, not just engineering gaps. First, data loading: encoding N classical data points costs O(N), so an algorithm with a log(N) inner loop still costs O(N) overall. The speedup evaporates in preprocessing, and no hardware improvement fixes it — it is structural. Dequantization results have already erased several claimed speedups by finding classical algorithms with matching complexity.

Second, barren plateaus. Gradient variance shrinks exponentially with qubit count, so at a few dozen qubits with a generic ansatz the training signal is simply gone. Mitigations exist; none is a general solution.

Third, the empirical record. A 2026 head-to-head study compared seven matched quantum/classical model pairs across supervised learning and reinforcement learning. Quantum lost on three axes: prediction performance, policy stability, and training time — the quantum models were slower to train, not faster.

What remains genuinely promising is narrower and worth stating: quantum machine learning applied to quantum data rather than classical data, quantum kernels for structured problems where they sidestep barren plateaus, and noise filtering and false-positive control. Those are real research directions.

So learn it if you want to do research in it, or to evaluate claims critically. Do not learn it expecting it to make your classical models faster.

Two things routinely mislead people about Grover.

The first is the "database search" framing, which is misleading. Loading N records into a quantum oracle costs O(N) in the first place, which destroys the speedup. Grover is useful where the search space is defined by a function you can compute rather than a table you must load — cryptanalysis being the canonical case, where it halves effective symmetric key length and is precisely why AES-256 is recommended over AES-128.

The second is that more iterations are not better. Success probability oscillates as sin²((2k+1)·θ/2), so overshooting the optimum actively destroys your answer. For N = 8 with one marked state the optimal count is 2 iterations, giving 94.4% success in a measured 4096-shot run. Run 3 iterations and it drops to 32%. Run 4 and it collapses to 1.3% — worse than random guessing, nine times worse than doing nothing. Knowing the right k requires knowing how many solutions exist, which may itself require quantum counting first.

On hardware the picture is harsher still. A 4-qubit multi-controlled X can compile to 20+ two-qubit gates, and published Grover demonstrations are almost all 2–3 qubits. They are demonstrations, not useful computations. The quadratic gain can be eaten entirely by error-correction overhead.

The first milestone is genuinely same-day. Install Qiskit, build a Bell state, run it on a simulator and then on real IBM hardware. That is a couple of hours and it makes the field concrete in a way that reading does not.

The second phase is the long one: understanding why circuits do what they do. This is where linear algebra becomes necessary — state vectors, unitary matrices, the Bloch sphere, why interference rather than parallelism is what actually produces speedups. Working through PennyLane's Codebook or IBM's Basics of Quantum Information gives structure to it. Expect a few months.

The third phase, which most self-taught people skip and shouldn't, is learning to read results honestly. Recognising shot noise versus device noise, knowing when error mitigation is warranted and when it is fabricating an answer, understanding why a benchmark claim might not survive a better classical algorithm. This is the skill that separates people who can use these machines from people who can run tutorials.

The realistic warning is about the failure mode: getting stuck in theory and never building. Alternate between the two. Every concept you learn should have a circuit you ran attached to it.

Free is not the compromise option in this field — it is where most of the best material is. Vendors have a strong incentive to teach people to use their platforms, and the result is unusually high-quality zero-cost training.

For a structured path, IBM Quantum Learning is the most complete and connects directly to free hardware. Basics of Quantum Information covers the formalism properly without assuming graduate physics.

For learning by doing, PennyLane's Codebook is interactive and well paced, its Coding Challenges are a good intermediate step, and Microsoft's Quantum Katas are exercise-driven in a way that exposes gaps fast.

For conceptual grounding, Quantum Computing for the Very Curious uses spaced repetition and is genuinely free. For academic depth, MIT 8.370x on edX is available to audit at no cost, though the certificate is paid.

Qubit by Qubit runs a free full-length introductory program if you prefer cohort structure and deadlines.

The common mistake is collecting courses rather than finishing one. Pick a single primary path, work through it, and treat the others as reference. Verify current pricing yourself — free-audit terms on edX and Coursera change more often than anyone's published list, including ours.

The field is too young for credentials to have settled meaning. There is no equivalent of AWS certification in terms of recognised hiring value, and employers hiring quantum-adjacent roles look at what you have built and whether you understand the physics, not at badges.

Where certificates do earn their keep is as commitment devices. A deadline and an assessment finish courses that would otherwise stall. On that basis the free ones are straightforwardly worth doing: IBM Quantum Learning course badges are issued through Credly, typically require a 20-question quiz at 80% to pass, and are the easiest genuine quantum credentials to obtain at zero cost. The Qiskit Global Summer School certificate requires watching about 80% of core lectures, with lab work for the advanced track.

Be more sceptical about paid options. Verified certificates on edX and Coursera, and vendor associate-level exams, cost real money for credentials with limited external recognition. If money is the constraint, that money buys more as compute time, a textbook, or a conference ticket.

Prices and availability shift constantly, so verify against the provider directly before paying — our certifications page records when each entry was last checked rather than guessing.

Set expectations honestly. This is not a field where a bootcamp leads to a job. The largest category of openings is research scientist and quantum engineer roles requiring a doctorate in physics, EE or CS. Below that sit quantum software engineer roles, where strong classical software skills plus working quantum knowledge is a viable profile — and where the competition is less brutal than the research track.

The demand signal is genuine. A government does not stand up workforce institutes for a field with adequate staffing. But "shortage" here means shortage of people with rare deep expertise, not an open door.

The pragmatic path for most people is adjacency rather than a career change. Quantum-safe cryptography migration is hiring now and will keep hiring, because the deadlines are regulatory and the work is classical software engineering with a specific specialism. Simulation and HPC engineering, compiler and transpiler work, and control-systems engineering all touch quantum without requiring you to be a physicist.

And do not over-specialise in one vendor's stack. No hardware modality has clearly won, so betting a career on a specific platform carries more risk than the marketing suggests.

The case for now is that the fundamentals are stable. Superposition, entanglement, interference, the circuit model, why measurement is destructive, why error correction is expensive — none of that changes when better hardware arrives. Time spent on concepts is not wasted even if the machines take another fifteen years. The tooling is free, the learning material is excellent, and the entry cost is essentially zero.

The case for waiting is that the payoff is uncertain and the opportunity cost is real. If you are choosing between learning quantum computing and learning something with immediate professional application, the second one is probably the better economic decision right now. That is an uncomfortable thing for a quantum computing site to say, and it is true.

The strongest version of "now" applies to two groups. Anyone responsible for data with a long confidentiality lifetime should understand post-quantum cryptography today, because harvest-now-decrypt-later means the clock is already running. And anyone in HPC or computational chemistry should track quantum simulation, since that is the application area where the theoretical case is strongest.

For everyone else: treat it as an interesting thing to understand, not a career bet with a due date.