Custom provider models are missing from the Web UI model picker

[websideofamir]

Models from custom providers are returned correctly by /api/runtime-config, but they do not appear in the chat model picker. The picker falls back to the default built-in models.

Reproduction

1. Configure a custom provider.
2. Add its models to the Web UI model allowlist.
3. Confirm the models appear in modelsByHarness and modelCatalog from /api/runtime-config.
4. Open the chat model picker.

Cause

plugins/web-ui/src/pi-models.ts#getBaseModel only creates dynamic models when the provider is openrouter. Models from other providers throw Unsupported model and are silently dropped by buildOption.

Expected

Models from any supported custom provider should appear in the picker.

The provider protocol could be included in modelCatalog so the frontend can construct the appropriate model instead of special-casing OpenRouter.

[westlavie-creator]

Confirmed and verified on a local deployment with DeepSeek as an OpenAI-compatible custom provider. Two working fixes, depending on how general you want to be:

1. If the provider exists in pi-ai's builtin catalog (deepseek does, with api: openai-completions and the correct baseUrl): just add it to KNOWN_PROVIDERS in plugins/web-ui/src/pi-models.ts:

const KNOWN_PROVIDERS = ["anthropic", "openai", "openrouter", "deepseek"] as const;

2. Generic fallback for any custom provider not in pi-ai's catalog: clone a completions-protocol template instead of throwing:

if (fallback) {
  const template = (getModel("deepseek", "deepseek-v4-flash" as Parameters<typeof getModel>[1]) ??
    getModel("openai", "gpt-4o" as Parameters<typeof getModel>[1])) as PiModel | undefined;
  if (template) return cloneModel(template, id, fallback.name);
}

With this the custom models appear in the picker, and turns work end-to-end: the UI sends modelId/harnessId, and core resolves the wire details (baseUrl/protocol) from the admin-registered provider — the UI only needs the Model for display/feature flags.

Agree that including the provider protocol (and baseUrl) in modelCatalog is the cleaner long-term fix, so the frontend can construct the right api/baseUrl for any provider instead of special-casing.

[websideofamir]

in my use case i used cliproxy, which might not be as a known provider (or any other ai proxy platforms). so the fixed providers might not fix my problem