None of this session's work had any UI, so all of it was JSON-only. Now:

MODEL PAGE — a Placement section: serve this model from a remote URL
(with its name and token on that remote), and burst-to-RunPod with the
three triggers (no free slot / queue full / no local GPU) and a target
that is either a managed pod or your own serverless endpoint. The pod
form gained engine (auto/vLLM/llama.cpp/coderai/custom), the GGUF to
download, image, health path, docker args, the private-registry
credential, the pod's bearer token with an explicit "leave it open"
opt-out, and the scaling knobs (scale-up threshold, max in-flight per
pod, sticky sessions).

SETTINGS PAGE — a remote service URL for each of the five engines
(ds4, colibri, k3, ktransformers, vLLM), the account-wide registry
credential, and a Remote capabilities card: one row per capability,
each Local / Remote URL / RunPod pod, with image, shared pool name,
VRAM, $/hr, max pods and idle timeout.

Clearing a remote field now REMOVES it. The save path only writes keys
that are present, so sending an empty value as "unchanged" would have
left a stale remote in place and the model would have kept going to a
machine the user thought they had detached.

Tests assert what is easy to get silently wrong in UI work: every
getElementById reads an id that exists (counting ids the page assigns to
elements it creates), every new field is both populated and collected,
every capability the gateway can route has a row, and the admin API
keeps every key the form sends.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY