CUDA Python 1.0 stabilizes APIs with semantic versioning across components

NVIDIA released CUDA Python 1.0 with CUDA 13.3 on August 25, 2026, marking Python as a supported, first-class way to use the CUDA platform. The milestone bundles several independently versioned components: cuda.core 1.0.0, cuda.compute 1.0.0, cuda.bindings 13.3.0, cuda-pathfinder, and nvmath-python 1.0. The components keep separate release tracks, so the version numbers differ deliberately. The headline change is a semantic versioning commitment: breaking API changes only in major releases, features in minor releases, bug fixes in patches, and deprecation with a clear replacement path before any public API is removed.

One foundation instead of many

Before this release, reaching CUDA from Python meant choosing among several binding layers, each maintained by a different project with its own idea of what a stream, device, or allocation was. Libraries inherited whichever layer their dependencies used, and interop between libraries on the same GPU memory required interchange protocols and careful ownership tracking. CUDA Python 1.0 replaces that with one NVIDIA-maintained path to CUDA, and NVIDIA states that CUDA Python and C++ now stand as equal first-class citizens with feature-complete parity going forward.

The practical result is that libraries compose rather than merely coexist. A Numba kernel and a cuda.compute call can operate on the same GPU buffer in the same stream because neither brings a private CUDA layer along. Advanced platform features like green contexts, which partition a GPU's streaming multiprocessors to shield latency-sensitive kernels from throughput kernels, now land in cuda.core once and become reachable by everything built on it.

Three tiers on one foundation

The CUDA Python ecosystem stacks in three tiers. At the bottom sits the runtime system: device management, memory allocation, streams and synchronization, CUDA graphs, and JIT compilation. cuda-pathfinder locates the CUDA components installed in an environment, addressing the recurring problem of debugging which CUDA runtime a process actually loaded. Above that sit the CUDA libraries: cuda.compute brings CCCL's host-callable parallel algorithms, nvmath-python brings the math libraries, and NCCL4Py and NVSHMEM4P bring the communication libraries. None reimplements the CUDA layer underneath; they work in the same cuda.core buffers, devices, and streams. At the top sits kernel authoring: numba-cuda for SIMT kernels, plus two newer domain-specific languages, cutile-python for the block model and cuteDSL for Tensor Cores. Some newer kernel-authoring components remain experimental and are not yet covered by the 1.0 semantic-versioning guarantees.

Three ways in

For users who want optimized algorithms without writing kernels, cuda.compute exposes CCCL parallel algorithms such as sort, scan, reduce, transform, unique, histogram, and top-k as host-callable functions that compile for the active GPU. Version 1.0 adds the ability to customize algorithms with ordinary Python functions, including lambdas. For custom kernels, Numba compiles a subset of Python into GPU kernels using the SIMT model, and the newer Numba CUDA MLIR backend replaces the compiler underneath with MLIR and the modern NVVM toolchain, delivering faster warm JIT compiles and lower kernel-launch latency, typically with a one-line import change. For direct driver and runtime API access, cuda.core provides a Pythonic interface covering devices, streams, programs, linkers, memory resources, and graphs, with runtime compilation of CUDA C++ and exception-based error handling instead of error codes. cuda.bindings offers exhaustive 1:1 coverage of the CUDA C APIs for library authors. Major ecosystem libraries including CuPy, PyTorch, and NVIDIA's communications and math libraries now build on the shared cuda.core foundation.