Our local timing goal deserves its own yardstick. The question is not whether every classical method has been beaten, but how much registered QPU time we use compared with the kernel of our current local classical approach. The saved measurements give a ratio of approximately twenty.
Two separate quantum jobs, one existing baseline
The chi64 kernel of the classical 6×6 baseline took 150.819180 seconds. The cold worker, including imports, took 156.905497 seconds, excluding the Windows/WSL launcher. Other local work was running concurrently, so this was not an isolated system performance benchmark.
Two separate quantum jobs recorded 8 and 7 seconds of QPU usage respectively. The second included both original and compact. It would be incorrect to add the jobs together and present that as one necessary quantum budget, or to assign seven seconds to each arm.
| Comparison | Calculation | Ratio |
|---|---|---|
| Classical kernel / earlier QPU job | 150.819180 / 8 | 18.85x |
| Classical kernel / latest paired QPU job | 150.819180 / 7 | 21.55x |
The concise description is therefore approximately 20x less registered QPU time than the classical kernel time of our current baseline. It is a resource comparison with explicitly defined clocks.
Why this is not a stopwatch comparison
According to the provider timestamps, the newest hardware job took approximately 181 seconds between running and finished. That interval alone was much longer than the seven registered QPU seconds; queueing and local analysis are not fully described by it either. Accounted QPU usage and experienced elapsed time therefore answer different questions.
The IBM documentation on workload usage matters here: use the provider’s registration as intended, rather than retrospectively treating it as complete end-user elapsed time.
What if chi64 is still insufficient?
A higher bond dimension can make the classical calculation more expensive. But we did not run chi128. We cannot count an estimated longer classical runtime as additional measured quantum advantage. Conversely, improved classical algorithms or a different observable could make the local calculation cheaper.
Our reference is an MPS approximation to the selected finite circuit. Its accuracy must be established separately. The same applies to the quantum estimator, whose TFLO holdouts have not yet passed. A matched-accuracy test can support a stronger statement only when both approaches meet the same predefined error tolerances.
Why this limited milestone still matters
Choosing a concrete local competitor is a meaningful goal for a small project. The ratio shows that the registered QPU resource for this experiment is small relative to our current classical kernel. That motivates further improvement. Accuracy checks do not erase this milestone; they determine which stronger claim can responsibly follow.
Sources: both provider_metrics.json files and summary.json from classical_full_6x6_mps_T04_chi64_v1, preserved in full in the repository.