oqc-qcaas-sdk

A Python SDK for Oxford Quantum Circuits’ Quantum Computing as a Service platform, built for modern async Python workflows.

Note

This is an early release and the public API may change before 1.0.0.

  • Natively async — all I/O uses httpx.AsyncClient; no blocking wrappers

  • Uses mutable Job objects — no juggling of task IDs

  • Makes success and failure obvious via job.completed, job.error, job.raise_for_status(), and clear repr() output

  • Records execution history within each job object

  • Supports save and load — persist jobs to JSON and restore in a later session

Note

Upgrading from oqc-qcaas-client? See Migrating from oqc-qcaas-client for side-by-side code comparisons that show exactly what changes.

Documentation for oqc-qcaas-client is available at: docs.oqc.app

Core Concepts: Job and CompositeJob

The SDK provides two execution objects.

Job — a single quantum program submission:

job = sdk.create_job(program=qasm, qpu_id="qpu:uk:2:d865b5a184")
outputs = await job.execute()      # submit → poll → return outputs
print(job.result, job.error)       # latest result / error
print(job.history.all())           # every run ever made on this job

CompositeJob — multiple programs submitted and polled together. Pass a list of programs to create_job() and the SDK creates a CompositeJob with one child Job per program:

composite = sdk.create_job(program=[prog_a, prog_b], qpu_id="qpu:…")
outputs = await composite.execute() # batch submit + concurrent poll
print(composite.completed_jobs)    # children that succeeded
print(composite.failed_jobs)       # children that errored

Shared interface

Both Job and CompositeJob expose the same core surface:

  • outputs — a JobOutputProxy holding results/errors for the latest run

  • history — a JobOutputProxy of every run output ever produced

  • completed — True when every constituent run succeeded

  • execute(timeout_s=…) — submit (or re-submit), poll, return outputs

  • cancel_if_active() — cancel in-flight work; no-op if already finished

Where they differ

  • State scope: Job has a single state property; CompositeJob has per-child state via active_jobs and terminal_jobs.

  • Result data: job.result.data for a single Job; outputs.all() iterates every child result for a CompositeJob. Both types return a JobOutputProxy from execute() — see Accessing Results.

  • Re-execution: Calling execute() again on a finished Job resets and resubmits it. CompositeJob applies this per-child — finished children are reset and resubmitted while in-flight children are only polled.

  • Cancellation: cancel_if_active() on a Job guards one task; on a CompositeJob it applies to all children concurrently.

Contents

OQC QCaaS SDK