Quantum Circuit Resource Estimation: How to Calculate Qubits, Depth, Gates, and Shots

Overview

The question How many qubits do I need? has several answers because a circuit is described at more than one level. A source circuit may use a small number of algorithmic qubits, while compilation can add operations, routing steps, temporary qubits, and measurements. Hardware execution adds another layer: error-correction assumptions, connectivity, calibration, queueing, and repeated shots.

A useful estimate separates five quantities:

• Qubit count: the number of data, ancilla, workspace, and readout qubits required by the circuit.
• Gate count: the total number of operations, preferably split into one-qubit and two-qubit gates.
• Circuit depth: the number of sequential layers after operations that can run in parallel have been grouped together.
• Shot count: the number of circuit repetitions needed to estimate measurement probabilities or an expectation value.
• Execution cost: memory, wall-clock time, and any provider-specific job or usage cost that follows from the first four quantities.

These values are related but not interchangeable. A circuit can have many gates but modest depth if the gates run in parallel. Conversely, a circuit with a low gate count can be difficult to execute if its two-qubit operations are arranged in a long dependency chain. For background on why compilation changes these measurements, see Quantum Compiler Basics: Transpilation, Mapping, and Why Your Circuit Changes.

How to estimate

1. Count the logical qubits

Start with the circuit before hardware-specific compilation. Count the qubits that hold the problem data and add every qubit used for workspace, controls, phase estimation, arithmetic, uncomputation, or measurement ancillas. Reusing an ancilla after it has been reset can reduce the peak live-qubit count, so count the maximum number of qubits needed at one time rather than simply adding every named register in a program.

Record this as Q_logical. If the algorithm processes an input of size n, do not assume that Q_logical equals n. Encoding choices, precision, oracle construction, and ancilla management determine the actual requirement.

2. Estimate gates by type

Separate the source circuit into at least three categories:

• Single-qubit gates, such as basis changes and rotations.
• Two-qubit gates, such as controlled operations and entangling gates.
• Measurements, resets, barriers, and other instructions that may affect execution but are not ordinary unitary gates.

Two-qubit gates deserve special attention because they often drive routing overhead and error exposure. Keep both the original count and the compiled count. A simple expansion factor is:

Two-qubit overhead = compiled two-qubit gates ÷ source two-qubit gates.

Use the factor only as a measurement of one compilation result, not as a universal constant. It can change with the target device, coupling graph, native gate set, optimization settings, qubit layout, and circuit structure.

3. Calculate circuit depth

Depth is the length of the longest dependency path through the circuit. Gates acting on different qubits can occupy the same layer when they do not conflict. Estimate source depth first, then transpile or compile for the intended target and record the resulting depth.

For hardware planning, track at least:

• Overall compiled depth.
• Two-qubit depth, meaning the layers containing entangling operations.
• Measurement and reset duration, if those operations are relevant to the workflow.

Two circuits with equal gate counts may have different practical behavior because their depth and two-qubit placement differ. If a circuit contains repeated layers, estimate depth as the depth of one layer multiplied by the repetition count, then add preparation, readout, and any uncomputation stages.

4. Estimate shots and runtime

A shot is one execution of a circuit followed by measurement. The required number depends on the precision of the result, the distribution being measured, the observable, and the amount of statistical confidence required. For a rough Bernoulli measurement with probability p, the standard error of an estimated probability is approximately:

sqrt(p(1 − p) ÷ S),

where S is the number of shots. Because the largest value of p(1 − p) is 0.25, a conservative planning estimate for absolute error e is:

S ≈ 0.25 ÷ e².

This is a statistical estimate, not a guarantee. Estimating several observables, resolving a small signal, applying error mitigation, or comparing many parameter settings can multiply the total shot budget.

For a first runtime estimate, use:

Total execution time ≈ number of circuits × shots per circuit × circuit duration.

Then keep queue time, compilation time, batching, classical post-processing, and retries as separate planning items. Provider terminology and billing rules can differ, so verify those inputs immediately before a real submission. The Quantum Hardware Job Submission Checklist is a useful companion when moving from a simulator to a cloud QPU.

Inputs and assumptions

A resource estimate is only as useful as its assumptions. Put the following in a worksheet or experiment log:

