Add a generic OpenAI-compatible "custom" provider (for OpenRouter, OpenCode Zen, etc.)

[HarvardChin]

Right now the "Add Model" flow only supports 5 hardcoded providers: anthropic, openai, google, cloudflare, ollama. Each is wired to a specific wire format in ai-models.ts (Anthropic Messages, OpenAI Responses, Google Generative AI, Workers AI REST, and OpenAI Completions for Ollama).

The apiUrl override on anthropic/openai/google only changes the host, not the request shape — so it can't be pointed at an OpenAI-compatible aggregator like OpenRouter or OpenCode Zen, since those speak Chat Completions rather than, say, OpenAI's Responses API.

The only working path today is picking "Other Ollama..." and pointing its apiUrl/apiToken at the aggregator, since the ollama case in getModelDirect already just speaks plain openai-completions against an arbitrary URL. That works, but it's mislabeled and easy to miss.

Proposal: add a custom provider (or similar) that's explicitly "any OpenAI Chat-Completions-compatible endpoint" — same underlying implementation as the current ollama case, minus the Ollama-specific URL normalization, with its own label/placeholder in AddModelModal.tsx instead of piggybacking on Ollama's UI copy.

Happy to put together a PR for this if it's a direction you'd want — wanted to check here first given the contribution guidelines. Prior art: OpenRouter and OpenCode Zen both expose OpenAI-compatible /chat/completions endpoints that would slot into this cleanly.

[Tmeister]

Yes please

[haonan-c]

+1 — a generic OpenAI-completions custom provider is the right abstraction. One design point I'd push on, from wiring up DeepSeek's official API:

Context window can't be assumed — it must be user-settable per model. A custom provider by definition points at arbitrary models (especially through aggregators like OpenRouter, which expose hundreds), and their context windows range from a few K to 1M+ and shift with each model revision. There's no safe single default. This number isn't cosmetic: it feeds the compaction budget, so if a custom model falls back to a hardcoded default (e.g. 128k) it will compact far too early or, worse, overflow a smaller-window model. Please let users set context window (and ideally an output reservation) per custom model, and surface it in AddModelModal.tsx.

Concrete example: DeepSeek V4 Flash has a 1M window — hardcoding 128k throws away ~87% of it for long agent sessions.

Two smaller gotchas worth designing around, since DeepSeek is a common target:

pi 0.83 defaults OpenAI-compatible providers to max_completion_tokens, but DeepSeek's Chat API only honors max_tokens — the provider needs a way to force compat.maxTokensField: "max_tokens".
Reasoning defaults affect context/cost: DeepSeek emits an explicit thinking:{type:"disabled"} when no effort is passed.
I have a working DeepSeek-specific implementation on a fork (models catalog + direct routing + tests) if useful as a reference. Happy to help.