The isolated venv was solving a problem that was not real. audiocraft is pure
Python: its torch==2.1.0 is a declared pin, not an ABI requirement, so --no-deps
sidesteps it. The only genuine constraint was xformers, which it imports at
module load — and 0.0.35 ships a py39-none wheel requiring torch>=2.10, which
this image satisfies. I had ruled that out by grepping wheel filenames for
cp312 and missing that abi3/py39 wheels cover 3.12.

Verified in the built core image: torch 2.11.0+cu128 with xformers 0.0.35,
MusicGen and AudioGen import, ops.memory_efficient_attention present.

Cost in the main venv: 950 MB. The second venv cost 6.2 GB, because it carried a
duplicate torch and a duplicate CUDA stack. The audio image drops from 15.8 GB
to about 10.2 GB, which also removes the reason to split it in two.

audio_backend (per model, or CODERAI_AUDIO_BACKEND for a pod) selects
audiocraft or transformers explicitly, because they are not equivalent — melody
conditioning and AudioGen exist only in the first. Asking for audiocraft when it
is absent raises rather than quietly substituting something less capable. A
model's own setting beats the environment it lands in, and the choice travels to
a pod instead of being decided by what happens to be installed there.

The isolated-venv worker stays in the tree: if audiocraft 1.3.0 turns out to
misbehave against torch 2.11 at generation time, restoring one profile file
brings it back.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY