Execution backends¶
Limbo doesn't lock you into one execution path. The SDK is built around a narrow QuantumProvider interface with shipped implementations and a documented extension point.
| Scenario | Use |
|---|---|
| Prototyping, CI, anything Aer can run | Local · LocalSimulationProvider |
| You already have IBM / AWS / Azure quotas | Direct to a vendor · IBMProvider / AWSProvider / AzureProvider |
| Anything else (Quantinuum, IonQ direct, custom) | Bring your own · subclass QuantumProvider |
| One key, multi-chip-aware compile server-side | Hosted · CloudProductionProvider (not yet available) |
Local simulator¶
No account, no network.
from limbo_quantum import DistributedCompilerSDK, LocalSimulationProvider
sdk = DistributedCompilerSDK(
provider=LocalSimulationProvider(),
num_qpus=2, max_capacity_per_qpu=4,
)
Direct to a vendor¶
If you already have vendor quotas, the SDK ships wrappers for the three major clouds. Install the matching extra and pass an instance to the SDK; no subclassing needed.
# pip install 'limbo-quantum[aws]'
from limbo_quantum import DistributedCompilerSDK, AWSProvider
sdk = DistributedCompilerSDK(
provider=AWSProvider(
device_arn="arn:aws:braket:::device/quantum-simulator/amazon/sv1",
),
num_qpus=1, max_capacity_per_qpu=34,
)
# Credentials: the standard boto3 chain (env vars, ~/.aws/credentials, IAM role).
# pip install 'limbo-quantum[azure]'
from limbo_quantum import DistributedCompilerSDK, AzureProvider
sdk = DistributedCompilerSDK(
provider=AzureProvider(
subscription_id="...",
resource_group="quantum-rg",
workspace_name="my-workspace",
location="eastus",
target_name="ionq.qpu",
),
num_qpus=1, max_capacity_per_qpu=23,
)
# Auth: DefaultAzureCredential (az login, managed identity, or SP env vars).
All three handle QASM-to-vendor translation, submission, status polling and result decoding. They import their vendor SDK lazily, so import limbo_quantum stays fast with only one extra installed.
Bring your own backend¶
Targeting something else? Subclass QuantumProvider and implement three methods:
from limbo_quantum import QuantumProvider, Job, JobResult
class MyBackend(QuantumProvider):
name = "mine"
def submit(self, payload, *, shots=1024, **options) -> Job:
"""Send compiled QASM. Return a Job."""
...
def _fetch_status(self, job_id: str) -> JobResult:
"""Poll. Return a JobResult with status in
{queued, running, completed, failed}."""
...
def list_devices(self) -> list[dict]:
"""Optional device catalog for auto-routing. May be []."""
...
The shipped IBM, AWS and Azure providers in limbo_quantum/vendors.py are full reference implementations of this pattern.
Hosted backend¶
Not yet available
The hosted compile service is still being built. Until it launches, run everything locally or directly against a vendor. The client below ships in the SDK so your code won't need to change when it does.
CloudProductionProvider is the HTTP client for the hosted Limbo service, which will run the multi-chip-aware partitioner and cross-chip scheduler server-side.
from limbo_quantum import DistributedCompilerSDK, CloudProductionProvider
sdk = DistributedCompilerSDK(
provider=CloudProductionProvider(api_key="lmb_live_...", server_url="https://api.limbosys.dev"),
num_qpus=4, max_capacity_per_qpu=20,
)
auto_provider() reads LIMBO_API_KEY and LIMBO_SERVER_URL from the environment and falls back to the local simulator when neither is set. That makes it a safe default today.