1. Problem size and encoding: define what one logical qubit represents and the input size being tested.
2. Algorithm version: record the circuit library, ansatz, oracle, approximation level, and repetition count.
3. Ancilla policy: identify whether workspace qubits are reused, reset, measured, or retained.
4. Compilation target: specify the simulator, abstract gate set, or hardware connectivity model.
5. Optimization settings: record the transpiler or compiler configuration and initial layout when applicable.
6. Noise model: distinguish an ideal estimate from one that includes gate errors, readout errors, decoherence, or mitigation circuits.
7. Precision goal: state the desired error tolerance for probabilities, expectation values, or an optimization objective.
8. Batch structure: count parameter values, observable groups, repetitions, and calibration circuits in addition to the main circuit.

For state-vector simulation, memory is often the first constraint. A general pure state over q qubits has 2^q complex amplitudes. If each amplitude uses b bytes, the raw state-vector storage is approximately:

Memory ≈ b × 2^q.

This excludes indexing, temporary buffers, simulator metadata, operating-system overhead, and parallel execution costs. A state-vector estimate should therefore be treated as a lower bound. Tensor-network, stabilizer, and sampling-based methods can have different scaling behavior, so do not use the state-vector formula to judge every quantum simulator.

For fault-tolerant planning, distinguish logical qubits from physical qubits. A logical qubit is an error-corrected unit of computation; a physical-qubit estimate must include the chosen error-correction code, error rates, target logical error rate, syndrome-extraction circuitry, and routing or spare capacity. Without those inputs, it is more honest to report logical requirements and state that the physical estimate is not yet determined.

Worked examples

Example 1: A small algorithm circuit

Suppose an algorithm uses 8 logical qubits, including 2 reusable ancillas. Its uncompiled circuit contains 48 single-qubit gates and 20 two-qubit gates, with a source depth of 31. A target connectivity model produces 34 single-qubit gates, 29 two-qubit gates, and a compiled depth of 46.

The report should show both views:

• Logical qubits: 8.
• Source gates: 48 single-qubit and 20 two-qubit.
• Compiled gates: 34 single-qubit and 29 two-qubit.
• Two-qubit expansion: 29 ÷ 20 = 1.45.
• Depth increase: 46 − 31 = 15 layers.

The lower single-qubit count does not mean the compiled circuit is simpler overall; the compiler may have rewritten operations into the target native basis. The increase in two-qubit gates and depth is the more relevant hardware-planning signal.

Example 2: Estimating measurement effort

Assume one observable must be estimated to an approximate absolute statistical error of 0.02. Using the conservative formula gives S ≈ 0.25 ÷ 0.02² = 625 shots. If an experiment evaluates 40 parameter settings and measures 3 separately executed observables at each setting, the main measurement workload is approximately 40 × 3 × 625 = 75,000 circuit executions.

This estimate excludes calibration, validation, parameter-shift circuits, and repetitions used to assess variability. It also assumes the same shot target is suitable for every observable. In practice, run a small pilot, inspect the variance, and revise the shot allocation rather than treating 625 as a fixed rule.

Example 3: Simulator memory

For a state-vector simulation using 16 bytes per complex amplitude, a 25-qubit state requires approximately 16 × 2²⁵ bytes before overhead. That is roughly 512 MiB of raw amplitude storage, but the actual process can need more memory for temporary arrays and parallel execution. If the circuit only requires samples or has a structure compatible with another simulation method, compare that method instead of automatically increasing state-vector capacity.

When to recalculate

Recalculate resource estimates whenever an input that affects compilation, sampling, or execution changes. The most important triggers are:

• The problem size, precision target, ansatz depth, or algorithmic repetition count changes.
• You switch SDK versions, compiler settings, native gates, layout strategies, or optimization levels.
• You move from an ideal simulator to a connectivity-constrained simulator or hardware backend.
• The hardware topology, calibration data, supported instructions, or execution interface changes.
• You add observables, parameter-shift evaluations, error-mitigation circuits, or validation runs.
• Provider pricing, quotas, shot limits, job limits, or billing terminology changes.
• A simulator reaches a memory, runtime, or parallelization limit.

For a repeatable workflow, keep a versioned worksheet with columns for logical qubits, physical or mapped qubits, source and compiled gate counts, two-qubit gates, depth, shots, circuit count, memory estimate, and runtime assumptions. Re-run the worksheet after every meaningful code or backend change, and preserve the previous result so increases are explainable.

Before execution, use the estimate to make a decision: simplify the circuit, reduce the problem size, change the simulation method, group compatible measurements, choose a different layout, or proceed with a bounded pilot. Resource estimation is not a prediction of useful quantum advantage. It is a disciplined way to expose bottlenecks early and compare implementations on the same assumptions.

For broader development context, connect this analysis to the quantum computing learning path, and for variational workloads review the hybrid quantum-classical workflow guide. Revisit the worksheet whenever the algorithm or execution environment changes.