On-Demand Access

What is on-demand?

On-demand access allows you to run a job on a Quantum Processor Unit (QPU) without a reservation.

How do I use on-demand?

First, your account must be authorized for on-demand access, which today is limited to select users. If you'd like access, reach out to [e-mail] or wait for general access to be released.

Then, you'll need a supported, updated client, such as:

• pyQuil (>= v4.0)

• Rust or Python QCS SDK

Otherwise, you don't need to do anything special to submit a job as on-demand. If you submit a job without a current reservation, it will automatically go to the on-demand queue.

How does queuing work?

On-demand jobs are processed on a first come, first served basis. Jobs associated with a reservation will always take priority over on-demand jobs. This applies only to jobs which are both enqueued and then executed during a reservation for the submitting user.

Preemption

If an on-demand job is already running and a reserved job arrives, the on-demand job will be halted and replaced into the queue so as to run the reserved job immediately. This process is not visible to the user, except in that the job's queried status may oscillate between RUNNING and QUEUED. The results of a partial, pre-empted execution are discarded and, on retry, the job is restarted from the beginning.

Reservation Boundaries

Entering a reservation: if a pending on-demand job belongs to a user who then starts a reservation, that job remains in the on-demand queue.

Exiting a reservation: If a job is submitted during a corresponding reservation and then that reservation expires before it can run (because the user submitted more jobs than there is time for in the reservation), it is re-enqueued as an on-demand job to run afterwards. This remains subject to the limits described below.

How long are wait times?

Wait times are dependent on how many other on-demand jobs are in the queue and if there is a current reservation. Since jobs associated with a reservation always take priority, a user actively using their reservation may prevent any on-demand jobs from being executed for the duration of the reservation.

Additionally, execution may be temporarily paused while the QPU undergoes maintenance.

No estimate for wait time is currently available to the user.

When can I submit on-demand jobs?

On-demand jobs can be submitted at any time. However, when they run will be subject to the queue and wait times described here.

If the on-demand queue is currently full, you will have to wait to submit your on-demand job.

What does it cost to run an on-demand job?

Unlike reservations - which cost per second of reservation, regardless of jobs run - on-demand jobs are billed per microsecond of execution time on the QPU. None of the following incur a cost to the user:

• Time spent in the queue

• Failed execution

• Pre-empted execution (as described above)

The billable duration is returned to the client as execution_duration_microseconds along with the result. Note that for a program that time may fluctuate based on stochastic factors in execution.

Note that a failed execution does not mean a failure on the client side; if the job runs and succeeds, it is billed, regardless of whether the results are successfully collected by the client.

Note that, in general, a second of on-demand execution time is more expensive than reservation time.

What limits are there?

Queue Size

The queue has a limited size, and on-demand jobs will be rejected when the queue is at its limit. There is a per-account limit and another per-QPU limit shared by all users. If you receive an error message indicating that the queue is full, wait and retry.

Parallelism

Jobs run during a reservation may execute in parallel with one another when they don't share control system resources - that is, when they use disjoint parts of the QPU.

For system reliability and user experience, this feature is disabled for on-demand jobs; an on-demand job is run in isolation across the QPU.