Experiment Runner

The circuit, as the OpenQASM 3 the agent sent — not a re-serialisation, so what you read is what ran. The targetwith its parameters: simulator is the exact statevector engine behind every page on this site (up to 16 qubits, shots clamped to 4096); noisy-simulator layers a Pauli-error model on the same engine — a depolarising channel after every one-qubit gate (default 0.1%) and two-qubit gate (1%), and an independent readout flip per bit (2%), up to 10 qubits; hardware submits through the same authenticated, plan-checked, quota-reserving route as the app’s hardware page and records the job handle. The result: counts (and, for the ideal simulator, the final amplitudes) or the job handle. The note the agent left.

Watch for the two things a record makes visible that a chat transcript hides: whether the hypothesis was written before the runs (it is timestamped first), and whether the conclusion cites step numbers and counts that are actually on the page.

It does not run anything on its own. There is no scheduler and no agent here — Claude Code (or any MCP client) drives the tools, and this page only reads what was written. It does not verify a conclusion: the agent’s write-up is stored verbatim, and judging it against the counts is your job. The noisy simulator is a model, not a device: no T1/T2 decay, crosstalk, leakage or correlated readout error. Hardware steps record the submission, not the counts — those are polled from the hardware page once the job finishes. Records have no access control: they are attributed to a signed-in author when the request carried a token, but every record on a deployment is readable by anyone who can open this page, so the tools tell agents not to put secrets in them. Without a Supabase service role the store is this server’s memory (at most 200 records, 200 steps each), which a restart empties.