Reported from production, minutes after v0.3.96 made an adapter a model of its
own on the pod:

    503 Model 'diogene-alpha' failed to load: Unknown backend: cpu

Only the pool's OWN entry was seeded with its engine. Siblings got none, so the
adapter arrived on the pod with no backend and fell through to the pod's
default. Verified against the live catalogue: the seed genuinely had no
`backend` key.

This had always been wrong and could not bite before, because an adapter
collapsed into its base on the pod and was never a model of its own to LOAD.
Making it one — which was the right fix — is what exposed it.

Every sibling now takes the POOL's engine, not its own. A pool is one pod
running one image, so siblings cannot each have a different engine: seeding
one would describe something the pod cannot satisfy, and the failure would
land minutes later inside a rented machine. A test asserting the opposite was
written and then corrected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM