BYOK only supports Anthropic, OpenAI, and Google — MiniMax and other providers not available

[DaVinciCloud]

Summary

Warp's Bring Your Own Key (BYOK) feature is limited to three providers: Anthropic, OpenAI, and Google. Users who already pay for other AI providers via subscription (for example, MiniMax, or other platforms) cannot use those keys in Warp, even though the underlying models may be compatible with standard API interfaces. This makes the Build plan's added cost difficult to justify on top of existing provider subscriptions.

Problem

Warp's BYOK allows users to avoid consuming Warp credits by routing agent requests through their own API keys. However, the feature is restricted to only three provider families. Users who pay for other providers — whether directly via subscription or through other platforms like MiniMax — have no way to leverage those keys in Warp. This creates a significant gap for users who are already spending money on AI elsewhere and want Warp to fit into their existing stack rather than replace it.

Reproduction steps or desired workflow

1. User subscribes to a build plan on Warp.
2. User already pays for AI access through another provider (e.g., MiniMax) via a separate subscription.
3. User opens Warp Settings and searches for "API keys" to configure BYOK.
4. Only Anthropic, OpenAI, and Google options are available.
5. User cannot connect their MiniMax or other provider keys, and therefore sees no path to offset Warp credit usage with their existing spending.

Expected behavior

Warp's BYOK should support a broader range of model providers (at minimum, those with standard OpenAI-compatible API interfaces) so that users can route requests through their existing provider subscriptions rather than being forced to consume Warp credits.

Warp version

Unknown

Operating system

macOS

[oz-for-oss]

@DaVinciCloud

This issue appears to overlap with existing issues:

• Ability to set base_url for openai compatible endpoints for using Oz - use any provider instead of the big 3 #9368 — Ability to set base_url for openai compatible endpoints for using Oz - use any provider instead of the big 3
• Custom OpenAI-Compatible Provider Endpoints (BYO Endpoint for Local & Remote LLMs) #9303 — Custom OpenAI-Compatible Provider Endpoints (BYO Endpoint for Local & Remote LLMs)

If this report is meaningfully different, please comment with the additional context or distinguishing behavior so a maintainer can review it. Otherwise, a maintainer may close it as a duplicate after review.

Maintainer details

I concluded that this is a duplicate enhancement request for broadening BYOK beyond the fixed built-in provider set, especially via custom OpenAI-compatible provider endpoints..

Duplicate reasoning

• Ability to set base_url for openai compatible endpoints for using Oz - use any provider instead of the big 3 #9368: Requests the same core capability as this issue: configuring an OpenAI-compatible base URL so Oz/Warp can use providers beyond the fixed big-three provider set.
• Custom OpenAI-Compatible Provider Endpoints (BYO Endpoint for Local & Remote LLMs) #9303: Describes the same BYOK limitation and asks for custom OpenAI-compatible endpoints with base URL, model name, and optional API key support.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[MukundaKatta]

The cleanest path here is probably an "OpenAI-compatible (custom endpoint)" provider type, not adding MiniMax/DeepSeek/Together/etc one by one. Most providers (including MiniMax) already expose an OpenAI-compatible v1/chat/completions endpoint, so reusing the OpenAI client with a configurable base URL covers nearly all of them at once. Saves Warp from chasing API shapes per vendor.