Quantum Computing

Effectively anyone with a reason to run a quantum circuit. Academic and industrial researchers use it for everyday simulation and hardware access; organisations preparing for post-quantum cryptography use it to study the algorithms behind that transition; and students, educators, and independent enthusiasts use it to build a working understanding of the physics. No institutional affiliation or specialised infrastructure is required.

Start with the six built-in circuit templates in the console: GHZ entanglement, Grover search, QAOA optimization, VQE chemistry, Bernstein-Vazirani, and quantum teleportation. Each loads in a single click with the right engine already chosen and a live circuit diagram, so you can run a real quantum circuit without writing any code. The documentation explains how to use each one, and every template has a full walkthrough in Research.

Quantum computing uses the physics of tiny particles, superposition and entanglement, to process information in ways an ordinary computer cannot. A QPU (quantum processing unit) is the actual quantum chip that does this, the quantum world's counterpart to a CPU or GPU. Most quantum work today is written and tested in simulation first, then run on a real QPU when the physics calls for it, which is exactly the workflow ZKSF gives you.

ZKSF (Zero Kelvin Simulation Foundry) is a cloud service that runs quantum circuits on the cheapest compute suited to them: CPU simulators, GPU simulators, or real quantum hardware. Every approximate result carries a certified error estimate.

That is your call, and both paths are here. Many research circuits (QAOA, ansatze, Clifford codes, bounded-entanglement dynamics) simulate accurately; when you want hardware, the qpu.rigetti and qpu.ionq engines run your circuit on a Rigetti superconducting or IonQ trapped-ion QPU.

It depends on the circuit, not a single number. Exact statevector reaches ~30 qubits on CPU and 32 on the GPU tier; Clifford circuits run to 5,000+ qubits; low-entanglement structured circuits go past 100 qubits with tensor-network MPS; and Pauli propagation returns expectation values from 100 to 200 qubits. The router picks the method that fits; the docs explain how it decides.

Every approximate result carries an accuracy statement. The default is a convergence check: the circuit is re-run at a higher resource budget and the shift in the answer is reported, where zero movement is evidence the approximation has saturated. The certified path instead returns a bound measured within the single run. Either way the statement can be exported as a public certificate and checked by anyone using zcc-verify, an open-source tool that recomputes the declared bound from the reported measurement and needs no account. That establishes the certificate is self-consistent; it does not by itself establish that the measurement was honestly made. The methodology is detailed in the docs.

ZCC-v0.1 is our versioned protocol for stating simulation accuracy. It has two levels. The default is a convergence check: the circuit is re-run at a higher bond dimension and the shift in the leading outcomes is reported as evidence that the approximation has saturated. Requesting the certified path returns a measured single-run bound instead: for a matrix product state built without renormalization, the final state's norm deficit is the exact discarded weight, read from the state rather than estimated, and the outcome error is bounded by the square root of twice that value where the individual truncation errors accumulate incoherently. Deep circuits do not always meet that condition, so we report the figure as an empirically supported bound: it was never exceeded across 334 runs checked against exact simulation, 290 of which were built to falsify it.

ZHF-v0.1 is the sibling protocol for real quantum-hardware runs: where the circuit is small enough to also simulate exactly, we compare the measured hardware counts against that exact distribution and report the fidelity, rather than a self-reported device specification. Every finished job can be exported as a public, verifiable certificate under whichever protocol applies. The full specification, with code and worked examples, is in the certification page.

Yes, as an opt-in. Enabling zero-noise error mitigation runs your circuit at several amplified noise levels and extrapolates the chosen observable back to the zero-noise limit, on the simulator or on real hardware, where it submits three runs and so bills three times. The result is a mitigated value reported with a ZCC-Estimate-v0.1 uncertainty: a statistical estimate, stated as such, rather than the measured bound of the certified simulation paths. Most providers return a mitigated number with no error statement at all. The methodology is in the certification page.

Pure pay-per-use: no subscriptions, no minimum spend. CPU jobs from $0.001; GPU billed by the second at $3/GPU-hour to 30 qubits and $8/GPU-hour for 31 to 32 qubits (the larger card costs more to run); and quantum hardware at provider list price (Rigetti $0.30/task + $0.000425/shot; IonQ $0.30/task + $0.08/shot). Every job shows a cost estimate before it runs, at no charge.

Yes. The SDK accepts Qiskit circuits directly: client.run(your_qiskit_circuit). Install with pip install qsim-sdk and see the quickstart.

Yes. Those are parameter sweeps, and gradient methods need two circuit evaluations per parameter per step, so a 20-parameter, 50-step run sent one job at a time is 2,000 submissions. client.run_sweep(circuit, bindings) sends them in one request, roughly an order of magnitude faster. A binding that turns out too entangled to simulate comes back marked and unbilled rather than failing the whole sweep, so your optimizer treats it as a bad point and carries on. See parameter sweeps.

Yes. The ZKSF Android app runs the same platform from your phone: upload a QASM circuit, pick an engine, and read the certified result on the go. It uses the same login as the web app, so your jobs and history stay in sync across both. Get it on Google Play.

We reject it instead of burning your budget on a wrong answer. The rejection comes with a diagnostic explaining why, and what would work: a different formulation, a smaller instance, or real hardware.

Right now. Sign in, choose qpu.rigetti (Rigetti superconducting) or qpu.ionq (IonQ trapped-ion), and your circuit runs on the real device.

For expectation values, yes. Select the pauli.cpu engine and pass the observable you want to measure as a list of Pauli terms, then call client.run(circuit, engine="pauli.cpu", observable=[[1.0, "Z"*192]]). Instead of tracking the full state, it propagates the observable back through the circuit in the Heisenberg picture, so cost scales with circuit structure rather than qubit count and reaches well past 100 qubits where a statevector runs out of memory. You get the expectation value plus the total discarded weight as a truncation-error statement. This returns expectation values, not bitstring samples, which is exactly what variational and energy-estimation workloads need.