Planning a quantum experiment requires more than choosing a circuit and pressing run. You need a defensible estimate for shots, execution time, transpilation overhead, queue delay, and cloud usage before submitting a job. This guide provides a repeatable method for estimating those inputs, comparing simulator and hardware runs, and revising the plan when circuit or provider conditions change.
Overview
A quantum circuit is usually executed repeatedly rather than measured once. Each repetition is a shot: the circuit is prepared, executed, and measured to contribute one sample to the output distribution. More shots generally improve the stability of estimated probabilities, but they also increase execution work and may increase queue time or usage consumption.
A useful planning model separates five quantities:
- Logical circuit work: qubit count, gate count, depth, and measurement structure before compilation.
- Transpiled circuit work: the operations and depth produced for the selected target device.
- Shot budget: the number of repetitions needed for the decision you want to make.
- Execution time: circuit duration multiplied by shots, plus setup and submission overhead.
- Cloud usage: the provider-specific unit used for quotas, credits, billing, or job limits.
These quantities are related but not interchangeable. A circuit with few qubits can still be expensive to run if it is deep, requires many repetitions, or is submitted repeatedly during development. Likewise, a large simulator job may be limited by memory rather than by physical circuit duration.
For background on device quality and error rates, see the quantum computing hardware benchmarks comparison. If your goal is repeatable experimentation, pair this planning method with the quantum experiment reproducibility checklist.
How to estimate
Start with the measurement question, not a default shot count. Ask what must be estimated: the most likely bitstring, a probability, an expectation value, or a difference between two circuit variants. The required precision can vary substantially between these tasks.
1. Choose a precision target
For a single measured event with probability p, the standard error of an estimated probability is approximately:
sqrt(p(1 - p) / N)
where N is the number of shots. If you do not know p in advance, use the conservative worst-case variance, where p(1 - p) is at most 0.25. A rough planning formula is therefore:
N ≈ 0.25 / e²
Here, e is the desired one-standard-error precision. This is a planning approximation, not a guarantee. If you need a confidence interval, compare several circuits, or estimate a small probability, increase the budget and define the statistical method before running.
2. Account for circuit variants
Multiply the shots per circuit by the number of variants, parameter settings, calibration points, or repeated trials. A parameter sweep with 40 settings and 2,000 shots per setting is a 80,000-shot experiment before any validation reruns. Include control circuits, baseline measurements, and error-mitigation circuits in the same inventory.
3. Estimate circuit duration
For hardware, a simple wall-clock estimate is:
execution time ≈ shots × circuit duration + per-job overhead
Circuit duration depends on the scheduled operations, not merely the number of gates. Parallel gates may occupy the same time interval, while barriers, measurement operations, reset operations, and device-specific timing constraints can add duration. Treat the result as a range until you inspect the compiled or scheduled circuit.
4. Add transpilation and queue behavior separately
Transpilation can change gate count, depth, connectivity, and duration. Estimate this overhead as a separate stage because it may occur once per circuit, once per parameterized circuit family, or repeatedly depending on the SDK workflow. Queue delay is also distinct from execution time. A job that needs only seconds of device time may still take longer to begin when demand, scheduling, or access rules change.
5. Translate the run into the provider's usage unit
Cloud platforms may describe usage using different concepts, such as shots, circuit executions, job duration, processor time, credits, or plan-specific quotas. Do not assume that one shot always equals one billable or quota unit. Read the current provider documentation immediately before budgeting, record the terminology used there, and keep the raw experiment totals in your own log.
Inputs and assumptions
Use a small planning sheet for every experiment. The following fields are enough for a first estimate:
| Input | What to record | Why it matters |
|---|---|---|
| Target | Simulator, emulator, or hardware backend | Determines whether time is dominated by computation, device execution, or queueing. |
| Qubit count | Logical and expected physical qubits | Routing and simulation memory can grow as the circuit expands. |
| Depth | Pre- and post-transpilation depth | Deeper circuits usually have longer duration and more opportunities for noise. |
| Shots | Shots per circuit and total shots | Controls sampling precision and total execution work. |
| Variants | Parameter values, controls, and repetitions | Prevents undercounting the real experiment size. |
| Measurement plan | Registers, observables, and basis changes | Additional measurement settings may require additional circuit executions. |
| Provider unit | Current quota, credit, or billing definition | Connects technical work to cloud usage without guessing. |
Keep assumptions visible. For example: “2,000 shots per setting, 12 settings, one calibration circuit per setting, no mitigation, and a hardware run after transpilation.” This is more useful than recording only “24,000 shots,” because the estimate can be updated when the design changes.
For simulator work, distinguish state-vector, tensor-network, and sampling approaches where relevant. A simulator may avoid hardware queue time while still encountering memory, CPU, accelerator, or wall-clock limits. For hardware work, distinguish queue time from active device time and avoid treating a provider's maximum job size as a recommendation.
Worked examples
Example 1: Estimating shots for a probability
Suppose you want to estimate a measured probability to an approximate one-standard-error precision of 0.02. Using the conservative formula gives:
N ≈ 0.25 / 0.02² = 625
You might round this to 1,000 shots for an initial run, especially if the probability is unknown or you expect to compare multiple circuits. If the experiment has 16 parameter settings and one control circuit for each setting, the planned total becomes 17,000 shots at 1,000 shots per circuit. The control circuits should be counted because they consume execution capacity even though they are not the primary result.
Example 2: Estimating hardware work
Assume a parameterized circuit has 25 settings and uses 2,000 shots per setting. You also plan five validation settings and a matching control circuit for each primary setting. The total circuit count is:
25 + 5 + 30 = 60 circuits
The shot total is:
60 × 2,000 = 120,000 shots
Before submission, inspect the transpiled depth and scheduled duration. If the target device produces a longer circuit than expected, split the work into a small pilot job and a follow-up job rather than submitting the full budget immediately. The pilot can reveal whether output variance, device noise, or execution limits require a different design.
Example 3: Simulator first, hardware second
A practical workflow may use a simulator to verify circuit construction and measurement labels, then run a reduced hardware pilot. For example, use a small shot count to check that the distribution has the expected shape, test a few parameter settings, and inspect the compiled circuit. Only then scale the hardware run to the precision needed for the final comparison. This does not predict hardware results, but it can catch incorrect qubit ordering, basis selection, and parameter binding before those errors consume cloud usage.
When moving between SDKs or frameworks, confirm that measurement conventions, transpilation settings, and parameter handling remain equivalent. The Cirq vs Qiskit comparison can help frame that tool choice, but the execution estimate should always be based on the compiled circuit sent to the selected target.
When to recalculate
Recalculate your estimate whenever an input changes, rather than treating the first plan as fixed. The most important triggers are:
- The circuit changes: new gates, measurements, controls, or parameter settings can alter depth and shot totals.
- Transpilation changes: a different target, optimization setting, layout, or connectivity assumption can change physical resource use.
- The precision goal changes: tighter error tolerance usually requires more shots, while exploratory work may justify fewer.
- You add comparisons or mitigation: each extra circuit family or measurement basis expands the experiment.
- The provider changes its access model: verify current job limits, terminology, quota rules, and pricing documentation before submission.
- Benchmarks or rates move: update duration assumptions after a pilot run or when backend performance characteristics change.
Before each run, write down the target, circuit version, transpiled depth, shots per circuit, total circuits, total shots, expected active time, and provider usage unit. Run a small pilot when uncertainty is high, compare observed output variance with the target, and then revise the full budget. This turns quantum circuit execution planning from a guess into a repeatable developer workflow.
