DEV Community: EigenOrbit

One Python codebase, every quantum computer: running the same circuit on IonQ, IQM and IBM

EigenOrbit — Mon, 09 Nov 2026 13:58:27 +0000

Most quantum code lives on a simulator. Moving it to real hardware is where the work starts: each provider has its own account, keys, billing and SDK objects, and comparing two quantum computers on your own circuit means setting up both. This post walks through a setup where the circuit is written once, the device is a string, and one API key with one prepaid balance works across many quantum providers: today IonQ, IQM, Rigetti, AQT and IBM, plus cloud simulators, with more providers planned.

It uses two pieces: eigenkit, a Python library that describes a circuit once and runs it on many backends, and EigenOrbit Router, a hosted service that sends eigenkit jobs to the quantum providers for you. Both are ours, so read the rest with that in mind.

What usually stands between a circuit and a QPU

To run one circuit on quantum computers from two or three providers with your own credentials, you usually need:

an account with each cloud or hardware provider, often with its own contract;
cloud permissions, storage for results, the right region for each device and spending limits;
a separate API key and SDK setup per provider;
a way to know what a run costs before it lands on the bill.

For a team with existing cloud contracts this is a one-time cost. For a student, a researcher trying a second device or a small team comparing providers, it is often where the experiment stops.

The circuit, written once

eigenkit describes a circuit as data, separate from any SDK. Here is a small variational circuit with two qubits:

import numpy as np
from eigenkit import Circuit
from eigenkit.core.blocks import AngleEncoding, BasicVariational, assemble
from eigenkit.core.observables import all_z

spec = assemble([
    AngleEncoding(in_features=2),
    BasicVariational(depth=1),
])
weights = np.linspace(-0.9, 1.1, spec.n_weights)
inputs = np.array([0.2, 0.6])

On a local simulator you pass a provider name:

print(Circuit(spec, all_z(2), provider="numpy")(weights, inputs))

The device as a string

With the router extra, the same circuit runs on cloud simulators and QPUs through one key:

pip install "eigenkit[router]"
export EIGENORBIT_ROUTER_API_KEY=eo_live_...

from eigenorbit_router_client import RouterConfig

# Every device ID is listed in the public catalog
devices = {
    "SV1 simulator": RouterConfig(device="braket/sv1", shots=1000),
    "IQM Garnet":    RouterConfig(device="braket/iqm_garnet", shots=100),
    "IBM Fez":       RouterConfig(device="ibm/ibm_fez", shots=4000),
}

for name, provider in devices.items():
    circuit = Circuit(spec, all_z(2), provider=provider)
    print(name, circuit(weights, inputs))

The loop is the whole comparison. The circuit, the observables and the post-processing stay the same, and the results have the same shape, dtype and bit order as a run with each provider's own credentials. We checked this on real runs on two cloud simulators and on QPUs from IQM and IBM. When a new provider is added to the router, it appears as one more device ID, and the code around it does not change.

The key comes from the router web app: sign in, top up a prepaid USD balance and create a key. Jobs on IBM devices run on your own IBM Quantum account, which you connect once in the app; the router charges nothing for them, and IBM bills your account directly.

Knowing the price first

Building a circuit on a paid device asks the router for an estimate and shows a CostWarning with the price of one job, split into the provider's cost and the EigenOrbit fee, and your available balance. circuit.dry_run_info() returns the same estimate as a dict (estimate_usd_micro, available_usd_micro and the gate counts of the circuit) without sending a job, which is handy in a notebook before a long batch.

For QPUs priced per job and per shot, the estimate equals the final charge: 100 shots on IQM Garnet come to about $0.53. Cloud simulators are billed by run time, and a short simulator job costs well under a cent.

The router reserves the estimate on the balance before it sends the job, so a job your balance cannot cover never starts. After the run it charges what the provider reported and returns the rest.

Waiting for a long queue

A QPU queue can be long. Instead of a blocking call you can submit the job and keep working:

handle = circuit.submit(weights, inputs)
print(handle.job_id(), handle.status())

# later in the same session
values = handle.result()

handle.status() is one non-blocking request, and handle.result() waits for the job. The router watches the provider's queue itself, so the job keeps running if you close the notebook: its result stays on the Jobs page of the web app, which lists jobs from every provider with status, cost and result.

