feat: per-model capability flag overrides (`modelCapabilities`) (#28)
* feat: add modelCapabilities per-model capability flag overrides Implements #25. Some proxies lack /v1/model/info or report flags that disagree with the deployment, leaving models misclassified in the picker (no tool_call badge, no attachments, ...). A new `modelCapabilities` provider option overlays boolean capability flags per exact model id as a third enrichment tier: /v1/models entry first, /v1/model/info gap-fill second, user override last — explicit `false` wins, and flags the proxy never reported can be forced on. Like includeModels/excludeModels, overrides are applied inside discoverModels so cold discovery and background refresh persist the same adjusted view to the model cache. The parser keeps any boolean capability key (not just the five known flags) so future LiteLLM flags work without a plugin change. * fix: scope the model cache by filter/capability config CodeRabbit review finding on #28: the cache key was only providerId@baseURL, but discovery bakes includeModels/excludeModels and modelCapabilities into the cached entries. After editing those options, the next start would merge the stale adjusted view from the cache, and the corrected entries would only surface after the background refresh plus a second restart. buildCacheKey appends a canonical (order-insensitive) fingerprint of the filter/capability config to the cache key whenever any is configured, so changed config starts a fresh discovery and the picker reflects it on the very next start. Configs without adjustments keep the plain key, so existing users' caches stay warm across the plugin upgrade.
Y
Yusef Mohamadi committed
e14a09e2f1fb4e5ed45ae1c3bf991dc425107e8f
Parent: a5dd1de
Committed by GitHub <noreply@github.com>
on 9/13/2026, 8:53:29 PM