The Ocean SDK is D-Wave's Python stack for working with quantum computers

What the SDK actually is

The repository's own description is short: it is the installer for D-Wave's Ocean tools.

That undersells it slightly, because the same repository is also the monorepo that contains the packages. The top-level entries show the split clearly: dimod, dwave-cloud-client, dwave-gate, dwave-graphs, dwave-hybrid, dwave-inspector, dwave-networkx, dwave-optimization, dwave-preprocessing, dwave-samplers, dwave-system, plus minorminer and penaltymodel, which are the C++ components vendored as submodules. There is a.gitmodules file, so those two come in as submodules rather than as Python packages.

So the metapackage on PyPI is a convenience, and the repository is where the work happens. The Ocean SDK is D-Wave's suite of tools for solving hard problems with quantum computers, and the documentation lives at docs.dwavequantum.com.

The important thing for a new user is that the packages divide into two groups. dimod, dwave-optimization and dwave-preprocessing work entirely on your machine, with no connection to D-Wave's hardware or cloud. dwave-system, dwave-samplers and dwave-cloud-client are the parts that talk to the cloud. dwave-inspector and dwave-networkx are tools for looking at results. dwave-hybrid and dwave-gate cover the hybrid solvers and the gates framework for running your own code on D-Wave hardware.

That division is what lets you develop and test your problem model without an account, and it is the practical reason the SDK is worth reading rather than just installing.

The licence is Apache-2.0, the primary language is Python, and the last push was on 2026-10-22, after the 9.5.0 release on 2026-09-15.

Installing it and getting an account

Installation from PyPI is a single command:

pip install dwave-ocean-sdk

The README points at the Ocean documentation's installation page for more information, and the metapackage pulls in the family of packages rather than requiring you to pick them one by one.

Then the part that is not a package manager question. Sign up for the Leap quantum cloud service, which is where the samplers live and where the hosted solvers are accessed. The Leap signup link is at cloud.dwavesys.com/leap/signup.

That is a deliberate design decision on D-Wave's part and it shapes the whole SDK. The quantum processing units are not something you can install, so the samplers in dwave-system are clients for a remote service, and the account is the credential that makes them work.

The learning resources are listed next and they cover different needs. The D-Wave documentation is the place to learn about quantum computers and how to use them. Get Started with Ocean Software covers installing and starting to code with the SDK. dwave-examples is a GitHub repository of code examples and Jupyter Notebooks. And the Resource Library on D-Wave's website holds whitepapers and additional resources.

The examples repository is the one to open in parallel with the SDK, because the API is compact enough that reading a worked example teaches it faster than the reference documentation does.

The example program and the shape of every program

The README gives one complete program, and it is short enough to be the whole API in miniature.

import dimod
import dwave.inspector
import dwave.system

bqm = dimod.generators.ran_r(1, 20)
sampler = dwave.system.EmbeddingComposite(dwave.system.DWaveSampler())
sampleset = sampler.sample(bqm, num_reads=100)
dwave.inspector.show(sampleset)

Five imports and five statements, and they divide into three phases.

The first phase is the problem. dimod.generators.ran_r(1, 20) generates a random problem of a given shape, and the result is a binary quadratic model. A BQM is the central data structure in the SDK, and the README links the concept documentation for it. It is a set of variables that each take a value of minus one or plus one, plus quadratic coefficients describing the interaction between pairs of them, which is exactly the structure of the problems these solvers are built for.

The second phase is the sampler, and the composition is the interesting part. dwave.system.EmbeddingComposite wraps dwave.system.DWaveSampler(), and embedding is what lets you solve a problem whose structure does not match the hardware's qubit connectivity. The README links the embedding guidance documentation, and the phrase on the right side of the inspector visualisation showing the qubits representing these variables on a quantum processing unit is a reminder that embedding is not free: your logical variables have to be mapped onto physical qubits, and the mapping is what the visualiser draws.

The third phase is the sampleset and the inspection. sampler.sample(bqm, num_reads=100) submits the problem and asks for a hundred reads, and dwave.inspector.show(sampleset) draws the result.

That last call is what makes the SDK worth the trouble of learning. The visualisation is described in the README: the left side represents the problem's variables as circles, with white dots for variables assigned values of -1 and blue dots for values of +1, and the colours of the connecting lines represent the values of the quadratic coefficients for each pair of variables. The right side shows the qubits representing these variables on a quantum processing unit.

So the inspector shows you both the logical answer and the physical embedding at the same time, which is the fastest way to see whether a problem was mapped sensibly.

The package family, and what each one contributes

The top-level directories map to a set of distinct jobs, and the naming is systematic enough to be worth decoding.

dimod is the problem model and the samplers' data structures. It is the one package you cannot avoid, since a BQM is what goes in and a sampleset is what comes out. dwave-system provides the samplers and the composition machinery, including the EmbeddingComposite that the example uses.

dwave-samplers covers the sampler implementations, and dwave-cloud-client is the layer that handles talking to the Leap cloud service, including the authentication that the account requires.