Small things that help in practice

Spending limit per API key. A key can go to a student or into CI with a fixed budget.
Retries without double charges. The client retries dropped connections with the same idempotency key, so a flaky network never creates a second paid job.
Errors you can branch on. Every failure is a RouterError with a stable code such as insufficient_balance, device_unavailable or shots_invalid.
Provider-specific options where they matter. For example, error suppression options on IBM devices go through primitive_options, in the same shape as eigenkit's own IBM config.
A public device catalog. router.eigenorbit.com/devices shows every device ID, price, shot range and availability window without sign-in.

When to use your own credentials instead

If your organization already has a contract with a quantum cloud provider at negotiated prices, or you need hybrid jobs or reserved sessions, use eigenkit with your own credentials: the circuit code stays the same and only the provider changes. The router fits best when you want to try several devices without opening several accounts, give hardware access to students or a team with a budget, or keep the cost of each run visible before it happens.

Providers and devices

The catalog changes as providers and devices are added, so check router.eigenorbit.com/devices for the current list. In November 2026 it has:

Quantum provider	Devices	Qubit technology
IonQ	Forte 1, Forte Enterprise 1	Trapped ions
AQT	IBEX Q1	Trapped ions
IQM	Garnet, Emerald	Superconducting
Rigetti	Cepheus-1-108Q	Superconducting
IBM (on your own IBM account)	ibm_fez, ibm_kingston, ibm_marrakesh	Superconducting
Cloud simulators	SV1, DM1	State vector and density matrix

IonQ, AQT, IQM, Rigetti and the simulators are reached through Amazon Braket and paid from the EigenOrbit balance; IBM devices go through IBM Quantum.

More providers and devices are coming soon. Follow EigenOrbit to see each one as it is added.

eigenkit: write a quantum circuit once, run it on any backend

EigenOrbit — Mon, 09 Nov 2026 13:25:27 +0000

Every quantum SDK has its own circuit objects. A model written for PennyLane has to be rewritten to run on Qiskit Aer, and rewritten again for an IBM or IQM device. Comparing backends on your own workload turns into integration work.

We built eigenkit to remove that step. It is an open-source Python library (Apache-2.0) that describes a circuit once, as data, and lets each backend compile that description into its own SDK. Moving to another simulator or a QPU means changing the provider= argument.

pip install eigenkit

The core install is numpy, scipy and pydantic. PyTorch, scikit-learn and every quantum SDK are optional extras.

One circuit, four simulators

A small IQP circuit: Hadamards, a ring of ZZ rotations, Hadamards again.

from eigenkit import Circuit, CircuitBuilder, Z

def iqp(n, edges, angles):
    qc = CircuitBuilder(n_qubits=n)
    for q in range(n):
        qc.h(q)
    for (i, j), angle in zip(edges, angles):
        qc.pauli_exponential((("Z", i), ("Z", j)), angle)
    for q in range(n):
        qc.h(q)
    return qc.build()

spec = iqp(4, [(0, 1), (1, 2), (2, 3), (3, 0)], [0.7, 1.1, 0.4, 1.9])
observables = [Z(0) * Z(1), Z(1) * Z(2), Z(0) * Z(1) * Z(2) * Z(3)]

for provider in ["numpy", "pennylane", "qiskit-aer", "qulacs"]:
    print(provider, Circuit(spec, observables=observables, provider=provider)([]))

numpy       [0.46548538 0.11841725 1.        ]
pennylane   [0.46548538 0.11841725 1.        ]
qiskit-aer  [0.46548538 0.11841725 1.        ]
qulacs      [0.46548538 0.11841725 1.        ]

numpy is the built-in simulator and needs nothing extra. The others come with pip install "eigenkit[pennylane,qiskit,qulacs]".

The current list of simulators: numpy, PennyLane, Qiskit, Qiskit Aer (statevector and MPS), Qulacs, qsim, TensorCircuit, CUDA-Q and Amazon Braket.

The same code on hardware

On a QPU the provider becomes a device config. The rest of the program stays the same:

from eigenkit import IQMConfig, QiskitRuntimeConfig

