SIGN IN SIGN UP

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