dwave-preprocessing works on the problem before it is sent. The natural preprocessing step in an annealing workflow is to take a model with a constraint structure and re-express it as a penalty on unconstrained binary variables, and that is what this package is for. dwave-optimization sits on the other side of the same idea and provides formulations for a set of standard optimisation problems.

minorminer and penaltymodel are the C++ components vendored in as submodules. Minorminer is the graph minor algorithm used to produce the embedding, and penaltymodel is the shared model of the penalty formulation. Having them as submodules rather than as separate PyPI packages means the C++ build is part of this repository's release, which is why the package metadata has a .clang-format file at the root.

dwave-inspector is the visualiser from the example, and dwave-networkx is the bridge to the NetworkX graph library, so an existing graph analysis workflow can consume the results.

dwave-graphs and dwave-gate are the newer pieces. The gates framework is for writing your own programs to run on D-Wave hardware, and dwave-graphs covers graph algorithms with a quantum angle. dwave-hybrid covers the hybrid solvers, which are classical algorithms that use a quantum sampler as a subroutine rather than relying on one for the whole problem.

That last one is worth flagging for anyone choosing an approach. The hybrid solvers exist because the useful quantum advantage, if it comes, is in a well-chosen subproblem rather than in the whole problem, and a hybrid workflow keeps the classical part of the solution in your own code.

How the project is built and released

The build configuration is small, and for a repository this size that is worth explaining.

The pyproject.toml declares only the build system, requiring setuptools at 46.4.0 or later along with wheel, and selecting the setuptools.build_meta backend. The setup.py is correspondingly minimal, calling setup() with no arguments.

That means the package metadata comes from setup.cfg rather than from code, and setup.cfg is the file to read if you want to understand how the individual packages are declared. The repository's root setup.py is the top-level one for the metapackage, and each subdirectory holds its own.

The documentation build is configured by .readthedocs.yaml and the CI runs on CircleCI, with the badge pointing at the CircleCI configuration for the repository. There is a tests/ directory at the root, alongside per-package tests.

The versioning is a single stream across the whole family. The releases are 9.3.0 from 2026-01-22, 9.4.0 from 2026-06-18 and 9.5.0 from 2026-09-15. One version number for the metapackage and its dependencies means you are not left with a mismatched set of packages, which in a family this interdependent is the difference between a working install and a debugging session.

The cadence is quarterly to a few weeks, so the numbers move fairly often, and the 9.x line has been stable enough to keep its minor version meaning.

Contributions are handled through the Ocean contributing guide, which has the guidelines for contributing to Ocean packages rather than only for the metapackage, and the support structure is layered: the Leap user community for conversation with other users, the Leap help center for searching the knowledge base, and the SDK GitHub issues tracker for issues on the SDK or on any one of its packages.

Where the Ocean SDK fits, and where it stops

The comparison worth making is with the cloud service itself and with the general Python quantum libraries.

Against using Leap directly through its own API, the SDK is the layer that makes the service usable from Python rather than from a notebook in a hosted environment. The samplers, the embedding, the preprocessing and the visualisation are all here, and they are all things you would otherwise write yourself.

Against general purpose quantum computing libraries, the difference is focus. A general framework gives you circuit construction, gate-level control and a simulator. Ocean is built around a different shape of work: you describe a mathematical problem as a BQM, hand it to a sampler, and interpret the samples that come back. That is a narrower model, and it is a model that maps to a specific class of solver, which is why it produces results you can inspect as circles and dots rather than as state vectors.

The limits are worth naming. The samplers are clients for a remote service, so an account and network access are required, and the SDK is not a local simulator. The API is centred on binary quadratic models and the annealing or hybrid workflows built on them, so it is not the tool for a circuit-level quantum algorithm. And the value of a quantum annealer on a given problem is an empirical question the SDK cannot answer for you: it will faithfully submit your model and return samples, but which problems benefit is exactly what you are using it to find out.

There is a licensing consideration for commercial work. The SDK is Apache-2.0, which is permissive, but using the Leap service itself is a separate commercial relationship with D-Wave rather than something the open source licence covers.

The API surface is also worth understanding before you commit to it. dimod, dwave-system and dwave-inspector are the three you will use in almost every program, and the example in the README is a complete program using exactly those three. Everything else is available when a particular problem calls for it, which is a reasonable way to structure a suite this broad.

On maintenance, the last push was on 2026-10-22, about a month after the 9.5.0 release on 2026-09-15, the repository is not archived, and the CircleCI workflow, the Read the Docs configuration and the contributing guide all point to a project with an active release process rather than a one-off publication.

Editorial conclusion

Ocean suits a developer who wants to experiment with annealing and hybrid quantum solvers from Python, since dimod gives you a problem model, dwave-system gives you samplers and embedding, and dwave-inspector shows you what came back rather than leaving you to trust a sampleset. It is the wrong tool if you want to run everything on your own machine, because the samplers talk to D-Wave's Leap cloud service, and it is the wrong tool if you are looking for a general quantum programming framework, since the API is centred on a particular class of problem. Before you start, read the example program in the README, because the order of the pieces, model then sampler then inspector, is the shape of every program you will write against it.

Frequently asked questions

Official sources

1. dwavesystems/dwave-ocean-sdk on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases