Built for the multi-chip era of quantum

The compiler for multi-chip quantum computing.

Quantum hardware is going modular. The next generation isn't one giant chip but networks of chips stitched together by photonic interconnects. Limbo partitions your circuit across QPUs, picks the vendor whose topology matches your algorithm, and routes cross-chip operations as first-class objects.

Join the waitlist Read the docs

Headline numbers · see the full benchmark

Wins or ties

19 / 21

benchmark cells across 4 workload families

Cut reduction

up to 42%

vs leading multi-chip compiler

vs naïve baseline

63%

avg cut reduction vs no graph analysis

VQE amortization

100×

parametric circuits compile once

Why multi-chip is the future

Quantum is going modular. Every vendor's roadmap says so.

Single chips can't scale to fault tolerance on their own. The physics and engineering fight back as they grow. The industry's answer: connect many smaller chips into one logical machine.

IBM

Quantum System Two

Multiple Heron chips linked today, with deeper integration on the roadmap. IBM's stated path to 100k+ qubit systems.

IonQ + Quantinuum

Multi-zone trapped-ion architectures. Quantinuum's H-series already runs separate traps as one logical device.

Photonic interconnect

PsiQuantum, QuEra, and Rigetti are racing to link qubits across chips with photons. Once it lands, every algorithm becomes a cross-chip routing problem.

Most quantum stacks were built for one chip and retrofitted for many. Limbo is the inverse: multi-chip first, single-chip as a degenerate case. Designed for networked hardware from day one.

Smart vendor routing

Topology first. Queue depth as the safety check.

We classify your circuit by interaction-graph shape and send it to the vendor whose physical layout matches. If the topology winner has a long queue, we re-check whether a runner-up with empty seats would actually finish faster end-to-end, and only then do we swap.

A↔A

Dense / hub-heavy circuits

QFTs, hub-and-spoke patterns, dense QAOA → trapped-ion all-to-all hardware (IonQ Aria/Forte, Quantinuum H). No SWAP penalty.

▦

Lattice-friendly circuits

Nearest-neighbor circuits (hardware-efficient ansatze, surface-code subroutines) → superconducting lattices (IBM Heron, Rigetti Ankaa, IQM Garnet).

⌬

Modular circuits

Independent sub-problems that cluster naturally → our hypergraph partitioner places them on separate QPUs with minimal cross-chip traffic. Any vendor works.

Step 1 · Topology fit (primary)

Hardware mismatch always costs you. The wrong layout inflates both runtime and error rate. We default to the vendor whose physical layout natively matches your circuit.

Step 2 · Queue check (tiebreaker)

If the topology winner has a long queue and a runner-up would finish sooner end-to-end, we route to the runner-up. Otherwise we stay with the topology pick.

Want to see the recommendation before you submit? Hit POST /analyze with your QASM and get back the topology family, confidence, and ranked vendor list. No transpile, no execution, no charge.

Why Limbo

One pipeline, every quantum cloud.

Multi-chip compilation is dominated by partitioning and routing. We prioritize both, and give you a Python SDK that hides the vendor lock-in.

Built for multi-chip

Every layer of Limbo assumes the target is a network of chips, not a single monolithic one. The modular hardware every vendor is building next is our default case.

Topology-aware vendor routing

We classify your circuit by interaction shape and pick the cloud vendor whose physical layout matches. Dense circuits go to all-to-all hardware. Lattice-shaped circuits go to lattice hardware. Modular circuits go wherever fits.

Smart partitioning

Multi-qubit gates count as a single cross-chip cost, so the optimization tracks what you actually pay on real hardware. No double counting.

Multi-framework input

Drop in a Qiskit, Cirq, or OpenQASM circuit. We translate each into one uniform form. No provider-specific glue code on your side.

Hardware-aware transpile

We pull each device's actual layout and native gates from the vendor in real time. IBM, IonQ, Rigetti, IQM, and Quantinuum hardware all hit their real targets.

Variational fast-path

Compile a parametric circuit once, then stream new parameters on every iteration. A 100-step VQE pays the heavy compile a single time.

Pipeline

From your Python file to a quantum backend.

The SDK runs the first three steps locally so capacity errors and structural mistakes never burn a paid cloud call.

# Install once, target every quantum cloud
$ pip install limbo-quantum

# Three lines to compile + run
from qiskit import QuantumCircuit
from limbo import DistributedCompilerSDK, CloudProductionProvider

sdk = DistributedCompilerSDK(
    provider=CloudProductionProvider(
        api_key="qra_live_…",
        server_url="https://api.limbosys.dev",
    ),
    num_qpus=4,
    max_capacity_per_qpu=20,
)
qc = QuantumCircuit(8)
qc.h(0); qc.cx(0, 1); qc.measure_all()

result = sdk.compile(qc, shots=1024)
print(result.counts)

Step A · Ingest
Multi-framework parser. Qiskit, Cirq, or OpenQASM-3 in. One uniform IR out. Zero network.
Step B · Lint
Local static checks. Capacity audit rejects un-routable layouts. Hotspot detection surfaces the qubits that will dominate cross-chip traffic.
Step C · Template cache
Variational fast-path. Same parametric ansatz with new floats? Bind locally, ship only the bound circuit. No re-partitioning.
Step D · Dispatch
Server KaHyPar + hardware-aware transpile. Topology-routed to IBM / AWS / Azure with the device's real coupling map and native gates.

Reserve your seat.

Limbo is in closed access. Join the waitlist and we'll email you the moment your seat opens.

Join the waitlist