Quantinuum and Oracle Open OCI Quantum AI Compute Beta for Helios Access
Oracle Cloud Infrastructure (OCI) customers woke up this morning to a new tile in their console: Quantum AI Compute. The beta program, announced jointly by Quantinuum and Oracle and reported by the Quantum Computing Report this morning, puts Quantinuum's Helios trapped-ion system behind an OCI-native API surface. For backend engineers, the immediate question is not whether quantum advantage has arrived. It is whether the integration model, job semantics, and billing shape make sense for production pipelines that already run on OCI compute, object storage, and streaming.
The beta is invitation-only and limited to a set of OCI tenancies in us-ashburn-1 and eu-frankfurt-1. Access is granted through a new IAM policy verb, QUANTUM_INVOKE, and the service is exposed as quantum-ai-compute in the OCI CLI. Quantinuum is handling the physical backend; Oracle is handling identity, networking, and the queueing layer that sits between customer code and the Helios control stack.
What Helios Actually Exposes to OCI Tenants
Helios is Quantinuum's latest trapped-ion device, and the beta exposes it through three interfaces: a REST endpoint under https://quantum-ai-compute.{region}.oci.oraclecloud.com, a Python SDK (oci-quantum), and a QIR-based submission path for teams that already compile to LLVM-style quantum IR. The device itself is not co-located with OCI regions; jobs are forwarded over a dedicated interconnect to Quantinuum's facility, which means round-trip latency for job submission is measured in hundreds of milliseconds, not microseconds. That matters for anyone tempted to treat the API like a local simulator.
The noise_model parameter is worth flagging. The beta defaults to calibrated, which applies the most recent device calibration snapshot to the returned distribution. Setting it to raw returns unmitigated counts, and mitigated runs a zero-noise extrapolation pass server-side. Each mode has a different billing multiplier, which we will get to.
Job Semantics, Queuing, and the Cost of Waiting
The beta does not offer dedicated device time. Jobs enter a shared queue with priority tiers tied to OCI tenancy type. During the first 24 hours of the beta, observed queue depths for standard tenancies ranged from 40 seconds to just over 11 minutes for a 4,096-shot job on 12 qubits. That is not a latency figure you can hide behind a synchronous HTTP call in a request path. The SDK's wait() is a polling wrapper, and Oracle's documentation recommends event-driven consumption through OCI Events rather than blocking threads.
For teams building hybrid workflows, the practical pattern is to treat quantum jobs like batch inference: submit, persist the job ID to Object Storage or a database, and resume on a completion event. The beta supports OCI Events of type com.oraclecloud.quantumai.JobCompleted, which can trigger a Functions invocation or a Streaming message. That is a reasonable design, but it does mean the quantum call cannot live inside a tight classical optimization loop without restructuring. Variational algorithms that need hundreds of sequential circuit evaluations will pay the queue latency on every iteration unless they batch submissions, and batching is capped at 256 circuits per request in the beta.
Billing Model and the Per-Shot Multiplier
The beta bills per shot with a backend multiplier, and the multipliers are not trivial:
| Mode | Multiplier | Effective cost per 1k shots (beta list) |
|---|---|---|
| raw | 1.0x | $0.42 |
| calibrated | 1.6x | $0.67 |
| mitigated | 3.4x | $1.43 |
These are beta list prices and Oracle has stated they will be revisited at general availability. The multiplier on mitigated is the one that will shape architecture decisions. Zero-noise extrapolation typically requires running the same circuit at multiple noise scale factors, so a single logical result can consume three to five times the shots of a raw run before the multiplier is even applied. Teams that default to mitigated without measuring whether it improves their observable will burn budget quickly.
There is also a fixed per-job submission fee of $0.008, which sounds negligible until you consider that a poorly batched variational loop can generate thousands of jobs per hour. The beta console exposes a per-tag cost breakdown, and Oracle recommends tagging every submission with a pipeline identifier so chargeback does not become an archaeology project.
Identity, Networking, and the IAM Surface
The integration reuses OCI IAM rather than introducing a separate Quantinuum identity plane, which is the right call for enterprise adoption. A policy granting submission rights looks like:
The service supports resource principals, so Functions and OKE workloads can submit jobs without embedding user credentials. Private endpoint access is available through a service gateway, and Oracle states that job payloads are encrypted in transit and at rest with customer-managed keys. For regulated workloads, the beta currently does not offer a dedicated-tenant device partition; all beta jobs share the same Helios calibration window. That is a real constraint for anyone hoping to run calibration-sensitive experiments alongside noisy neighbors.
Where the Integration Fits and Where It Does Not
The honest read is that this beta is an integration milestone, not a capability milestone. Helios is a real device with published gate fidelities, and putting it behind OCI IAM and Events removes a meaningful amount of operational friction for teams already standardized on Oracle Cloud. The queue semantics, tagging, and event model are familiar to anyone who has worked with OCI Data Science or OCI Batch. That familiarity is the point.
The constraints are equally clear. Shared calibration windows, a 256-circuit batch cap, queue latencies in the minutes, and a mitigation multiplier that can triple effective cost all argue against treating this as a low-latency primitive. The teams that get value from the beta in the next quarter will be those running offline or batch-oriented workloads: chemistry simulations, portfolio sampling experiments, and calibration studies where a few minutes of queue time is irrelevant against a multi-hour classical post-processing step.
Quantinuum and Oracle have not published a general availability date. The beta application form is live in the OCI console under Quantum AI Compute, and Oracle's documentation points to the OCI Quantum AI Compute service page for the current region list. For backend architects, the useful next step is not to port a production pipeline. It is to stand up a tagged, event-driven submission harness against the beta and measure queue depth, mitigation uplift, and cost per observable before committing any real workload to the queue.