devices = {
    "IBM Heron": QiskitRuntimeConfig(backend_name="ibm_kingston", shots=8192, primitive="sampler"),
    "IQM Emerald": IQMConfig(quantum_computer="emerald", shots=8192),
}
for name, device in devices.items():
    print(name, Circuit(spec, observables=observables, provider=device)([]))

Hardware access goes through IBM Qiskit Runtime, IQM Resonance and the QPUs on Amazon Braket. Photonic circuits run on Quandela's Perceval.

Real hardware costs money, so the library guards against accidental spending. Compiling for a paid device raises a CostWarning, and dry_run_info() previews a job before it is submitted. Gradients on hardware are opt-in (enable_gradients=True), since one backward pass runs at least two jobs per weight.

A circuit fits the classical stack

Circuits can also be assembled from ready-made blocks. With the default interface a circuit is a numpy function, and the gradient is one call away:

import numpy as np
from eigenkit import Circuit, Encoding, Variational, all_z

circuit = Circuit(
    blocks=[Encoding(in_features=4), Variational(depth=2)],
    observables=all_z(4),
)

weights = np.zeros(circuit.spec.n_weights)
x = np.random.uniform(0, np.pi, size=(8, 4))   # a batch of 8 samples
y = circuit(weights, x)                         # shape (8, 4)
grad = circuit.jacobian(weights, x[0])          # no torch needed

With interface="torch" the same circuit becomes a torch.nn.Module that owns its weights and trains inside a larger model with a standard optimizer. The ready-made models (hybrid networks, quantum kernels, reservoir computing) follow scikit-learn's fit / predict, so they work with Pipeline and GridSearchCV.

Checking the result against classical models

A quantum model is only interesting next to a good classical baseline. compare() trains quantum and classical models on the same data over several seeds and reports mean and spread:

from sklearn.svm import SVC
from sklearn.ensemble import RandomForestClassifier
from eigenkit import QSVC
from eigenkit.benchmark import compare

result = compare(
    {"QSVC": QSVC(), "SVC (RBF)": SVC(), "Random forest": RandomForestClassifier()},
    dataset="iris",
    n_seeds=5,
)
print(result.table())

On our run:

┌───────────────┬───────────────┬───────────────┬──────────────────┬───────────────────┐
│ Model         │ Accuracy      │ F1            │ Fit time (s)     │ Predict time (s)  │
├───────────────┼───────────────┼───────────────┼──────────────────┼───────────────────┤
│ QSVC          │ 0.974 ± 0.039 │ 0.973 ± 0.040 │ 0.0022 ± 0.00039 │ 0.00075 ± 2e-05   │
│ SVC (RBF)     │ 0.965 ± 0.036 │ 0.965 ± 0.037 │ 0.0012 ± 9.3e-05 │ 0.00023 ± 3.2e-05 │
│ Random forest │ 0.957 ± 0.053 │ 0.956 ± 0.054 │ 0.095 ± 0.0091   │ 0.0049 ± 0.00017  │
└───────────────┴───────────────┴───────────────┴──────────────────┴───────────────────┘

The quantum kernel has the highest mean accuracy. result.significance_test("accuracy") runs a Wilcoxon test across seeds, and every pairwise p-value comes out at 0.5 or higher. On iris the three models are statistically tied, and the classical SVC predicts about three times faster. That is the kind of answer compare() is there to give.

The qml and benchmark extras are needed for this example. eigenkit.datasets ships 12 datasets for classification, regression and time series.

What else is inside

Optimization: QUBO / Ising, Max-Cut, QAOA.
Chemistry: Jordan-Wigner and Bravyi-Kitaev mappings, UCCSD, VQE, molecular Hamiltonians through PySCF and OpenFermion.
HHL, iterative amplitude estimation (IQAE) and portfolio risk (VaR / CVaR).
Orthogonal networks of RBS gates for orthogonal fine-tuning and certified robustness.

Optimization and chemistry run on the core install. A four-node Max-Cut takes three lines:

from eigenkit.optimization import QAOA, max_cut

res = QAOA(layers=1, provider="numpy", random_state=0).solve(max_cut([(0, 1), (1, 2), (2, 3), (3, 0)]))
print(res.best_bitstring, res.best_energy)   # (1, 0, 1, 0) -4.0

Links

Which backend or dataset should we test next? Tell us in the comments.