Running a circuit on a real quantum processor is different from running it in a simulator. This checklist gives you a repeatable way to validate the circuit, select a compatible backend, estimate shots and spending, configure credentials, preserve results, and compare hardware output with a controlled simulation before submitting a cloud QPU job.
Overview
A successful quantum hardware submission is not simply a simulator job with a different backend name. Real devices impose constraints on available qubits, supported operations, connectivity, circuit depth, measurement formats, execution time, access permissions, and cost. Device status and queue conditions can also change between planning and execution.
Use this workflow for small experiments, algorithm demonstrations, and hybrid quantum-classical prototypes:
- Validate the circuit on an ideal simulator.
- Define the measurement and statistical result you need.
- Inspect the target backend's current capabilities and restrictions.
- Transpile or compile the circuit for that backend.
- Estimate shots, runtime, and budget before submission.
- Submit with reproducible metadata and secure credentials.
- Compare hardware results against an appropriate simulator baseline.
This process is useful whether you are following an IBM Quantum tutorial, an Amazon Braket tutorial, an Azure Quantum tutorial, or using another provider through Qiskit, Cirq, PennyLane, or a provider-specific SDK. The names of resources and submission calls may change, but the checks remain broadly applicable.
For background on why circuits change during compilation, see our guide to quantum compiler basics. It is particularly relevant when a circuit that works in simulation becomes deeper after mapping to hardware.
How to estimate a hardware job
Estimate a submission in layers rather than treating “one circuit” as the unit of work. A practical estimate is:
Total execution volume = number of circuit variants × shots per variant × repetitions or parameter settings.
A circuit variant may be a different parameter value, observable, input dataset, error-mitigation setting, or measurement basis. A variational algorithm can therefore create many executions even when its logical circuit is small.
For cost planning, separate provider charges into the categories documented by the platform you intend to use. Depending on the service and access arrangement, relevant inputs may include task or job charges, QPU execution charges, simulator charges, storage, or associated cloud resources. Do not assume that a free development account, reservation, or promotional allocation applies to every backend or workload.
For statistical planning, decide what precision is meaningful before increasing the shot count. If you only need to identify the most frequent bit string, a modest pilot run may be enough to reveal whether the circuit behaves plausibly. If you need an expectation value or a small difference between two candidates, you may need more shots and repeated measurements. More shots reduce sampling uncertainty, but they do not automatically correct device noise or compilation errors.
Use a two-pass submission strategy when possible:
- Pilot pass: Run a small number of shots to verify that the job is accepted, measurements are present, and output formatting is as expected.
- Measurement pass: Increase shots only after confirming the selected backend, compiled circuit, and result parser.
This approach can prevent wasting a large shot allocation on a malformed circuit or an incorrect observable definition.
Inputs and assumptions
Circuit validation
Start with a deterministic software test. Confirm register sizes, classical bit mapping, measurement locations, parameter binding, and expected output labels. Run the same circuit on an ideal simulator and save the result. If the simulator output is already unexpected, hardware execution will make diagnosis harder.
Then test a noise-aware or device-like simulation if your toolchain supports one. This does not reproduce every property of a live processor, but it can expose sensitivity to readout noise, gate errors, or circuit depth before you spend hardware time.
Backend compatibility
Check the backend immediately before submission. Confirm that it is online or accepting jobs, has enough usable qubits, supports the gates required by your circuit, and permits the measurement format your program expects. Logical qubit count is not the only constraint: connectivity may require additional routing operations, and the compiler may decompose high-level gates into a longer native sequence.
Record the backend name, software versions, compilation settings, and any reported calibration or availability information that affects interpretation. Backend properties are time-sensitive, so a result without this context is difficult to reproduce.
Transpilation and depth
Compile for the selected backend before estimating the final job. Inspect the resulting qubit mapping, depth, two-qubit gate count, and measurements. A circuit that looks short at the algorithm level can become substantially longer after routing and gate decomposition.
Do not compare an uncompiled ideal circuit directly with hardware output if the hardware job used a transformed circuit. Save both the original and compiled representations. Our quantum Python libraries guide can help you identify which SDK is responsible for circuit construction, compilation, and result handling.
Credentials, queue, and storage
Use an account or workspace with the required permissions, and keep tokens outside source code. Prefer environment variables, a local credential store, or the secret-management system approved by your team. Test authentication with a low-risk simulator or device query before submitting a large job.
Review queue information and submission limits, but treat them as estimates rather than guarantees. Save the job identifier immediately, then persist the circuit, backend, shot count, submission time, software environment, and raw result. Raw counts are more useful than a screenshot because they allow later recalculation of probabilities and observables.
| Platform route | What to verify | Best planning habit |
|---|---|---|
| IBM Quantum with Qiskit | Provider access, backend availability, supported instructions, transpilation output, and job limits | Save the compiled circuit and job identifier alongside the Qiskit environment details |
| Amazon Braket | Device availability, task configuration, region or workspace settings, and cloud billing inputs | Separate circuit definition, device selection, shot count, and task metadata in your experiment log |
| Azure Quantum | Workspace access, selected target, target-specific constraints, submission permissions, and pricing terms | Record the workspace, target, SDK version, and any provider-specific compilation choices |
This table is a planning framework, not a current capability or price list. Provider interfaces, names, limits, and access models change; check the relevant documentation before every production submission.
Worked examples
Example 1: A two-qubit Bell-state check
Suppose a circuit prepares an entangled two-qubit state and measures both qubits. First, run it on an ideal simulator and confirm the expected bit-string pattern. Next, compile it for the chosen QPU and inspect whether the two logical qubits are adjacent or require routing. Submit a small pilot with a clearly recorded shot count. If the output contains unexpected states, compare the hardware counts with a noise-aware simulation before changing the algorithm.
The useful decision is not whether every hardware shot matches the ideal result. Instead, ask whether the observed distribution is consistent with the experiment's intended correlation and whether the deviation is stable across a repeat run.
Example 2: A parameter sweep
Assume a variational circuit uses five parameter settings and you plan to collect 1,000 shots for each setting. Your initial execution volume is five circuit variants multiplied by 1,000 shots, or 5,000 shots. If you evaluate three measurement bases for each setting, the plan becomes 15,000 shot executions before accounting for retries or calibration checks.
Run one or two settings first. Verify that parameter binding and observable calculations are correct, then submit the full sweep. Store each parameter vector with its result rather than saving only the final objective value. This is essential for debugging a hybrid quantum-classical workflow; see our hybrid quantum-classical machine learning workflow for a broader experiment structure.
Example 3: Simulator versus hardware comparison
For a fair comparison, use the same logical circuit, measurement basis, shot count, and post-processing definition. Compare ideal simulation, device-like simulation when available, and hardware output as separate baselines. Label whether each difference comes from sampling, simulated noise, hardware noise, compilation, or a changed circuit. This prevents the common mistake of attributing every discrepancy to the QPU itself.
When to recalculate
Revisit the estimate whenever any input changes. In practice, recalculate before each hardware job if the work matters, and always recalculate after:
- Changing the backend, region, workspace, or provider account.
- Changing the circuit, parameter count, measurement basis, or shot count.
- Upgrading the SDK, compiler, runtime, or provider integration.
- Seeing a different queue state, device status, or access requirement.
- Changing a reservation, budget, billing arrangement, or execution mode.
- Repeating an experiment after a significant interval.
As a final pre-submission checklist, confirm: the ideal-simulator result is saved; the circuit has measurements; the selected backend is compatible; the compiled circuit has been inspected; shots and variants are counted; budget and permissions are understood; credentials are secure; the job identifier will be recorded; and the hardware result has a defined simulator baseline.
Hardware capabilities, SDK syntax, access rules, queue behavior, and pricing inputs should be checked against current provider documentation. Revisit this workflow after major IBM Quantum, Amazon Braket, or Azure Quantum changes and at least every six months. For the next stage of learning, connect this process with a structured quantum computing learning path, then use a small reproducible project rather than an isolated hardware run.
