Score vs Cost
The Semantic
Equivalence Grader
Matching an expected output is not proof that a quantum program performed the requested computation. Quantum programs can produce measurement statistics, prepared states, or unitaries, and many different circuits can carry out the same computation. Therefore, when benchmarking quantum code, a grader comparing against a single human-written example or only measurement outputs risks incorrectly grading a program. Graders must check both the functional behavior of the program and its output.
Classical code benchmarks already showed that the tests themselves shape a model's score on coding. HumanEval, MBPP, and APPS made executable test suites the standard. EvalPlus then showed that stronger and augmented test suites expose wrong solutions that earlier suites had accepted and can change which model ranks highest. Quantum code generation inherits that problem and adds another: a grader can also reject a correct program just because it was written differently from the stored solution.
Quantum code benchmarks have moved toward this, working within what a single stored solution allows. Qiskit HumanEval adapted HumanEval-style execution to a quantum software development kit. QuanBench added algorithmic coverage and a process-fidelity check, but stayed tied to one framework and one stored solution. QuanBench+ aligned those tasks across Qiskit, Cirq, and PennyLane. It compared output distributions to a single reference under a global threshold on Kullback-Leibler (KL) divergence, a measure of the gap between two distributions. Two circuits that do the same job can still show high KL divergence. Equivalence checking tools such as Munich Quantum Toolkit Quantum Circuit Equivalence Checking (MQT QCEC) make the same point. Compare what two circuits do, not how they are written, and ignore differences no measurement can detect, such as global phase.
QCircuitEval is an open-source, deterministic behavior-contract benchmark for large language model (LLM)-generated quantum circuit code across Qiskit, Cirq, PennyLane, and CUDA-Q. QCircuitEval grades a program by what it does, not just by what it outputs. A candidate must pass two graders: a structural grader that rejects shortcuts, and a functional grader that tests the program against a contract. The contract is a versioned definition of one task. It fixes the inputs, the target result, and the bit order, which the prompt states as well. It also specifies the signature, the named systems, the parameter domain, the output policy, the semantic object, the metric and its tolerance, the resource limits, and any required construction.
The target is derived from the task statement rather than from a stored solution, then pinned by a hash. Change the target and the hash changes with it, so the contract cannot drift unnoticed. The functional grader ignores global phase, which no measurement can detect; it does not accept bit-order reversal or qubit permutation after the fact.
Two checks, one verdict
Generated code is run in the task's framework, then lowered to a shared intermediate representation. From that representation, two graders operate the same way for Qiskit, Cirq, PennyLane, and CUDA-Q. The functional grader simulates the circuit and compares its behavior with an independently derived target. That alone is not enough: code can reproduce the expected output without performing the requested computation. The structural grader therefore inspects registers, gates, measurements, and source for evidence of the required construction and for banned shortcuts. Both graders must pass, and construction requirements are run before the functional checks.
No LLM takes part in grading. Every verdict comes from a deterministic verifier, and each contract has one verifier route. Only a verified pass counts toward a score. A functional or construction mismatch returns as a semantic failure. When the grader cannot justify a decision, it returns an execution error rather than a guessed pass, and the same applies when a result falls inside the uncertainty band. Exceeding a resource, time, memory, or dimension limit returns as a resource limitation.
Hellinger fidelity
Quantum programs can produce measurement statistics, prepared states, or unitaries. Because measurements are stochastic, many tasks compare distributions rather than a single return value. For a target distribution and a candidate , the grader uses the Hellinger fidelity, :
The index ranges over every possible measured bitstring. The Hellinger fidelity is symmetric, bounded in , and more stable than KL divergence when probability is spread across many small outcomes, the regime where a single-reference KL threshold is most brittle.
Target p vs candidate q
The acceptance test is on Hellinger infidelity, , against the contract's pinned target in the declared bit order. Gate and unitary tasks instead compare operators up to global phase:
Other semantic objects use checks suited to what they are. States are compared by trace distance under the contract's phase and observation policy. Unitaries and isometries use an operator norm, restricted to the logical subspace or with ancilla restore where the contract declares it. Channels are compared through the normalized Choi representation under Frobenius distance. Instruments are checked on branch probabilities together with the normalized post-measurement states. Classical input-output tasks run the full finite truth table rather than a sample of examples, and distribution tasks compare the whole probability vector. Shor and Steane encoders use phase-sensitive exact state checks, so a program that matches the measurement support with the wrong codeword signs fails. Arithmetic and Boolean tasks are evaluated across their full declared input domain. Parameterized quantum error correction (QEC) tasks run every declared diagnostic case, including no error and each permitted single-error location. Every case must pass.
What counts as the same answer
The target is derived independently of any one canonical solution, so a circuit passes when it realizes the contracted behavior, not when it matches a particular reference listing. Different constructions can still overlap on that contracted distribution. Readout order is not open: prompts and contracts pin little-endian bit order, and a reversed measurement map fails because 011 and 110 do not overlap. A circuit that hardcodes the expected bit string also fails the structural checks, even if its simulated histogram matches.
Gate and unitary tasks still treat global phase as unobservable. Multiplying a state by does not change any measurement probabilities, so two circuits that differ only by that overall factor realize the same physical operation. and look like different listings, but , so both are treated as equivalent:
Why simulation is not enough
A functional grader can be fooled by code that writes the expected answer directly. This supposed adder returns the demonstration result 0110 without allocating operands or performing any addition:
The functional grader sees the expected output; the structural grader sees that no adder was built. Requiring both checks accepts genuinely different valid circuits without turning output matching into a loophole.
The adder is the crudest version of the problem, and the structural grader is built to catch the subtler ones too. It rejects precomputed counts and probabilities, a unitary handed back in place of a program, and a nontrivial dense unitary on the full register. It also rejects amplitude injection, where a program writes the target state straight into the register. Each of these reproduces the expected output while skipping the computation the task asked for.
Beyond rejecting fabricated answers, contracts state what a valid program has to contain. A contract can set minimum qubits, operations, measurements, and entangling gates, require that particular wires are measured while forbidding others, and name the interactions that must occur between data, ancilla, control, and target registers. Where a task calls for an explicit construction, the grader enforces the gate families and decompositions the contract specifies and bans the obvious substitutes, among them library calls, optimizers, eigensolvers, simulators, samplers, decoders, and dense evolution.
The harder evasions need checks of their own. A net-unitary nonlocality check finds entangling gates that cancel one another out, and restricting that check to the measured register catches an entangler parked on unused ancillas, where it satisfies a gate count without touching the result. Error correction tasks strip canceling padding and require physical errors that depend on the arguments they were given, and a contract can insist on multi-controlled corrections. Cross-case invariance catches a function that branches on public arguments and hardcodes each row of the truth table rather than computing it. Every one of these routes has an adversarial test behind it.
Results
Results
The benchmark consists of 70 tasks across four frameworks (Qiskit, Cirq, PennyLane, and CUDA-Q), giving 280 records in a full run. Tasks are split into 58 Core tasks and 12 quantum error correction tasks.
Core contracts break down by semantic object into 26 distribution, 17 state, 6 total-unitary, 5 exhaustive classical input-output, 2 instrument, 1 channel, and 1 isometry. By task category, that is 42 algorithms, 10 state preparations, and 6 decompositions, spanning Grover and amplitude amplification, the Quantum Approximate Optimization Algorithm, the quantum Fourier transform and phase estimation, Simon's algorithm, Bernstein-Vazirani, the Harrow-Hassidim-Lloyd algorithm, Shor and order finding, quantum walks, Hadamard and swap tests, teleportation, arithmetic, state preparation, gate decomposition, and Trotterized dynamics.
Error correction contracts are 10 exact distribution and 2 exact state. Coverage includes bit-flip encoding, syndrome extraction, and correction; phase-flip; repetition-code logical controlled-NOT; Shor and Steane encoding; Steane and Shor syndrome; and five-qubit repetition.
The published run covers 33 official pass@1 configurations across 10 models, 280 records each, for 9,240 records in total. Each configuration is a model paired with a reasoning setting. The highest score was 92.67% on Core, or 215 of 232 records, from GPT-5.6-sol at high reasoning effort. Gemini 3.1 Pro Preview and Grok 4.6 each reached 90.95%, or 211 of 232. The benchmark is saturated: seven of the 33 configurations score at least 90% on Core.