[llm-pi-ai] renamed custom provider routes silently lose installed-catalog metadata (contextWindow/maxTokens) — catalog matched by provider name only

[edisonzerolam]

Title: [llm-pi-ai] renamed custom provider routes silently lose installed-catalog metadata (contextWindow/maxTokens) — catalog matched by provider name only

Labels: bug, enhancement

Summary

resolveRouteModels() resolves installed-catalog defaults via catalogModels(provider) — strictly by route name. A user route aimed at a cataloged gateway under a different name (e.g. "opg" with baseURL: https://opencode.ai/zen/go/v1/, byte-identical to the bundled opencode-go catalog provider) resolves defaults = ∅. Every configured model then falls back to defaultContextWindow (262144) and defaultMaxTokens, even though the correct metadata ships inside the same installation.

Production consequence

A free-tier model on that gateway accepted ≥580k-input requests while the harness believed its window was 262,144 — producing premature client-side CONTEXT_WINDOW_EXCEEDED mappings and mis-scaled compaction thresholds. We had to hand-declare contextWindow/maxTokens for ~30 models in settings.yaml from pi-ai's own bundled catalogs — data the adapter already had on disk.

Suggested direction

When the route name has no catalog entry, fall back to matching catalog providers by baseUrl (+ api), so renamed routes keep full catalog fidelity; optionally log a warning when neither name nor baseURL matches a catalog and a model lacks an explicit contextWindow.

Happy to work up a patch if the direction sounds right.

---

Environment

DSH desktop install; @deepseek-ai/* 0.1.1-rc.2 (patches applied to the compiled lib/index.js); Windows. Both patches verified red/green with independent harnesses that mirror the seam/compaction semantics against the real packaged rg binary.