Quantum resource estimation turns an algorithm idea into a testable engineering plan. This guide shows how to estimate logical and physical qubits, gate counts, circuit depth, connectivity overhead, measurement shots, runtime, and error assumptions before committing to a simulator or quantum hardware.
Overview
A useful estimate is more than a single answer to “how many qubits does this algorithm need?” Quantum circuit resource requirements depend on the problem instance, data-encoding method, compiler, target device, measurement strategy, and accuracy you need. An algorithm that appears small at the logical level can require additional operations after transpilation, repeated circuit executions for sampling, or extra qubits for ancillas and error correction.
Separate your estimate into two layers:
- Logical resources: the ideal circuit before hardware-specific compilation. These include algorithm qubits, ancillas, gate counts, circuit depth, and shots.
- Physical resources: what a selected device or fault-tolerant architecture must provide after mapping, routing, calibration, error handling, and scheduling are considered.
This distinction prevents a common planning mistake: treating the number of wires in a circuit diagram as the total cost of running the workload. For background on choosing an algorithm, see Quantum Algorithms Explained: How to Choose the Right Algorithm for a Real Problem.
How to estimate
1. Define the workload and success criterion
Start with a precise workload rather than an algorithm name alone. Record the input size, number of data points, number of features, expected output, and acceptable error. For example, “run a variational circuit” is incomplete; “estimate the minimum energy for a problem with 12 terms, with an expectation-value uncertainty below a chosen threshold” is measurable.
2. Count algorithm qubits and ancillas
Count the qubits that hold the problem state, then add temporary or persistent ancillas. Data encoding can dominate this number. Basis encoding, angle encoding, and amplitude encoding make different trade-offs between qubit count, circuit depth, and state-preparation work. Compare those choices in Quantum Data Encoding Methods Compared.
Use this basic expression:
Total logical qubits = data qubits + workspace ancillas + control or readout ancillas.
Document whether ancillas are reused. A circuit that reuses one workspace qubit may need fewer total qubits than a circuit that keeps every intermediate result available.
3. Count gates by type
Record one-qubit gates, two-qubit gates, measurements, resets, and any multi-qubit operations separately. A total gate count is useful, but it hides the operations most likely to affect execution quality. Two-qubit gates often deserve their own line because connectivity routing and hardware error assumptions can change their cost substantially.
For parameterized algorithms, report both the gates in one circuit evaluation and the number of evaluations required by the optimizer. A variational quantum eigensolver, for example, may execute many parameterized circuits across optimization iterations. The total workload is therefore:
Total circuit executions = circuits per evaluation × optimizer iterations × measurement settings × shots per circuit.
4. Estimate circuit depth
Depth is the number of sequential layers after gates that can run in parallel are grouped together. Calculate at least two values:
- Logical depth: depth in the abstract circuit.
- Compiled depth: depth after decomposition, qubit mapping, routing, scheduling, and any required resets.
Compiled depth is the more useful value for hardware planning. If two qubits in a logical two-qubit gate are not adjacent in the device connectivity graph, the compiler may insert routing operations. Do not assume that a short logical circuit remains short on every backend.
5. Estimate shots and runtime
Sampling-based results require repeated executions, called shots. Increase the shot estimate when the measured probability is small, the observable has high variance, or the required confidence is strict. For an initial feasibility review, use a range rather than false precision: a low, central, and high shot scenario.
A simple runtime model is:
Estimated runtime ≈ total circuit executions × (execution time + queue or scheduling overhead) + compilation time.
Keep queue time separate from device execution time because it depends on the service, backend, and workload conditions. For cloud planning, also record whether billing is based on shots, circuits, elapsed time, or another provider-defined unit; verify the current terms before making a budget decision.
6. Apply an error and overhead model
At the logical level, list the assumed error model and whether the estimate includes readout mitigation, zero-noise extrapolation, probabilistic cancellation, or other techniques. These methods can require additional circuit executions, so they belong in the resource estimate rather than in a footnote. The guide to Quantum Error Mitigation Methods Compared can help structure this part of the review.
Inputs and assumptions
Use a worksheet like the following for every algorithm proposal or backend comparison:
| Input | What to record | Why it matters |
|---|---|---|
| Problem size | Variables, terms, features, or items | Drives data qubits and repetitions |
| Logical qubits | Data qubits plus reusable and persistent ancillas | Defines the ideal register size |
| Gate profile | One-qubit, two-qubit, controlled, reset, and measurement counts | Reveals dominant operations |
| Depth | Logical depth and compiled depth | Shows sequential exposure to noise |
| Connectivity | Target topology and mapping assumptions | Determines routing overhead |
| Shots | Shots per circuit and confidence target | Controls sampling cost and precision |
| Repetitions | Measurement settings, optimizer steps, and parameter shifts | Converts one circuit into total workload |
| Error handling | Mitigation, correction, or no adjustment | Adds executions and sometimes ancillas |
For fault-tolerant planning, add the logical error target, code or architecture assumptions, magic-state or non-Clifford resource requirements, and the physical-to-logical qubit conversion model. Avoid presenting a universal conversion factor: it depends on the error rates, code, target logical error rate, decoding approach, and implementation assumptions.
Worked examples
Example A: a small variational circuit
Suppose a prototype uses 8 data qubits, 2 reusable ancillas, 3 measurement settings, and 1,000 shots per setting. One evaluation therefore requires 3,000 circuit executions. If an optimizer is expected to perform 40 iterations, the estimate becomes 120,000 executions before adding parameter-shift evaluations, calibration runs, mitigation circuits, or retries.
Now assume the abstract circuit contains 160 one-qubit gates, 80 two-qubit gates, and a logical depth of 24. After compilation to a constrained connectivity graph, record the measured two-qubit count and depth again. The difference between the two versions is the routing and decomposition overhead, not an error in the original logical design.
Example B: an encoded data pipeline
Consider a classifier with 6 features and 100 input records. An angle-encoding design might use 6 data qubits per circuit, while a different encoding could use fewer or more qubits but require a deeper state-preparation circuit. The estimate must include the encoding circuit for every record, not only the trainable ansatz. If training evaluates 100 records, 5 measurement settings, and 500 shots, the sampling workload is 250,000 shots per parameter evaluation. Add the number of optimizer steps and any gradient evaluations to obtain the full estimate.
This is why hybrid AI-quantum planning should track classical preprocessing, data transfer, circuit construction, and result aggregation alongside quantum execution. See Hybrid AI-Quantum Workflows: A Practical Guide to Building and Evaluating QML Prototypes for a broader workflow view.
When to recalculate
Recalculate resource requirements whenever the problem size, encoding method, ansatz, optimizer, shot target, mitigation method, or backend changes. A framework update can also change transpilation defaults or gate decomposition, so rerun the estimator after significant SDK changes. The Quantum SDK API Migration Checklist is useful when updating Qiskit, Cirq, or PennyLane projects.
Before each hardware run, compile a representative circuit for the selected target and compare logical versus compiled counts. Then benchmark a smaller version on a simulator and real device, recording depth, execution time, result variance, and shot requirements. Use How to Benchmark Quantum Circuits on Simulators and Real Hardware to organize that comparison.
Finally, preserve the worksheet with a date, SDK version, transpiler settings, backend assumptions, and confidence target. Treat the estimate as a versioned engineering artifact rather than a permanent fact. That habit makes it easier to explain feasibility decisions, identify optimization opportunities, and recalculate quickly when hardware specifications, execution models, or workload requirements change.
