Native dynamic model-catalog support for CLIProxyAPI (models and reasoning levels)

[CDeZT]

Summary

Could llm-pi-ai support an opt-in dynamic model catalog for custom providers, starting with CLIProxyAPI's rich catalog response?

The desired user experience is:

1. Enter a custom Provider baseURL, protocol, and credential in DSH.
2. DSH fetches the provider's model catalog, including reasoning levels and modalities.
3. DSH's existing native model/reasoning selector shows those capabilities.
4. Inference continues directly through the configured Provider; no browser extension, frontend injection, or inference proxy is needed.

Current behavior

DSH's llm-pi-ai adapter is backed by @earendil-works/pi-ai (^0.84.2 in the current source), and built-in provider metadata is imported from pi-ai. However:

• reuseCatalogProvider() explicitly drops catalog-owned dynamic refresh, because DSH treats the settings document as the route catalog.
• listModels() reads the current Models snapshot and does not invoke a provider refresh.
• Custom-provider discovery only accepts the standard OpenAI data[] shape and maps id/name/context/output capacity. It does not consume rich capability fields such as reasoning levels or input modalities, and it is a setup action rather than an automatically refreshed catalog.

As a result, entering only a CLIProxyAPI Base URL is not currently sufficient to keep the native DSH picker synchronized.

CLIProxyAPI catalog

CLIProxyAPI's normal /v1/models response is OpenAI-compatible and intentionally limited. When client_version=pi is present, the endpoint returns a richer models[] catalog with fields such as:

• slug / display_name
• context_window
• input_modalities
• supported_reasoning_levels[].effort
• default_reasoning_level

The behavior is implemented in CLIProxyAPI's OpenAI models handler.

The same organization maintains a pi CLIProxyAPI provider. It fetches {root}/v1/models?client_version=pi, maps the catalog to pi model metadata, caches it, and refreshes it in the background. Its endpoint normalization and mapping are visible in extensions/lib.ts.

Suggested direction

I would be happy with either of these native designs:

1. Add an opt-in rich catalog configuration to DSH custom Provider discovery, then refresh and persist/overlay the resulting models[] safely; or
2. Preserve pi-ai provider dynamic catalogs in a way that does not conflict with DSH's settings-owned overrides, and add CLIProxyAPI at the pi-ai provider layer.

For the CLIProxyAPI shape, a mapping could be:

• slug → models[].id
• display_name → models[].name
• context_window → models[].contextWindow
• input_modalities → models[].input
• supported_reasoning_levels → models[].reasoningEfforts
• remote none → DSH off with wire value none

Safety/behavior expectations:

• opt in by route or by catalog type, rather than treating every OpenAI endpoint as CLIProxyAPI;
• resolve credentials on the host only;
• preserve the last working model list when refresh fails or returns an empty catalog;
• do not infer capabilities from model names;
• keep DSH's native selector and direct inference path authoritative;
• define how a per-model default_reasoning_level should map, since the current profile-level reasoning field is route-wide.

Why this belongs upstream eventually

A host plugin can work around the gap by fetching the rich catalog and writing mapped models[] back into llm-pi-ai settings. That keeps inference and UI native, but duplicates catalog lifecycle logic outside DSH. Native support would make “Base URL + credential → synchronized native picker” work without a bridge plugin and would also provide a reusable path for other gateways that expose structured model capabilities.

Would the maintainers prefer this capability to live in DSH's llm-pi-ai discovery/settings layer, or first in pi-ai with DSH preserving its dynamic provider behavior?