How do you program a quantum computer today?

Status as of September 26, 2026. You program a quantum computer in ordinary Python, from a laptop, without owning a single qubit. Four open-source SDKs dominate the public stack — Qiskit, used by 69.1% of surveyed developers, PennyLane (30.8%), Cirq (17.5%) and the Amazon Braket SDK (12.1%), per the Unitary Foundation’s 2025 open-source survey of 1,400+ practitioners — and all four are Apache-2.0 licensed (PyPI), free to install, each shipping a free simulator. What costs money is the hardware minute, not the software (our provider guide). This is Rosetta Quantum’s map of the stack, layer by layer, with every version number checked against the public record today.

What does “programming a quantum computer” actually mean?

It means writing a classical program that builds, compiles and submits a circuit, then reads back thousands of probabilistic measurement outcomes. Nothing in the editor looks exotic: it is Python calling a library. The loop is the same in every SDK:

1. Build. You describe a circuit — qubits plus a sequence of gates. At this stage it is a data structure, portable and vendor-neutral (OpenQASM 3 is the common interchange format).
2. Transpile. A compiler rewrites your idealized circuit into the native gate set and qubit layout of one concrete target. This is where most of the engineering lives — see the layer map below.
3. Execute. The circuit runs on a simulator (free, classical — a statevector of n qubits holds 2^n amplitudes, so cost doubles per added qubit; our qubit explainer covers why) or on a QPU through the vendor’s runtime API (billed; cost mechanics).
4. Measure. You do not get “the answer”: you get shots — thousands of repeated runs summarized as a histogram, because measurement is probabilistic by physics, not by bug.

Dynamic circuits — branching on mid-circuit measurement — are a current frontier, not a solved default: Qiskit v2.5 (July 14, 2026) still lists exposing classical control flow (if/else, while, for) outside Python as a headline feature.

Which SDKs exist, and who actually uses what?

Four SDKs cover most of the open field, and the gap between first and second is wide. In the Unitary Foundation’s 2025 survey (997 respondents answered this question; multiple selections allowed) Qiskit leads at 69.1%, PennyLane follows at 30.8%, Cirq at 17.5%, NVIDIA’s CUDA-Q at 16.2%, the Braket SDK at 12.1% and Microsoft’s Q# at 8.3%. Two simulator engines rank as high as the SDKs themselves — Qiskit Aer at 47.7% and PennyLane Lightning at 17.3% (same survey) — which says where the day-to-day work actually happens: on classical simulators, not on QPUs. On the managed-cloud side, 65.5% of 852 respondents use the IBM Quantum Platform.

Reading discipline before quoting these numbers anywhere: the survey samples the open-source community that answers surveys, and shares are multi-select — they do not sum to 100. Usage measures attention, not quality. See “What we don’t know”.

What does each layer of the stack do?

Every SDK is the same four-layer machine: a circuit library on top, a transpiler under it, a runtime that talks to backends, and the backend itself. In 2026 the movement worth tracking is in the middle two layers.

The transpiler is where the engineering happens. Qiskit v2.4 (April 20, 2026) made gridsynth the default RZ synthesis, which IBM says “produces substantially lower T counts”; v2.5 (July 14, 2026) added dedicated Clifford+T and Pauli-based-computation pipelines, with IBM’s own benchmarks showing “some workloads compiling in roughly half the time” of v2.4. Both figures are vendor-run — no independent, pre-registered cross-SDK compiler benchmark exists in the public record we could cite today.

The runtime is the billed door to hardware. IBM renamed Qiskit Runtime Service to IBM Quantum Compute Service alongside v2.5 — same API, clearer split between the open SDK and the paid service. The frontier here is latency: Backline, announced by Xanadu and AMD on September 10, 2026, is an open-source PennyLane feature suite targeting classical–quantum loop times “under 3 microseconds” — a vendor-declared figure, and one that will matter most when error correction runs inside the loop.

What can you run for free — and where does paying start?

Everything up to the QPU costs $0. The four SDKs are Apache-2.0 (PyPI), and each ships a local simulator that runs on your own machine — AWS’s pricing page itself points beginners to “the free local simulator in the Amazon Braket SDK” (AWS). On managed hardware, free is measured in minutes: IBM’s Open Plan includes up to 10 minutes of QPU time per 28-day rolling window, us-east region only, and since March 16, 2026 active Open Plan users can opt into an additional 180 minutes over 12 months; AWS’s Free Tier covers 1 hour per month of on-demand simulator time for the first 12 months.

Past the free tier, QPU billing is per task plus per shot, and the spread across machines is the real lesson: on AWS’s own pricing page, a 10,000-shot job on Rigetti’s Cepheus costs $4.55 ($0.30 per task + $0.000425 per shot), while 2,500 shots on IonQ Forte with error mitigation cost $200.30 ($0.30 + $0.08 per shot, 2,500-shot minimum). Why those numbers are not comparable across vendors — different units, different minimums — is our provider guide’s whole subject; the house rule stands: a pilot that starts on a QPU is burning budget it did not need to burn.

How do you start without marrying a vendor?

Pick any of the four and hold two disciplines. First, keep circuits portable: OpenQASM 3 and QIR exist precisely so a circuit outlives its SDK, and the real lock-in is prepaid credits and non-transferable cost models, not the software. Second, keep the abstraction thin at the bottom: PennyLane treats backends as plugins — one program, many devices — and since February 24, 2026 its compilation layer also plugs into the Munich Quantum Toolkit, an academic compiler stack. Staff accordingly: the first profile a quantum project needs is a software engineer beside a strong classical-optimization baseline, not a resident physicist.

What we don’t know

• Whether the survey shares generalize. The UF survey samples a self-selected open-source community, partly recruited through the SDK vendors’ own channels; multi-select shares do not sum to 100. Usage measures attention, not quality.
• Which transpiler actually wins. The compile-time and T-count improvements above are IBM’s own benchmarks; no independent, pre-registered cross-SDK compiler comparison is in the public record we could cite today.
• The closed layer. Vendor-internal toolchains are invisible to an open-source survey; the public record on their real usage is thin.
• Whether any of this moves the scoreboard. An SDK is a steering wheel, not an engine: the advantaged-solve count on the Rosetta ledger remains 0 whichever one you install.
• Our own scope. Rosetta Quantum has not run a head-to-head SDK benchmark in-house; every figure above comes from the linked public record.

Rosetta Quantum publishes verdicts with raw, reproducible data. This is educational content, not a product claim.