XTTS-v2 and Parler were advertised in /v1/models and failed on every request.
Three separate causes, none of them the one the report assumed.

A venv built by a DIFFERENT interpreter bricks the engine permanently. A
worker venv keeps bin/python as a symlink to the python that created it, so
one built on the host and used from the container (or built before the image
moved its interpreter) leaves a dangling link. The failure is not a clean
"missing": Path.exists() follows symlinks and says False, so the code decides
the venv is absent and runs `python -m venv` over the top, which trips on that
same dangling bin/python3:

    Error: [Errno 2] No such file or directory: '.../parler_venv/bin/python3'

reported for weeks as "the venv can't be created", with a fully populated venv
and 7 GB of packages sitting right there. Both workers now check that the
interpreter RUNS, not that the path exists, and clear a foreign venv before
recreating.

TRANSFORMERS_CACHE pointed at a second cache. It is deprecated but transformers
4.x still honours it, and honours it as the cache_dir handed to
hf_hub_download -- a hub-layout cache, not a different kind of store. Setting
it to <dir>/transformers therefore gave the machine TWO hub caches: measured,
<dir>/hub held 122 models and <dir>/transformers held 2. A worker in an
isolated venv read only the second, found nothing, and -- forced offline so a
missing model fails fast -- reported "We couldn't connect to
https://huggingface.co" for a model that was present the whole time. It is
also why workers re-downloaded models the server already had. All four
variables now name the hub directory.

XTTS never built its venv at all. parler bootstraps on first use; XTTS only
looked for a venv and raised a 501 telling the operator to go and make one.
Same situation, two behaviours. It bootstraps now, with
CODERAI_XTTS_AUTOINSTALL=0 for a host that manages its own venvs.

Also the voice listing the report asks for, but NOT at /v1/audio/speakers:
that path is already enrolled speaker voiceprints for recognition, and serving
TTS voices there would conflate two unrelated things. The voices join the other
"what can this model do" answers at /v1/audio/speech/capabilities, which
already takes the same model= parameter.

It never loads a model to answer -- an already-loaded backend is asked
directly, otherwise the list is whatever was remembered the last time that
model loaded, and voices_source says which. And it does not invent metadata:
Kokoro ids genuinely encode accent and gender (af_sarah -> en-us, female) so
those are derived, while an XTTS speaker name carries neither and reports
None. A wrong gender against a voice is worse than no gender.

voice_selection is reported too, because parler has no speaker names at all --
it is steered by a free-text description, and a client reading only an empty
voices list would conclude it cannot be directed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC