Make BYOK available without requiring a Pro plan

[techjewel]

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

Describe the solution you'd like?

First, congrats on the open source move. Genuinely a meaningful direction for the project.

That said, one thing feels out of step with the framing: BYOK still requires a Pro plan. For a project that's now AGPL and inviting community contribution, gating the ability to use your own API keys behind a paid tier sends a mixed message.

A few reasons this matters:

1. Open source usually means I can run the software with my own resources. If I clone the repo, build it locally, and want to use my own OpenAI or Anthropic key, I should be able to. Requiring Pro for that makes the open source release feel more like a wrapper around an unchanged product.

2. It limits who can actually use and contribute. Many developers cannot easily pay for a Pro subscription due to currency, payment, or budget constraints. BYOK without a paywall would let them participate fully.

3. It blurs the line between open source and open core. If the most useful self-hosted workflow still requires payment, the project is open core, not open source. Both are valid models, but the framing should match the reality.

Proposal: Make BYOK available to all users of the open source build, without requiring a Pro plan. Pro can still offer cloud features, hosted agents, premium models, priority support, or anything else that genuinely adds value beyond self-hosting.

This would align the product with the spirit of the announcement and meaningfully expand who can use and contribute to Warp.

Thanks for considering it.

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

Yes. Warp's source is now AGPL and the announcement frames this as an open source release, but BYOK (using your own API keys) still requires a Pro plan. That means even if I clone the repo, build it locally, and want to use my own OpenAI or Anthropic key, I cannot do it without paying for Pro.

This creates a few problems:

1. It contradicts the open source framing. Most developers expect that an open source build lets them run the software with their own resources. Right now the open source release feels more like a wrapper around the same gated product.

2. It blocks real contribution. Many developers cannot easily pay for a Pro subscription due to currency, payment method, or budget constraints. If they cannot even use the software with their own keys, they cannot meaningfully test, dogfood, or contribute back.

3. It blurs open source vs open core. Both are valid business models, but the messaging should match the reality. If BYOK stays behind Pro, this is open core, not open source.

Additional context

For reference, most open source dev tools that ship AI features (Continue, Aider, Cline, OpenCode, and others) let users plug in their own keys for free as a baseline. Paid tiers add hosted infrastructure, managed agents, team features, or premium models. That model would work well here too.

I run a software company with around 110 developers. If BYOK worked in the open source build, we would deploy Warp widely across the team and contribute back fixes and improvements. The current setup makes that a non-starter, since asking each developer to also pay for Pro just to use their own keys is hard to justify.

Keeping Pro for cloud features, hosted Oz agents, premium models, and priority support would still leave plenty of reasons to subscribe. Opening BYOK would mostly cost Warp the users who were never going to pay anyway, and gain a much larger contributor and advocate base.

Operating system (OS)

macOS

How important is this feature to you?

5 (Can't work without it!)

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

None

[oz-for-oss]

@techjewel

You can view the triage session on Warp.

Here's what I found while triaging this issue:

This matches current documented/product behavior: BYOK is currently limited to paid plans starting with Build, so this is best routed as a pricing/feature request rather than a bug.

Maintainer details

I concluded that feature request to remove the paid-plan entitlement gate for BYOK so open-source/free users can use their own provider API keys..

Triage summary

This is a feature/pricing request to make Bring Your Own Key (BYOK) available without requiring a paid Warp plan. The report is well specified: the desired behavior is for users of the open-source/free build to configure local OpenAI, Anthropic, or Google API keys without upgrading.

Classification

• Type: enhancement
• Primary areas: billing/pricing entitlement and Agent/BYOK configuration
• Template: .github/ISSUE_TEMPLATE/02_feature_request.yml

Evidence

• Public docs currently describe BYOK as available only on paid plans starting with Build.
• app/src/workspaces/user_workspaces.rs uses current_workspace().map(|workspace| workspace.is_byo_api_key_enabled()).unwrap_or(FeatureFlag::SoloUserByok.is_enabled()), so workspace users depend on billing metadata and solo users depend on a feature flag.
• app/src/workspaces/workspace.rs resolves BYOK from billing_metadata.tier.byo_api_key_policy.enabled.
• app/src/settings_view/ai_page.rs disables/clears API key editors and shows an upgrade CTA when is_byo_api_key_enabled() is false.
• app/src/ai/request_usage_model.rs only treats local keys as preserving AI availability when BYOK is enabled and a key is present.
• app/src/ai/agent/api.rs only includes local provider keys in request params when UserWorkspaces::is_byo_api_key_enabled() is true.

Likely root cause / implementation shape

This appears to be intentional product entitlement gating rather than a defect. A change would likely need product approval for the free/open-source plan boundary, server-side billing tier policy changes for byoApiKeyPolicy, and client updates/tests around the SoloUserByok fallback, settings UI gating, request availability checks, and request payload construction.

Reproducibility

High for the current behavior: users without the BYOK entitlement should see API key inputs disabled or an upgrade path instead of being able to configure usable BYOK keys.

Duplicate check

No likely duplicates were found in the provided recent/open issue list.

Follow-up questions

None for initial triage; the request is a clear product decision rather than missing reporter-specific diagnostic information.

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

Powered by Oz

[TreeTreeDi]

+1

[TheNomadInOrbit]

+1. BYOK should be a baseline for the open-source build so people can use their own keys.

[Abhishek-B-R]

+1. that would be a great feature to add for a open-source repo

[zcg]

+1