You submit a variational quantum eigensolver job. It sits in the queue for 20 minutes. The optimizer updates parameters, submits again, waits another 20. After 50 iterations you've spent 17 hours queuing and 40 minutes computing. Qiskit Runtime sessions eliminate this waste by keeping your allocation alive across iterations.
The Queue Tax on Variational Workloads
Variational algorithms (VQE, QAOA) follow a tight loop: prepare circuit with current parameters, execute, measure, update parameters, repeat. Each iteration traditionally submits an independent job. IBM Quantum queues treat every job equally — your 100-circuit iteration waits behind someone's 10,000-circuit Monte Carlo simulation.
"Sessions aren't a scheduling hack. They're a contract with the backend: reserve capacity for a coherent workload, not a fire-and-forget job.
— Qiskit Runtime team, IBM Quantum
How Sessions Change the Economics
A session creates a dedicated execution window. The first job pays the queue tax. Subsequent jobs within the session's max_time and interactive timeout (default 2 hours) jump to the front. For a 50-iteration VQE, you queue once.
Session Parameters That Matter
| Parameter | Default | Tune For |
|---|---|---|
| max_time | 2h | Total session wall clock; increase for long optimizations |
| interactive_timeout | 2h | Idle time before session expires; keep > optimizer step time |
| max_jobs | None | Hard cap on jobs; useful for budget control |
💡
TipSet interactive_timeout longer than your slowest optimizer step plus network latency. A crashed optimizer shouldn't kill the session before you debug.
When Sessions Don't Help
Sessions add overhead for single-shot jobs. If you're running one VQE iteration daily, the session startup cost exceeds queue savings. Use batches for independent experiment sets (e.g., scanning ansatz depths). Use primitives directly for one-off circuits.
⚠️
WarningSessions consume backend capacity continuously. On shared systems, long idle sessions block others. Set max_time conservatively and close sessions explicitly.
Measuring the Gain
Track queue time vs execution time in your logs. A healthy session shows queue_time ≈ 0 for jobs 2 through N. If you see repeated queueing, your interactive_timeout is too short or the backend is oversubscribed — switch to a dedicated reservation or off-peak window.
✦
Next step: wrap your optimizer loop in a Session context manager this week. Log queue_time from each job result. You'll see the queue tax drop from hours to seconds — and your variational algorithms finally run at iteration speed, not queue speed.