A quantum simulator is classical software that works out what a quantum computer would do with a given circuit. People use quantum computing simulators to develop and debug algorithms before paying for hardware time, to establish what results a hardware run should produce, and to test claims of quantum advantage.
There are several kinds. Exact state vector simulators store every amplitude of the quantum state, so they give the exact answer for any circuit, but memory doubles with every qubit added. Approximate methods such as matrix product states and Pauli propagation give up exactness or generality to reach much larger circuits, when the circuit's structure allows it.
Which one fits depends on the circuit and the result you need. Up to the mid-30s of qubits, an exact state vector simulator is the natural default, and that's what bluesv is.
bluesv is an exact state-vector simulator we built from scratch at BlueQubit. It's API-compatible with NVIDIA's cuStateVec, so the tools people already use (Cirq, Qiskit, PennyLane) can call it without changes.
One detail worth putting up front, because it changes how you should read the rest: bluesv is a product of agentic engineering. Claude wrote every line, working in Claude Code. No human wrote the code. Instead, we provided systematic design documents (often co-designed with AI) and structured handoffs between stages of the build. They set out what each component had to do, how it would be checked, and what the next stage needed from it.
When a model writes every line, "it looks right" is not enough. A fast simulator that silently returns wrong amplitudes does more harm than a slow, correct one.
Checking was possible because the reference library (NVIDIA’s cuStateVec) is deterministic. Given the same input, it always produces the same output, down to the last bit. That gave us an oracle that could tell us in milliseconds whether new code was correct. Every piece of bluesv was written against that oracle. Write something, check it, fix what disagrees, repeat, until it agrees with NVIDIA’s cuStateVec.
The finished library agrees with cuStateVec and with a simple NumPy reference on every operation, in single and double precision, and the CPU version passes all the cases against the same reference. The largest difference anywhere is at the limit of floating-point precision. Full circuits pass BlueQubit's internal tests and the qsimcirq test suite, and match qsim to machine precision.
On GPUs, we benchmarked randomly generated circuits from 22 to 30 qubits and depths from 10 to 100 on an NVIDIA A100, against qsim running on cuStateVec.
bluesv is faster at every point we measured: over 1.4 times faster on the largest, hardest circuits. The core computation itself is faster than NVIDIA's library.
On CPUs, we ran the same kind of benchmark on a 10-core Xeon against qsim's CPU backend.
bluesv is faster at every size we tested. From 26 qubits up, bluesv is about 1.5–1.6x faster at depth 10 and about 1.8x at depth 30. At this point, the limits are the hardware's, not the software's.
Rebuilding a mature, heavily optimized GPU library normally takes a year, and doing it with a model writing all the code sounds like a worse version of that bet. It turned out the other way. Claude Code didn't just autocomplete snippets. Working from the design documents, it ran the inner loop itself: it wrote kernels, checked them against the oracle, read where they disagreed, and fixed them, thousands of times. Each stage ended in a handoff that set up the next one, until a production-grade library came out the other end.
This worked because the target was already defined. The hardest part of most software is deciding what it should do, and here the existing API had settled that. What was left was work where a fast, cheap feedback loop adds up, which is where an agent does well when the task is well specified. It also helps that correctness here comes down to one numerical answer per circuit, which is far easier to be sure of than the behavior of a large general-purpose system.
The limit of the argument: if your problem doesn't come with a cheap, exhaustive way to check your work, none of this transfers.
bluesv now runs the state-vector simulators behind the BlueQubit SDK and app.bluequbit.io. We host it, already set up, on large CPU and GPU machines, so you can run large universal simulations without provisioning hardware, installing drivers, or configuring anything. We measured how zero-setup hosted simulators compare, BlueQubit included, in Benchmarking Zero-Setup Quantum Circuit Simulators. If you’re getting started, our tutorial on choosing a quantum circuit simulator can help you understand which approach best fits your workload.
bluesv is also small and self-contained, so there's very little to set up even when you run it yourself. That matters most for large batches of small jobs, where setup used to cost more than the simulation.
We'll be open-sourcing bluesv. It's the first of several parts of the BlueQubit SDK that we plan to build the same way: Claude writes the code against clear specifications and automated checks, then we release it as open source.
The bigger point is about how this field gets built. AI can now write advanced, domain-specific libraries that hold their own against hand-tuned originals, as long as the design is careful, the specifications are clear, and every step can be checked. bluesv took weeks, whereas this kind of infrastructure usually takes a team a year. That leaves us more time for the work we actually care about: new algorithms, new experiments, and faster results.
We think the next few years in quantum computing will move quickly. More soon.
