#14003 fix(backend): Vision Bridge silently reroutes image requests to a different provider's model when the requested model has no MODEL_SPECS entry (Kimi kimi-for-coding)

Version: 3.8.50 (self-hosted, Windows, Node 24)

Symptom

When a client sends a request with an image for a model whose id has no entry in MODEL_SPECS, the Vision Bridge guardrail silently reroutes the whole request to a different provider's model — no error, and the substitute model answers as if nothing happened.

Our case: kimi-for-coding (Kimi Coding provider; Moonshot has upgraded this stable wire id to Kimi K2.8 Preview, which accepts images natively). Every image request for it was answered by command-code/moonshotai/Kimi-K2.6 — a different provider connection entirely. Text-only requests to the same model pass through unchanged, so from the client it just looks like "adding an image changes the model".

Evidence (app.log)

Before fix: Guardrail model reroute entry naming kimi-for-coding; the request was then routed to command-code/moonshotai/Kimi-K2.6.
After registering a spec entry (workaround below): kimi-for-coding → kimi-coding/kimi-for-coding, no reroute, image delivered, correct model answers.

Root cause (from reading the 3.8.50 source)

getResolvedModelCapabilities("kimi-for-coding") finds no MODEL_SPECS entry — the existing K2.7 spec only aliases kimi-k2.7* ids, and the Kimi Coding registry deliberately does not set supportsVision;
VisionBridgeGuardrail.preCall() short-circuits to pass-through only when supportsVision === true;
unknown capability → credential/availability path → whole-request auto-reroute to some other vision-capable model.

Why this bites generally: providers rename/upgrade wire models faster than the static spec table tracks. Any registry/autoSync-sourced model that starts accepting images without a spec entry gets silently substituted on image requests: wrong model answers, wrong billing, nothing surfaced to the client, and call_logs records the substitute as if it were intended.

Suggestions

I understand the whole-request reroute itself is intentional (#7303 closed as not planned), so this is not a request to remove Vision Bridge. The gap:

For direct requests to an explicit, user-specified model id (not combos), treat unknown capability as pass-through instead of reroute — consistent with chatCore's "unknown ≠ strip image_url" philosophy. Silently swapping a model the user named explicitly is surprising.
Or consult the provider registry / catalog capabilities before deciding to reroute.
At minimum: log the reroute at warn with the original model id, and make the guardrail opt-out per connection.
Data fix regardless: kimi-for-coding is now Kimi K2.8 Preview — please add spec kimi-k2.8-preview (aliases kimi-for-coding, supportsVision/Tools/Thinking, context 1048576) and update the Kimi Coding registry entry (name "Kimi K2.7 Code" → "K2.8 Preview", contextLength 262144 → 1048576). We verified in production that registering the spec alone makes preCall pass through before credential checks, so this data fix alone already repairs routing.

Related: #7303, #10808, #11767, #13918