How to reason about "Environment <environment> was resolved for a richer platform than <platform> provides" warnings?

[matthewfeickert]

As noted in matthewfeickert-talks/reproducible-cuda-workflows-with-pixi-scipy-2026#5 (comment), with Pixi v0.71.0+ we can specify both a CUDA version and CUDA compute capability (cuda-arch). So if we want to support CUDA compute capability v8.0+ then we can enforce that we have at least the required CUDA compute capability through using both cuda and cuda-arch when creating the workspace

[workspace]
channels = ["conda-forge"]
name = "example"
platforms = [ { name = "linux-64-cuda", platform = "linux-64", cuda = { driver = "13", arch = "8.0" } } ]
version = "0.1.0"

[tasks.download]
cmd = "curl -sLO https://raw.githubusercontent.com/NVIDIA/cutile-python/refs/heads/main/samples/quickstart/VectorAdd_quickstart.py"

[tasks.quickstart]
cmd = "python ./VectorAdd_quickstart.py"

[tasks.start]
depends-on = ["download", "quickstart"]

[dependencies]
numpy = ">=2.5.1,<3"
cupy = ">=14.1.1,<15"
cutile-python = ">=1.4.0,<2"
curl = ">=8.21.0,<9"

However, on a linux-64 machine with CUDA compute capability of 8.9 (i.e. Ada architecture)

$ nvidia-smi --query-gpu=name,compute_cap --format=csv,noheader,nounits
NVIDIA GeForce RTX 4060 Laptop GPU, 8.9
$ nvidia-smi -q | grep -i architecture
    Product Architecture                               : Ada Lovelace
$ nvidia-smi --version
NVIDIA-SMI version  : 595.71.05
NVML version        : 595.71
DRIVER version      : 595.71.05
CUDA Version        : 13.2

we get a warning that the resolved environment is not compatible with the local platform:

$ pixi run start
✨ Pixi task (download): curl -sLO https://raw.githubusercontent.com/NVIDIA/cutile-python/refs/heads/main/samples/quickstart/VectorAdd_quickstart.py
 WARN Environment 'default' was resolved for a richer platform than 'linux-64' provides; this machine only meets the installed packages' minimum requirements, so it runs here by accident.

✨ Pixi task (quickstart): python ./VectorAdd_quickstart.py
✓ vector_add_example passed!

but this only happens the first time the workspace is created, as

$ rm -f ./pixi.lock && pixi clean && pixi run start
  Removed /tmp/example/.pixi/envs (2.4 GiB)                                                                                                                                             Removed 2.4 GiB
✨ Pixi task (download): curl -sLO https://raw.githubusercontent.com/NVIDIA/cutile-python/refs/heads/main/samples/quickstart/VectorAdd_quickstart.py

✨ Pixi task (quickstart): python ./VectorAdd_quickstart.py
✓ vector_add_example passed!

Why is this warning happening and how can I debug this?

[matthewfeickert]

I asked Claude Code Fable 5 and its summary is:

---

That warning isn't about your hardware — it's about what pixi can prove about your hardware. Your GPU comfortably meets the declared platform (compute capability 8.9 ≥ 8.0, CUDA driver 13.2 ≥ 13). The problem is that the official pixi binary is a statically linked musl build, which physically cannot detect your GPU's compute capability, so the __cuda_arch half of your rich platform declaration goes unverified.

The mechanics

Your pixi.toml declares the rich platform { name = "linux-64-cuda", platform = "linux-64", cuda = { driver = "13", arch = "8.0" } }, which makes the solver resolve against the virtual packages __cuda=13 and __cuda_arch=8.0 (you can see both recorded under platform p1 in pixi.lock).

At pixi run time, pixi classifies your machine against two platforms recorded at install time (verify_run_platform in pixi_core/src/workspace/virtual_packages.rs):

1. Resolved platform — what the solve targeted: linux-64 + __cuda=13, __cuda_arch=8.0, glibc 2.28, … Machine matches → runs as intended, silence.
2. Minimum platform — the union of virtual packages the locked packages actually require at runtime. Machine matches only this → runs, but warn "by accident".
3. Neither → hard error.

Your pixi info shows exactly where you land:

Virtual packages: ... __cuda=13.2 ...        ← no __cuda_arch!
Resolved platform: linux-64 (cuda = { driver = "13", arch = "8.0" }, ...)
Minimum platform:  linux-64 (glibc, __unix)

Your machine's detected virtual packages include __cuda=13.2 but no __cuda_arch at all, so the resolved-platform check fails on the __cuda_arch=8.0 requirement. Pixi then falls back to the minimum platform — and since none of the locked conda-forge packages carry an actual __cuda_arch run-dependency (only glibc/unix constraints), that passes. Verdict: "runs here by accident."

