Build1 publisher3 min readPublished
A single-developer scheduler spanning IBM, AWS and IonQ logged a 1822:1 queue-to-execution ratio, and sending the same circuit to a different processor cut its error from 6% to 3%, so routing decides both the wall clock and the error budget.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Submitting a job to a quantum processor looks like any other cloud call. IBM now wants a Cloud IAM key and an instance identifier where a direct token used to be enough [7]. The circuit goes up, and it lands in a shared queue behind everyone else pointed at that machine [8]. There is no local install of the device and no reservation, and the SLA you would expect from a classical cloud service does not exist [8]. There is also nobody to escalate to, which keeps the escalation short.
The headline ratio is worth doing in seconds. 61 minutes is 3,660 seconds, and dividing by the reported 1822:1 puts the execution leg at about 2.01 seconds [11], which agrees with the ~2 s the post reports as stable across runs [2]. Turned around, the QPU held that job for one part in 1,823 of its wall clock, or 0.055% [13]. The wider number is the spread on a single machine: 10 seconds at one end and 61 minutes at the other is a factor of 366, same hardware, same circuit [12].
For that ratio to show up in your logs, things the write-up does not report would have to match. It gives no access plan, no time of day, and no run count behind the 10 s to 61 min range [2], so the range is a pair of observed extremes rather than a distribution you can schedule against. The durable part is the mechanism, not the multiple. A shared queue with no reservation and no wait-time commitment [8] will produce a long tail on any busy device, and the post's own framing is that the literature treats exactly this friction as a qualitative footnote [10].
Backend choice is the more interesting finding, because it moves a number that more shots cannot fix. The same circuit on a different processor came back at 97% rather than about 94% fidelity [3]. In error terms that is 6% down to 3%, a halving [14]. The chemistry benchmark in the same project is what makes the distinction load-bearing: a two-basis VQE reached the H2 ground-state energy to chemical accuracy only once shot noise, which averages away, was separated from a fixed noise-model bias, which does not [5]. A three-point infidelity gap between processors sits on the side of the ledger that averaging never clears. So a router that picks a backend is setting the error floor of the run, not just its start time.
What the evidence does not cover is what happens when everyone runs a router. Autonomous selection across IBM, AWS and IonQ with fallback [4] measures one client's outcomes against queues it does not control; a policy that steers work toward the least loaded, highest fidelity device also moves the load it is reading. The post does not test that, and the honest read is that its queue figures describe one afternoon's contention on machines shared with unmeasured neighbours.
Credit where the instrumentation deserves it. An outside review of the repository found two correctness bugs that the author's own metrics had not surfaced, and a third appeared after those were fixed [6]. The write-up keeps that in [6], which is the right call and also the reason to read the numbers as one developer's measurements rather than a benchmark. The project began as an undergraduate thesis argument that the hard part of quantum access is the systems layer, made in words with no numbers attached [9]. The numbers now exist, they were produced by code that has been wrong before, and the mechanism they point at is a queue.
Ranked by verification strength, evidence, and original report placement.
On the same IBM quantum processor, on the same afternoon, the same two-qubit circuit took 2 seconds to run and 61 minutes to reach the front of the queue, a queue-to-execution ratio of 1822:1.
Real QPU execution is stable at about 2 seconds while queue time on the same machine ranges from 10 seconds to 61 minutes, up to 1822:1.
The author built Quantum Orchestrator, an open-source multi-provider scheduler across IBM, AWS and IonQ that accepts a standard circuit, autonomously selects the best available backend, runs with automatic fallback, and reports fidelity, queue time, execution time and molecular ground-state energy.
An external code review of the repository caught two correctness bugs that the author's own instrumentation had missed, and a third surfaced once those were fixed; the author keeps the story in the write-up.
Authenticating to IBM now requires a Cloud IAM key and an instance identifier, not the old direct token.
A submitted circuit waits in a shared queue behind everyone else aimed at the same machine; there is no local install of a real QPU, no reservation, and no SLA of the kind recognizable from classical cloud computing.
Publishers with included, body-backed reporting in this cluster.
Follow any of these and your For You feed starts watching them — no settings page required.
build
The nightly shutdown Lambda earns its postmortem on the morning restart1 publisher
security
ONCD stakes Texas water security on six months of donated vendor red teaming4 publishers
security
ToxicPanda 2.0 Widens From 16 Apps to 140, and From Overlays to ADB Shell6 publishers
build
Saving a file keeps the graph alive while the cloud facts underneath it expire1 publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
A single author's runs on a single machine
Every number in this story comes from the author's own runs of his own tool, published on dev.to with no logs, no named backends and nobody reproducing them. The internal arithmetic does hold, which counts for something: 61 minutes at 1822:1 puts the execution leg at 2.01 seconds, consistent with the ~2 s figure used throughout. Against that, the fidelity comparison is two rounded percentages and the chemistry result is asserted without an energy value, and the author's disclosure that his instrumentation carried two correctness bugs tells us the apparatus was fallible during the period it was collecting.
The author and one reviewer
Two people have demonstrably touched this scheduler: the person who wrote it and the person who reviewed the repository. Our coverage records no downloads, forks, users or deployments, and although the tool spans three providers on paper, only the IBM runs produce reported measurements. The chemistry benchmark and the queue instrumentation exist as one developer's exercise, not as anything in service.
Big thesis, small sample
The title asks readers to accept that quantum computing is an orchestration problem; the evidence offered is one two-qubit circuit on one IBM processor over one afternoon. The overstatement sits in the generalisation rather than the figures, which are modest and specific, and it narrows because the author volunteers the weaknesses himself: his thesis argued this in words with untested assertions, his platform-comparison claim rests on approximations, and his code was wrong until someone else read it. The story also concedes that the research it accuses of hand-waving has already catalogued queueing and provider heterogeneity as open problems.
Validating his own thesis, publicising his own repo
The author has two stakes on the table: the argument of his undergraduate thesis, which these measurements are meant to vindicate, and the open-source project he is introducing. Neither is hidden, and no vendor funding, sponsorship or affiliation with IBM, AWS or IonQ appears anywhere in the piece. dev.to neither pays for nor edits submissions, so no outside party filtered the numbers before publication.
Queue numbers firm, everything downstream soft
Our confidence tracks the thinnest link. The timing figures are checkable by anyone with an IBM account and internally consistent, so they can be relied on as an existence proof of extreme queue variance. The fidelity comparison, the chemical-accuracy claim and the multi-provider framing cannot: no processors named, no energies quoted, no AWS or IonQ measurements reported. One source, one author, no replication.