Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

(Note: #12832 covers the specific Composer case; this proposes a broader, provider-scoped mechanism.)

Describe the solution you'd like?

Add support for custom model names on providers the user is already authenticated with, separate from Warp's official server-provided model catalog.

Example UX (Settings → Custom inference):

When a provider is connected (BYOK API key or SuperGrok OAuth), show an option to add a custom model:

Each entry would have:

• Model slug (sent to the provider)
• Display name (optional, for the picker)

Custom models would appear in the agent model picker under something like "Custom · OpenAI" / "Custom · SuperGrok", with clear copy that they are not part of Warp's official model catalog and are unsupported.

Important scope boundaries (non-goals for this request):

• This is not a request to add specific models (e.g. Composer 2.5) to Warp's official xAI integration or partnership lineup.
• This is not a replacement for custom endpoints (different URL + key); it's for extra slugs on an existing provider auth path.
• Custom models should respect existing workspace BYO policy (same as custom endpoints / user-added keys).

Implementation sketch (for discussion):

• Client: inject synthetic picker entries (similar to today's custom_llms from custom endpoints) when user defines custom provider models.
• Request: route using existing provider auth (openai key, grok_oauth_access_token, etc.) with the user-supplied slug.
• Server: may need to accept/pass through user-declared slugs when provider auth is present (related to warp:needs-server on Grok Composer 2.5 Fast missing #12832).

Precedent elsewhere: Other tools expose this as manual/curated slugs on OAuth or BYOK (e.g. Hermes xAI OAuth extras, OpenCode provider config). Warp already supports arbitrary model names via custom endpoints; this closes the gap for first-party provider auth without defining a full endpoint.

Is your feature request related to a problem? Please describe.

Today, Warp's model picker is driven by the server-provided feature_model_choice catalog. That works for officially supported models (e.g. grok-build-0.1 for SuperGrok), but users with valid provider access often have models that:

1. Aren't listed in Warp's catalog yet
2. Are callable with their existing auth (BYOK key or SuperGrok OAuth)
3. Shouldn't require setting up a separate custom endpoint (especially for OAuth, where pasting a token into a custom endpoint URL is brittle and undocumented)

Concrete example: #12832 — grok-composer-2.5-fast is available via SuperGrok/Grok Build OAuth but missing from Warp's picker. Maintainers noted it isn't on the public Grok API catalog Warp integrates against; I'm not asking to relitigate that — I'm asking for an opt-in, user-declared custom slug path so power users aren't blocked while waiting for official catalog updates.

Same pattern applies if a provider gives a user early access to a model slug Warp hasn't added yet — e.g. a stealth gpt-6-* preview on an OpenAI key.

Workaround today: Custom endpoints can approximate this for OpenAI-compatible APIs with URL + key, but that's heavy-handed and a poor fit for SuperGrok OAuth.

Additional context

Related issues

• Grok Composer 2.5 Fast missing #12832 — Grok Composer 2.5 Fast missing (specific instance)
• Integration of Grok models #5867 — Integration of Grok models (broader Grok support)

Maintainer context (from #12832): Warp indicated Composer isn't available on the Grok API surface they support yet. This feature request explicitly accepts that and proposes a user-initiated custom model escape hatch instead of official catalog inclusion.

Suggested disclaimer in UI:
"Custom models are not part of Warp's official catalog. Warp does not validate or support them. They may stop working without notice."

Open questions for maintainers

1. Is client-only picker + payload acceptable, or is server allowlist/pass-through required before this can work end-to-end?
2. Preferred storage: settings UI vs file under ~/.warp/ (like custom model routers)?
3. Should custom provider models be disabled when team policy disables user BYO?

Happy to help refine scope or contribute a spec/PR if this direction is acceptable.

Operating system (OS)

Cross-platform

How important is this feature to you?

4

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

Ignore