GitHub Repos advanced 3 min read May 25, 2026
Public Preview Sign in free for the full digest →

IBM keeps the QPU stack closed. OQTOPUS open-sources it.

“IBM, AWS, and Azure all run server-side transpilation and multi-programming near the QPU — and all three keep that code proprietary. OQTOPUS is the first to open-source it, including the implementation that directly touches the quantum chi...”

IBM keeps the QPU stack closed. OQTOPUS open-sources it.
1 Views
0 Likes
0 Bookmarks
Source · oqtopus-team.github.io

“"The design of quantum computing systems, especially in the most critical areas near quantum computers, remains largely undisclosed, creating a significant barrier to entry into the quantum computing field. If this situation continues, progress toward standardization, which is e...”

You know that feeling when you acquire expensive specialized hardware and then discover that the entire operational software environment for it has to be built from scratch? Every university or company that operates a quantum computer and wants to offer remote access has had to independently develop job queuing, user authentication, circuit transpilation, error correction, and a calibration dashboard. None of that is research — it is infrastructure tax. IBM built theirs. AWS built theirs. Neither open-sourced it. The result: each new quantum operator re-implements the same stack, alone.

quantum-computingopen-sourcepythoncloud-infrastructureawsresearchqcaas

Think of OQTOPUS as a full kitchen-to-table operation for quantum computing: you write a quantum circuit in Python using the QURI Parts SDK, which converts it to OpenQASM 3 (a standardized circuit description) and sends it to OQTOPUS Cloud — a serverless AWS stack that authenticates you via Cognito, stores your job in RDS, and queues it for execution. The OQTOPUS Engine on the backend polls that queue, passes your circuit to Tranqu Server for transpilation (rewriting the circuit to match the chip's specific qubit topology and gate set), then sends pulse instructions through the Device Gateway to the physical quantum processor. After the QPU runs, results flow back through the same chain: raw measurement outcomes pass through the readout error mitigator and arrive at your Python client as a corrected probability distribution.

01
Server-Side Transpilation (publicly available) — circuit optimization runs on the provider's server, not your laptop. IBM, AWS, and Azure all do this but keep the code closed; OQTOPUS ships the full implementation under Apache 2.0 so you c...
02
Server-Side Execution — you submit a full quantum-classical hybrid program once and the backend runs the entire sampling iteration loop without re-queuing per shot. VQE and quantum machine learning workflows stop burning queue slots on eve...
03
Multi-Programming — the engine packs multiple users' circuits into one combined circuit and runs them on the chip simultaneously, improving QPU throughput. Per Table I of arxiv:2507.23165, this is the only publicly available implementation...
04
Readout Error Mitigation — a 1-qubit tensor product mitigator tunes automatically to real-time device conditions rather than static calibration snapshots. Unlike standalone Qiskit, the correction adapts to what the chip is actually doing a...
05
Tranqu Transpiler Framework — run the same circuit through multiple transpilers (currently Qiskit and Osaka University's ouqu-tp) and pick the best compiled result. Transpiler quality for quantum circuits is NP-complete and varies widely b...
06
QDash Calibration Platform — a web dashboard that runs QPU calibration experiments as reproducible, documented workflows and stores the full history. Calibration quality on current NISQ devices is the dominant source of performance varianc...
07
Schema-Driven OpenAPI Contract — the cloud layer auto-generates FastAPI code from OpenAPI specs via datamodel-code-generator, keeping specification and implementation in sync. Third-party frontends and SDKs get a stable, documented REST co...
Who it’s for

This is for you if you operate a physical quantum computer — at a national lab, research university, or hardware company — and want to offer remote cloud access without building job management, user auth, transpilation, and calibration infrastructure from zero. Specifically designed for institutions running superconducting QPUs with pulse controllers. Not useful if you want to use a quantum computer as a researcher, need a simulator, or run on GCP or Azure — the cloud layer is hardwired to AWS-specific services with no alternative provider support.

Worth exploring

Worth evaluating if your institution operates quantum hardware and wants a documented, production-tested software baseline rather than building from scratch. Osaka University runs it in production and 22 public releases over 14 months show sustained engineering investment from Fujitsu. Pause if your organization runs on GCP or Azure — the entire cloud layer ties directly to five named AWS services, and porting requires rebuilding that tier completely.

Developer playbook
Tech stack, code snippet, sentiment, alternatives.
PM playbook
Adoption angles, user fit, positioning.
CEO playbook
Traction signals, ROI, build vs buy.
Deep-dive insight
Full long-form analysis, no fluff.
Easy mode
Core idea, fast — when you need the gist.
Pro mode
Technical nuance, edge cases, tradeoffs.
Read the full digest
Go beyond the preview

Deep-dive insight, Easy and Pro modes, plus action playbooks — the full breakdown is one tap away.

Underrated tools. Unfiltered takes.

Read the full digest in the Snaplyze app for deep-dive insight, Easy and Pro modes, and the playbooks you can actually use.

Install Snaplyze →