Why __cuda_arch isn't detected

Rattler detects __cuda and __cuda_arch by dlopen-ing libcuda.so and calling cuInit/cuDeviceGetAttribute. But your pixi is statically linked (file ~/.pixi/bin/pixi → "statically linked" — the official Linux releases are musl builds), and musl-static binaries can't do dynamic library loading. Rattler's musl fallback shells out to nvidia-smi, which yields the driver version (__cuda=13.2) but not the compute capability — rattler's CudaArch::current() docs state it returns None when "the system is using musl libc (dynamic library loading not supported)". So pixi is blind to your 8.9 GPU arch by construction.

Why only the first run

The warning is deliberately one-time: after emitting it, pixi writes a marker file — .pixi/one-time-messages/runs-by-accident-default exists in your workspace — and stays quiet on subsequent runs.

What to do

It's benign here (sm_80 code runs on any 8.x device anyway), but if you want Pixi to verify the platform properly, override the undetectable virtual package:

export CONDA_OVERRIDE_CUDA_ARCH=8.9

I verified this on your machine — with the override set, pixi info reports __cuda_arch=8.9, which satisfies the resolved platform's __cuda_arch=8.0 (the check is >=), so fresh installs classify as fully compatible and never warn. Alternatively, if you don't need the arch pin for solving, dropping arch = "8.0" from the platform entry (keeping cuda = { driver = "13" }) also eliminates the gap.

Given the musl-detection limitation makes every __cuda_arch-declaring workspace warn spuriously on official pixi binaries, this seems worth an upstream issue on prefix-dev/pixi if one doesn't exist yet.

Sources: pixi multi-platform docs, pixi virtual_packages.rs, rattler cuda.rs, rattler lib.rs

[ruben-arts]

I believe the warning is also useless for the time being in this case. As no package in your environment depends on the __cuda_arch virtual package.

@baszalmstra @hunger We always build for musl for the Pixi github release, so the cuda_arch will always be None: https://github.com/conda/rattler/blob/13951af152f9890d4776d877ecd1197ec28c4e02/crates/rattler_virtual_packages/src/cuda.rs#L133-L146

[Hofer-Julian]

@hunger

[matthewfeickert]

I see now that in

$ pixi --version
pixi 0.72.2

the error message has changed (I think(?) due to PR #6491).

Now if I start with a workspace with no dependencies on the same machine as before

[workspace]
channels = ["conda-forge"]
name = "example"
platforms = [ { name = "linux-64-cuda", platform = "linux-64", cuda = { driver = "13", arch = "8.0" } } ]
version = "0.1.0"

[tasks.download]
cmd = "curl -sLO https://raw.githubusercontent.com/NVIDIA/cutile-python/refs/heads/main/samples/quickstart/VectorAdd_quickstart.py"

[tasks.quickstart]
cmd = "python ./VectorAdd_quickstart.py"

[tasks.start]
depends-on = ["download", "quickstart"]

[dependencies]

and then add the dependencies

$ pixi add --no-install numpy cupy cutile-python curl
✔ Added numpy >=2.5.1,<3
✔ Added cupy >=14.1.1,<15
✔ Added cutile-python >=1.4.0,<2
✔ Added curl >=8.21.0,<9
$ pixi install
✔ The default environment has been installed.

I've resolved them on a machine that can meet the requirements. But the execution raises the warning

$ pixi run start
✨ Pixi task (download): curl -sLO https://raw.githubusercontent.com/NVIDIA/cutile-python/refs/heads/main/samples/quickstart/VectorAdd_quickstart.py
 WARN Environment 'default' requires cuda_arch >=8.0, but this machine does not provide '__cuda_arch'. The currently installed packages don't actually need it, so the environment still runs, but the next re-resolve (e.g. 'pixi update' or a change to the manifest) may install packages that do, which would no longer run on this machine.

✨ Pixi task (quickstart): python ./VectorAdd_quickstart.py
✓ vector_add_example passed!

The new error message is correct that __cuda_arch isn't found

$ pixi info
System
------------
       Pixi version: 0.72.2
        TLS backend: rustls
           Platform: linux-64
   Virtual packages: __unix=0=0
                   : __linux=6.8.0=0
                   : __glibc=2.39=0
                   : __cuda=13.2=0
                   : __archspec=1=skylake
          Cache dir: /home/feickert/.cache/rattler/cache
       Auth storage: /home/feickert/.rattler/credentials.json
   Config locations: No config files found

but does that mean that Pixi v0.72.2 doesn't know how to get __cuda_arch information from a machine's NVIDIA drivers yet?

[Hofer-Julian]

Yes. My understanding is that @baszalmstra's PR will fix that: conda/rattler#2568

[matthewfeickert]

Fantastic. Thank you very much @Hofer-Julian (and everyone else)!