Four unrelated rows from an end-to-end pass over every capability, with one
thing in common: in each case the information needed to get it right was
already in the server and something declined to read it.

**An image card with no precision loaded at f32.** The default here was f32 and
only --no-ram mode coerced it down, so whether a model occupied 2 bytes per
parameter or 4 came down to an unrelated flag. Measured on one run:
CyberRealisticPony and wai-illustrious (no_ram=True) loaded at 7.49 GB, while
PonyRealism and pornmaster-pro -- same SDXL architecture, no_ram=False --
measured 14.98 GB, exactly double, filled a 24 GB card and failed with "CUDA out
of memory. Tried to allocate 12.00 MiB". The inflation then spread to the
estimate, where the f32 precision factor turned 14.98 GB into a 30.9 GB need and
triggered a round of eviction that could not possibly help ("this model needs
more than the whole card"). Nothing was gained: these checkpoints are published
at half width. The default is now bf16 -- bf16 rather than fp16 because it keeps
f32's range, the same reason the --no-ram branch gives. An explicit f32 on a
card is still honoured.

**LTX refused the width and height.** Every family in video_geometry declares a
side_multiple -- 64 for Wan's VAE cell, 32 for H3 -- and nothing anywhere read
it; the request path never consulted the table at all. So 848x480 reached
LTX-2.5 and came back "`height` and `width` have to be divisible by 32 but are
848 and 480", with the server making the caller do arithmetic it had the numbers
for. Sides are now snapped to the nearest legal cell, and LTX has a family of
its own: it had none, so it inherited Wan's 16, under which 848 was already
"legal" -- snapping to the wrong multiple is indistinguishable from not snapping.
The new entry differs from the Wan fallback in exactly the one field a refusal
proved.

**Kokoro could not speak English.** espeak-ng names English by region and
refuses the bare code, while every OpenAI-compatible client sends "en" -- so the
Italian voices worked and the English ones raised `RuntimeError: language "en"
is not supported by the espeak backend`, as a 500, which reads as a broken
model. Regionless codes espeak rejects are mapped ("en" -> "en-us"); codes it
accepts bare ("it", "fr", "de") pass through untouched; anything it still does
not know is now a 4xx naming the language and what to send.

**A pinned model landed on the wrong engine.** by_name() matched an engine by
NAME or by BACKEND in one pass and returned the first healthy hit. A
GGUF-isolation split runs two engines on one card and both declare the backend
"nvidia", so a transformers model pinned to "nvidia" could resolve to the GGUF
sibling and be refused for a capability the engine it actually named has:
"model 'longcat-avatar' is pinned to 'nvidia' but engine 'nvidia' (backend
'nvidia') can't serve a 'transformers' model (capabilities: ['gguf'])". The
sibling fallback could not recover it either -- it appends "-gguf" to the PIN,
so it tried the same engine twice and never the one named "nvidia". An exact
name is unambiguous, so it now wins, in its own pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC