cuOpt: an NVIDIA GPU solver for linear, quadratic and vehicle routing problems

What cuOpt solves, and which parts are beta

cuOpt is described as a GPU-accelerated optimization engine that excels in linear programming, quadratic programming and vehicle routing problems, with support for quadratically constrained quadratic programming, second-order cone programming and mixed integer programming, all three marked beta. The claims are specific about scale and latency, that cuOpt enables near real-time solutions for large-scale LPs with millions of variables and constraints, and that it offers easy integration into existing modeling languages with seamless deployment across hybrid and multi-cloud environments. The beta marking applies to QCQP, SOCP and MIP in the C and Python API lists, while the server list marks only MIP as beta. The MIP note is more specific still, that the solver currently excels at finding high-quality feasible solutions quickly with GPU-accelerated primal heuristics, while proving feasible solutions optimal remains under active development. That is a solver without a proof, and it should be treated as one.

Four surfaces over one C++ engine, and an API you are told not to trust yet

The core engine is written in C++ and wrapped with a C API, a Python API and a Server API. The C API supports LP, QP, and the three beta problem classes. The Python support adds routing, covering TSP, VRP and PDP, and an algebraic modeling Python API that lets users build constraints and objectives. The Server support covers LP, routing and MIP, the last in beta. The C++ API is the odd one out, and the documentation is unusually blunt about it, since the project says it does not provide documentation for the C++ API at this time, anticipates that the C++ API will change significantly in the future, and says to use it at your own risk. The server mode is the one that survives a version upgrade, since it is an interface rather than a header, and for a long-running service that is the surface to build against.

The hardware floor: Volta or better, a specific driver, and Linux only

The system requirements are the first real constraint. You need CUDA 12.0 or newer, or CUDA 13.0 or newer, an NVIDIA driver of at least 525.60.13 on Linux and 527.41 on Windows, and a GPU of Volta architecture or better, which is compute capability 7.0 or above. Python has to be at least 3.11 and at most 3.14. The OS requirement is the sharpest, only Linux is supported and Windows via WSL2, on x86_64 or aarch64, and there is a note that WSL2 is tested to run cuOpt but not for building. So a Windows developer can run it, but a Windows developer cannot compile it without moving to a Linux environment. The Volta floor is old enough that the hardware requirement is unlikely to be the blocker for most teams, but the driver and CUDA version pairing is.

Installing with pip, and the CUDA major version decides the package names

Pip wheels are described as easy to install and easy to configure, for users whose workflows already use pip as a base, and cuOpt is installed from the NVIDIA Python Package Index rather than from PyPI. The instruction is to select the appropriate package depending on the major version of CUDA available in the environment, because the package names carry the CUDA major suffix. For CUDA 12.x you install the cu12 runtime package alongside the server and the shell client, and for CUDA 13.x you install the cu13 variants. Nightly builds are available with the pre flag and an extra index URL pointing at the RAPIDS nightly wheels. The pattern is consistent across pip, conda and containers, and it means the choice of channel is part of the installation decision rather than something the tool decides for you.

pip install \
  --extra-index-url=https://pypi.nvidia.com \
  nvidia-cuda-runtime-cu12==12.9.* \
  cuopt-server-cu12==26.12.* cuopt-sh-client==26.12.*

Conda and containers, including a FIPS validated image

The conda route goes through miniforge and installs from the rapidsai, conda-forge and nvidia channels, and the documentation notes that all other dependencies are installed automatically when cuopt-server and cuopt-sh-client are installed. Nightly conda packages are built from the HEAD of the development branch and you swap rapidsai for rapidsai-nightly. The container route ships two variants on Docker Hub, an Ubuntu-based image for general use and a Red Hat Universal Base Image 10 image for FIPS 140-3 compliant environments. The UBI10 image is based on RHEL 10, which ships OpenSSL 3.5 validated under FIPS 140-3, and it exists for environments with strict compliance requirements. The tags are per CUDA major, latest-cu12 and latest-cu13, where latest is the latest stable release, and a specific version is pinned with a suffix such as 26.6.0-cu13.

# For CUDA 12.x
docker pull nvidia/cuopt:latest-cu12

# For CUDA 13.x
docker pull nvidia/cuopt:latest-cu13

conda install -c rapidsai -c conda-forge -c nvidia cuopt-server=26.12.* cuopt-sh-client=26.12.*

The repository is a full product surface, not a solver source tree

The top level of the repository shows how much sits around the engine. There is a cpp/ directory for the C++ source and a python/ directory for the bindings, a benchmarks/ directory, a datasets/ directory, a regression/ directory for tests, a notebooks/ directory, a java/ directory, a helmchart/ directory for Kubernetes deployment, a cmake/ directory, a conda/ directory, a ci/ directory, and a skills/ directory alongside an agents/ directory. The presence of skills/ and agents/ matches the README claim that cuOpt extends into agent-first optimization workflows through open-source cuOpt agent skills, and the .claude-plugin/, .cursor-plugin/, .gemini-extension.json and .windsurf/ directories at the root suggest the same content is exposed to several assistants. There is also a VERSION file, a RAPIDS_BRANCH file, a CHANGELOG.md, a RELEASE-NOTES.md, a CONVENTIONS.md and a SECURITY.md, and the repository is also hosted as a COIN-OR project, which is how a solver becomes part of the academic optimisation ecosystem.

Upkeep, release cadence and where the documentation lives

The release history is on a calendar versioning scheme, with v26.06.00 on 2026-06-09, v26.08.00 on 2026-08-06 and v26.10.00 on 2026-10-14, so a release every two months with the year and month in the version. The version badge in the README reads 26.12.00 and the README says to ensure you are on the main branch for the latest version, and the install commands pin to 26.12.* packages, so the distribution channels are already ahead of the last tagged release. The licence is Apache-2.0, the primary language is Cuda, the last push to the repository was on 2026-10-15, and the repository is not archived. The documentation is a separate site at docs.nvidia.com/cuopt with a system requirements page, and the examples live in a separate NVIDIA/cuopt-examples repository with a Colab launcher and a launchable on NVIDIA infrastructure, which is a sensible way to let people try a solver that needs a specific GPU without setting one up.

Editorial conclusion

cuOpt suits a team solving large linear or quadratic programs, or vehicle routing problems, who want a solver that runs on a GPU they already have and can accept that the MIP branch is a beta with fast feasible solutions rather than proven optima. It is the wrong choice for a mixed integer problem where you need a certificate of optimality today, because the README says proving feasible solutions optimal remains under active development, and a poor fit if you have no NVIDIA hardware, since the requirement is a Volta architecture or better, that is compute capability 7.0 or above, and only Linux is supported natively with Windows via WSL2. Before adopting it, read the RELEASE-NOTES.md and pick your distribution channel deliberately, because the pip, conda and container paths each install a different pair of packages and the CUDA major version you pick determines which one you get.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NVIDIA/cuopt on GitHub
3. Project website
4. README
5. Releases