Quantum Circuit Resource Estimation: Calculate Qubits, Depth, and Gate Costs Before Execution

Overview

A circuit’s apparent size is only its starting cost. A small-looking circuit may require additional qubits, extra routing operations, or many repeated shots after it is compiled for a particular processor. Conversely, a circuit with a larger logical description may simplify substantially during optimization.

Resource estimation is therefore best treated as a comparison between at least two versions of a circuit:

• Pre-transpilation resources: the logical circuit you wrote, including its qubit count, gate count, depth, parameters, and measurements.
• Post-transpilation resources: the executable circuit after it has been mapped to a selected backend, restricted to supported operations, and optimized according to a stated compilation configuration.

The second view is usually more useful for hardware planning. Transpilation can change circuit depth and gate counts, especially when the logical circuit assumes interactions between qubits that are not directly connected on the target device. Two-qubit gates and routing operations deserve particular attention because they often determine whether a circuit is practical on noisy hardware.

Resource estimates do not predict useful output quality by themselves. They tell you what must be supplied: qubits, circuit operations, repetitions, execution time, and possibly error-mitigation overhead. For a broader introduction to the field, see this quantum computing learning roadmap.

How to estimate quantum circuit resources

1. Count logical qubits

Start with the number of qubits explicitly allocated by the algorithm. Include ancillas, workspace registers, index registers, and any qubits used to encode input data. If the circuit uses several registers, record both the total and the purpose of each register.

Do not confuse the number of meaningful data qubits with the total circuit width. A circuit may need temporary qubits even when the algorithm’s input appears small. Also note whether classical bits are required for measurement results or feed-forward control; classical storage does not increase quantum width, but it is part of the execution plan.

2. Measure logical depth and gate counts

Quantum circuit depth is the number of sequential layers needed when operations that act on separate qubits can run in parallel. A gate count simply totals operations, while depth captures dependency and concurrency. Both metrics matter:

• Total gate count: a broad measure of circuit work.
• Single-qubit gate count: useful for understanding local rotations and basis changes.
• Two-qubit gate count: a key bottleneck metric for many hardware experiments.
• Measurement count: relevant to readout and post-processing, particularly when measurements are repeated across many shots.
• Depth: an indicator of how many sequential operation layers the circuit must survive.

When reporting metrics, state how barriers, measurements, resets, and idle periods were treated. Different SDK versions and analysis methods may include or exclude certain instruction types, so metric names alone are not always sufficient for comparison.

3. Identify the target hardware constraints

Choose a target backend or a representative hardware model before treating the estimate as actionable. Record its available qubit count, connectivity, supported native operations, measurement approach, and any execution limits relevant to your experiment.

The logical circuit may use an all-to-all interaction pattern, while the processor may allow direct operations only between connected qubits. Compilation can then add swaps or equivalent routing operations. These additions increase physical gate count and depth, and they can alter the balance between single- and two-qubit operations.

4. Compare before and after transpilation

Compile the same circuit for the chosen backend using a documented optimization setting. Then record the resulting width, depth, total operations, and two-qubit operations. Repeat this comparison if you change the initial layout, optimization strategy, or target basis gates.

A useful comparison table looks like this:

5. Estimate shots and runtime

One circuit execution is normally repeated across multiple shots to estimate probabilities or expectation values. A first-order shot estimate is:

Total circuit executions = number of circuit variants × shots per variant.

Variants may include parameter values, observables, measurement bases, input samples, or separate circuits used for calibration and error mitigation. If an experiment evaluates 12 parameter settings with 2,000 shots each, the main workload is 24,000 circuit executions before adding calibration or mitigation circuits.

A rough runtime model is:

Execution time ≈ total shots × time per shot + queue, setup, and readout overhead.

Use this as a planning estimate rather than a promise. Actual duration depends on backend scheduling, batching, circuit length, measurement handling, provider limits, and whether the platform reports runtime per circuit, per job, or per shot. Keep queue time separate from device execution time when comparing experiments.

Inputs and assumptions to record

A resource estimate is only reproducible when its assumptions are visible. Save the following information with the circuit or experiment plan:

• Algorithm version, circuit-generation code, and parameter values.
• Logical qubit count, ancilla count, classical-bit count, and measurement locations.
• Gate-count definitions, including whether barriers, resets, and measurements are included.
• Target backend, backend configuration, connectivity, and native operation set.
• Transpiler or compiler version, optimization setting, initial layout, and routing method where available.
• Shots per circuit, number of parameter settings, observables, measurement bases, and calibration circuits.
• Assumed gate durations, measurement duration, readout delay, batching behavior, and queue-time treatment.
• Whether error mitigation, error correction, repetitions, or post-selection add extra circuits.

For noisy experiments, do not treat depth as the only quality indicator. A shorter circuit with more two-qubit operations may be less attractive than a slightly deeper circuit dominated by simpler operations. Resource analysis should be paired with an error strategy; the quantum error mitigation decision guide provides a useful next step.

Worked examples

Example 1: A logical estimate

Suppose an algorithm uses eight data qubits and two ancillas. Its logical circuit contains 96 single-qubit gates, 28 two-qubit gates, 14 layers, and one measurement at the end. The initial resource record is:

• Logical width: 10 qubits
• Total logical gates: 124
• Logical two-qubit gates: 28
• Logical depth: 14
• Shots: 4,000

This is enough to describe the algorithm, but not enough to predict hardware cost. It does not yet account for connectivity, native gate decomposition, or repeated circuits.

Example 2: A post-transpilation estimate

After compiling to a target backend, assume the circuit still uses 10 physical qubits but now contains 171 executable gates, including 63 two-qubit operations, and has depth 31. The revised record shows that routing and decomposition added substantial cost:

• Physical width: 10 qubits
• Total executable gates: 171
• Executable two-qubit gates: 63
• Compiled depth: 31
• Main experiment shots: 4,000

If the experiment also requires six measurement bases and four parameter settings, the main shot workload becomes 96,000 circuit executions: 6 × 4 × 4,000. Any calibration or mitigation circuits must be added separately. This example illustrates why a gate count taken only from source code can underestimate the real execution plan.

When to recalculate

Recalculate resources whenever an input that affects execution changes. At minimum, repeat the estimate when you:

• Move the circuit to a different backend or hardware generation.
• Change qubit layout, routing, native gates, compiler version, or optimization setting.
• Add ancillas, parameter sweeps, observables, measurement bases, or calibration circuits.
• Change the shot budget or introduce error mitigation and post-selection.
• Modify circuit structure, input encoding, ansatz depth, or stopping criteria.
• Need a new runtime, capacity, or queue-planning estimate.

Before each run, use this short checklist:

1. Count logical qubits and confirm that ancillas are included.
2. Record logical depth, total gates, and two-qubit gates.
3. Compile for the intended backend and record post-transpilation metrics.
4. Multiply circuit variants by shots per variant.
5. Add calibration, mitigation, and verification workloads.
6. Document backend and compiler assumptions with the estimate.
7. Compare the result with hardware capacity, execution limits, and the experiment’s acceptable depth and gate cost.

Keeping this record beside the circuit makes resource estimation a repeatable engineering step rather than a one-time guess. Revisit it whenever the circuit, compiler, backend, or experimental objective changes.