Hey @deanrie ,
The account I posted from is not my business account. After the previous BYOK issue was fixed, I purchased the Ultra subscription again.
I also do not agree with the statement that “this isn’t a bug, it’s expected behavior.” From a user perspective, this is a bug.
I am paying $200/month to use Cursor and it is my right to use Composer 2.5. If I want to use custom models through BYOK alongside Cursor’s own Composer models, I should be able to do that without constantly disabling keys, changing base URLs, or using manual workarounds. Explicitly selecting Composer while BYOK is enabled should route Composer through Cursor’s official infrastructure, not fail because a custom OpenAI-compatible endpoint is configured.
The suggested workaround:
“If you explicitly pick Composer, turn off the OpenAI key with Cmd+Shift+0 or disable Override Base URL.”
does not really solve the issue. It just forces users to constantly switch settings depending on the model they want to use. That is not a good experience for a paid Ultra user.
I already stopped using Cursor and cancelled Ultra for around two months because of the previous BYOK vision attachment issue. I do not want to go through that again. These kinds of routing issues feel small and fixable, but when they take months to resolve, they make Cursor much harder to rely on for daily work.
Please reconsider treating this as expected behavior. The expected behavior should be per-model routing: Composer should always use Cursor’s infrastructure, while BYOK/custom base URLs should apply only to compatible external vendor models.
I would appreciate it if this could be escalated and prioritized.