Before you spend credits

The checks worth making before a hardware run: get it right on the built-in simulator, size your shots on a noise model, confirm the machine is online, then approve the price.

Every simulator on Qollab is free and only the quantum computers spend credits. IonQ publishes a submission checklist for its own users; the four checks below are that checklist adapted for a platform where the API key and the account belong to Qollab.

1. Get the circuit right on the built-in simulator

The built-in simulator is free, runs in your browser, and never queues. It catches the things that have nothing to do with quantum mechanics: a syntax error, a qubit index out of range, a measurement you forgot to add.

The built-in simulator also confirms the circuit compiles at all. IonQ's own first checklist item is to test on their ideal simulator, and the built-in simulator fills that role here.

2. Size your shots on a noise-model simulator

How many shots you need depends on noise, and the built-in simulator has none.

Run it again on an IonQ remote simulator, which carries the noise model of the machine you are aiming at. The distribution you get back approximates how that machine's noise affects your results. IonQ recommends this step to help you choose a shot count. Run it at 100 shots and at 1,000, for example, and compare the two distributions.

A remote IonQ simulator might appear to be slower than the built-in one, because noise-model simulation is shot-aware: IonQ runs one simulation for every shot you request, so a large shot count means many simulations. It is also still a model: IonQ is explicit that you should not expect QPU results to match noisy simulation results quantitatively, and the models are simplified approximations of what hardware would do. See Compute backends.

A Qiskit job is expected to finish before the project code "exits". This is normally not an issue for a Python project, which has a synchronous code flow: whenever the main.py code exits, it's considered done. It can be an issue in JS projects, where user input can be "read" through events, and the async main.js code has to wait for it. See Waiting for user input.

3. Check the machine is online

Hardware is not always available. A backend that is down shows as offline in the Select QPU dialog, and IonQ publishes maintenance and availability at status.ionq.co.

The dialog shows whether a machine is available and nothing about the queue: you cannot see how many jobs are ahead of you before you submit. Once a hardware job is waiting, the run console prints IonQ's predicted waiting time for that circuit. See Running your code for the job states a run passes through.

4. Confirm the price

The runner shows the cost in credits next to your balance and waits for you to approve; decline and nothing is charged.

The figure quoted before the run is usually an estimate, and once the job finishes the runner replaces it with the actual credits withdrawn, which can differ. The allowance that decides whether you are asked at all lives in the runner, not in your profile settings; it starts at a tenth of your balance and is editable before you run.

If the estimate is higher than you expected, the usual causes are shot count and a circuit that compiled larger than you wrote it. See How credits work and How your circuit is compiled.

Stay in the loop.

Get the latest tutorials, demos, and project showcases straight to your inbox. No noise, just the good stuff.