CUDA Python 1.0: the deliverable is a versioning promise, not new code

A semantic-versioning promise is cheap to announce and expensive to keep, which is why it is the part worth reading closely. NVIDIA's commitment is the ordinary four-line one: breaking changes only in major releases, features in minors, fixes in patches, and any public API bound for removal deprecated first in a minor release with a stated replacement path ^[4]. By NVIDIA's own description this is not a rewrite and not a new product, since most of the components have been shipping and improving for a while ^[14]. The deliverable is the contract.

That contract has an edge worth noting. There is nothing called CUDA Python 1.0 to install, because the components are versioned separately and the mismatched numbers are deliberate ^[3]. Count the labels: cuda.core, cuda.compute and nvmath-python arrive at 1.0, cuda.bindings arrives at 13.3.0 because it tracks the toolkit, and cuda-pathfinder is announced without a number at all ^[2][6]. A team pinning its GPU stack is pinning five things that each keep their word on their own release track. Better than before, and not the same as one version to trust.

Underneath, the claim that matters is about identity. Each earlier binding layer was maintained by a different project, covered a different slice of the API, and had its own idea of what a stream or a device or an allocation was ^[7]. Handing a CuPy allocation to cuDF on the same stream without a copy was therefore a question answered through interchange protocols and careful accounting of who owned the memory ^[8]. cuda.core turns devices, streams and buffers into ordinary Python objects that every GPU library can build on ^[13], and the stated consequence is that a Numba kernel and a cuda.compute call work on the same buffer in the same stream because neither one brought a private CUDA layer along ^[9].

Green contexts are the concrete test of that design. The feature partitions a GPU's streaming multiprocessors so latency-sensitive kernels are shielded from throughput kernels ^[10]; under the old arrangement, every library that wanted it had to bind and expose it independently, and now it lands in cuda.core once and everything above it can reach it ^[11].

All of this is NVIDIA's account of NVIDIA's work, and the parity claim is the softest part of it. Python and C++ are described as equal first-class citizens as of CUDA 13.3, with feature-complete parity given as a forward commitment ^[12], not as a thing with a deadline or a definition of what counts as a breach. The payoff, read honestly, is about labour: NVIDIA's pitch to library authors is that their effort goes into what makes their library distinctive rather than into a low-level layer someone else has already written ^[15]. The alternative it replaces was learning enough CUDA C++ to write an extension, stand up a build toolchain and maintain bindings, which the announcement concedes most people never did ^[5]. None of this makes a kernel faster. It changes who writes the boring part.