When will Cursor fully support BYOK?

Feature request for product/service

Cursor IDE

Describe the request

Many current IDEs and CLI-based agents allow users to connect their own API keys via configuration and easily customize model parameters. However, Cursor, a once-popular IDE, still lacks this capability. Its current Bring Your Own Key (BYOK) feature is barely functional: users cannot configure any model parameters such as reasoning intensity and context window length, and are only allowed to enter a base URL and an API key, with support limited to just one base URL. I want Cursor to remain competitive among AI code platforms, yet its limited BYOK support severely restricts users’ options and configuration flexibility. This forces users to switch to alternative platforms just to access models from certain APIs.

Operating System (if it applies)

Linux

indeed, upvoted ! tips for now, you should give a look at third parties before official support!

Hey, thanks for the feature request and for the clear details. You’re right that BYOK is pretty minimal right now: one base URL and one provider key, with no way to configure model params like reasoning effort or context window.

I’ve logged this as a feature request to expand BYOK configuration model params plus support for multiple base URLs. To be honest, there’s no concrete timeline for this right now. Votes and comments in the thread help us prioritize, so if anyone else has similar use cases, please share them here.

As a temporary option, @Tom_Coustols already shared a solid workaround using LiteLLM as a proxy. I’d recommend taking a look: Cursor Integration | liteLLM

There are also a couple related threads you can check out and vote on:

Thanks for your suggestion, but after checking, it seems custom configuration of the model context and thiking depth is not supported.

well, indeed, those solution never could beat default integration, our only hope if to share this project enough and see if more people are interested by it!

I’ve looked into the liteLLM solution, and it doesn’t seem to support the definition of model parameters either. I think the topic votes related to BYOK have limited effectiveness, because not many people will actually post feedback about these issues on the forum. Most users will simply switch to other platforms that support BYOK once they find this feature missing, rather than genuinely wanting the current platform to be improved. After all, there are countless AI coding platforms available nowadays. Even so, I hope Cursor can become more polished so that I can keep using it long-term.

Fair point, and I won’t argue with your upvote logic. You’re right that most users just leave instead of posting feedback. That’s why detailed posts like yours are valuable on their own, even without a hundred upvotes.

To be honest, expanding consumer BYOK config (model params like reasoning effort and context window, multiple base URLs) isn’t in the near-term plans right now, and I don’t have a timeline for it. Part of this is architectural since all model traffic goes through the Cursor backend, so the current BYOK is intentionally thin. I don’t want to create false expectations that this will be fixed soon.

What I can do is keep your case logged as a separate signal for consumer BYOK configuration needs (specifically model params, not enterprise routing, those are different). If priorities change, I’ll reply in the thread.

Thanks for not just leaving and for spelling out what’s missing. It really helps us see where we’re falling short.

I have another minor suggestion: add a conversation selection feature for agent dialogues. When there are numerous dialogue turns within a single dialogue box, it becomes difficult for us to accurately locate the specific turn we need. I hope a navigation bar can be added inside the dialogue box to enable quick positioning of any conversation turn, just like the one in ChatGPT.