When using OpenAI API Key + Override OpenAI Base URL (custom OpenAI-compatible endpoint / BYOK), attaching any image to a chat causes the request to fail with:
“Unauthorized User Openai API key”
Text-only chats work perfectly fine with the custom endpoint. The moment an image is attached, Cursor falls back to the official api.openai.com endpoint (or uses hardcoded verification), which rejects the custom API key.
This has been an issue since at least July 2025 and is still not fixed as of April 19, 2026.
Steps to Reproduce
Go to Settings → Models
Enable OpenAI API Key and enter your key
Enable Override OpenAI Base URL and point it to your custom OpenAI-compatible endpoint (e.g. local LLM, vLLM, LiteLLM, Azure, Groq, etc.)
Select a vision-capable model (gpt-5.4)
Open a new chat
Attach any image (PNG/JPG) + type a prompt → Send
Expected Behavior
The full vision request (including image) should be sent to the overridden custom endpoint with correct authentication and payload.
Actual Behavior
Request immediately fails with “Unauthorized User Openai API key”. Removing the image makes the exact same chat work again. The override is completely ignored for multimodal requests.
This makes Cursor unusable for anyone who relies on custom or local vision models with gpt-5.4 or other multimodal setups. Please prioritize a fix for proper vision routing under OpenAI override / BYOK.
Hey, thanks for the detailed report and links. This is a bug on our side and it’s confirmed. The issue is a hardcoded validation for api.openai.com for multimodal requests, which ignores the custom base URL override. You described it correctly. Text requests bypass this code, images hit it.
We’re tracking the issue internally, but I can’t share a fix timeline yet. Gathering the related threads in one place is helpful, and the links will help with prioritization.
There’s no temporary workaround right now. If vision is critical, you’ll need to either use Cursor’s built-in models or use a separate tool for multimodal requests to your custom endpoint. I know that’s not a real solution.
As soon as there’s an update on the fix, I’ll reply in this thread.
Thanks for confirming this is a bug on your side (hardcoded validation for api.openai.com on multimodal requests). I appreciate the transparency.
However, I need to be very direct: this is a complete blocker for me, and I cannot continue using Cursor in its current state.
I run heavy automated workflows inside Cursor that heavily rely on the vision. These workflows involve attaching images (screenshots, diagrams, UI mocks, figma prototypes, error logs, etc.) and having the model read and act on them. Without vision support on my custom OpenAI-compatible endpoint (which I use for cost, privacy, and specific model needs), the entire auto mode becomes useless. Text-only mode is not an option for what I do.
The fact that this has been broken since at least July 2025 (9+ months) and is still not fixed as of April 2026 is extremely frustrating. Multiple users have reported the exact same issue (Azure, vLLM, LiteLLM), and it was even acknowledged internally as “a bug on our side.” Yet here we are, almost a year later, with no fix and no workaround.
I understand you can’t share a timeline, but I have to ask:
Is there any temporary workaround at all? Even something hacky (like a specific model setting, or internal flag) that would let vision requests actually respect the “Override OpenAI Base URL” setting?
Right now I’m forced to either:
Switch back to Cursor’s built-in models (not viable for my use case), or
Leave Cursor entirely and go back to VS Code + Codex.
This isn’t a nice-to-have feature request — it’s a hard blocker for my daily work. I’d really appreciate if the team could prioritize this or at least explore a quick internal patch / beta build for affected users.
Please let me know if there’s any path forward, even a short-term one.
This is currently a blocker for us. We need to implement UI/design work in Cursor, and image attachments are essential for that workflow. However, because multimodal requests appear to bypass the configured OpenAI Base URL override, we cannot use our OpenAI-compatible backend for image-based conversations.
Text-only requests work correctly with our backend, but the moment an image is attached, the request fails with:
“Unauthorized User Openai API key”
This makes the OpenAI BYOK / custom endpoint setup unusable for vision workflows, which are critical for implementing designs from screenshots, Figma exports, and UI references.
Could this be prioritized or escalated? A fix for proper vision routing through the configured OpenAI Base URL override would unblock our team’s workflow.
Hey, no updates on the fix yet, and I can’t share an ETA.
@Mehmet_Baykar about a workaround: I can’t suggest anything clean inside Cursor. The only thing that might work on your side is to put a proxy in front of your custom endpoint that accepts any OpenAI-valid key format on /v1/models and just returns 200 for the check, then forwards the real requests to your backend. It’s a hack, but multimodal requests should get past the hardcoded validation. If you’re using vLLM or LiteLLM, LiteLLM can respond correctly on /v1/models, so make sure that endpoint is reachable and the key is valid there.
Once there’s an update on the fix, I’ll post it here.
Same problem. here . this bug didn’t exist 10 releases before. I get it now every day when i use the custom base model, OpenAI compliant, override endpoint .
Thank you for your previous reply and for suggesting the proxy workaround. I tried using a mockable OpenAI API key, but it did not resolve the problem.
As paying customers, we are unfortunately unable to fully utilize Cursor for our core workflows because we cannot use our own OpenAI-compatible backend with image attachments. This is a very significant blocker.
We rely on vision capabilities daily for UI/design work — reviewing screenshots, Figma prototypes, diagrams, and more. The moment an image is attached, the request bypasses our configured “Override OpenAI Base URL” and fails with the “Unauthorized User Openai API key” error.
This bug has existed for more than 10 monhts (since at least July 2025). As you can see in this thread, many other users are experiencing the exact same issue.
We would greatly appreciate if the team could prioritize fixing the vision routing for custom endpoints/BYOK setups as soon as possible.
No updates on the fix yet, so I can’t give an ETA, being honest. But I see the thread has a few confirmations from different users, and the impact in the logs is big. I’ll raise this internally again.
About the proxy workaround, I think I know why it didn’t work. The validation request to /v1/models is sent from our backend, not from the IDE, so a proxy in front of your endpoint won’t catch it if the base URL override isn’t applied on that code path, which is basically the bug. To fully confirm your case, what exactly did your proxy show in the logs when you tried an image request, did you see any hit to /v1/models, or did nothing come in? If nothing came in, that confirms the validation is bypassing the override, and sadly there’s no user-side workaround.
When I have an update on the fix, I’ll reply here.
I checked the logs. When an image is attached, the request never comes to the server. So please fix it. I would appreciate if it can be fixed this week because we are already due to finish our tasks for design implementation and we really don’t want to switch to another IDE.
Hey, no updates on the fix yet. I know this has been dragging on for a while.
@Devi_Tripathy thanks, I added your report to the other confirmations in the thread.
On the workaround again: @Mehmet_Baykar confirming that /v1/models never even reaches the proxy fully rules out that hypothesis. The validation leaves our backend without applying the override, so the user can’t work around this on their side. If vision is critical right now and you can’t wait, the only practical option is to temporarily use Cursor’s built-in models for multimodal tasks, and keep the custom endpoint for text-only.
As soon as there’s an update on the fix, I’ll post it here.
Unfortunately, I still do not understand why this issue has not been prioritized for an immediate fix. Any Cursor user relying on a custom OpenAI-compatible endpoint, whether Azure, LiteLLM, vLLM, or another backend, cannot use image-based workflows properly because multimodal requests ignore the configured base URL and still hit api.openai.com.
This has been reported for more than 10 months across multiple forum threads, and it is now confirmed as a bug on Cursor’s side. From a user perspective, this is not a minor edge case. BYOK/custom endpoint support is effectively broken for vision workflows, which are essential for UI/design implementation, especially when working with screenshots, Figma exports, design references, and mobile app screens.
Because of this, we have had to move back to Codex for these workflows. We cannot continue using Cursor seriously until vision requests correctly respect the configured OpenAI Base URL override.
For other users facing the same issue: if your workflow depends on your own OpenAI-compatible endpoint and image attachments are important, Cursor is currently not a reliable option for that use case. The only practical alternative is using Cursor’s built-in models, but those options have not been reliable enough for high-quality UI/design implementation, especially for mobile app screens where screenshots, Figma exports, spacing, layout details, and visual accuracy matter a lot.
We’re also experiencing the same bug, unfortunately we’ve had to cancel two Ultra subscriptions as they no longer work with our use-case due to this bug.
Hopefully you can provide a fix and we can resubscribe.
Hey @Mehmet_Baykar, honest answer: there’s still no fix, and I don’t have an ETA I can share.
What I’m doing on my end today: I’m escalating the impact summary internally with the new confirmations in this thread from @Devi_Tripathy, @Viktor1, and @agoodkind, plus @rid’s Ultra cancellations. That kind of concrete signal helps with prioritization, even if I can’t promise a timeline.
On the workaround: your log check confirmed what I suspected. The /v1/models validation never reaches your backend, so the override is getting skipped before the request even leaves us. There’s nothing you can change on your side to fix that. Using built-in models for multimodal and a custom endpoint for text-only is the only stopgap right now.
I won’t post here again until there’s something real to share. Appreciate the patience, even though I know it’s wearing thin.
Just wanted to add that I’m facing the same thing when overriding OpenAI base URL. Text-only works, but image upload doesn’t. I also get the same error when using @Browser, maybe because it takes snapshots and tries to send images on the request too. I don’t see any logs on my self-hosted proxy, so I don’t think it’s being reached.
Frankly speaking, waiting 25 days for an issue to be fixed, while Cursor is releasing almost one update every day, shows how the Cursor team handles customer support.
@nunesmatheus thanks for confirming. The @Browser case is a useful signal. Browser snapshots go through the same multimodal pipeline, so they fail with the same error. I’ll add this to the impact summary since it helps clarify the blast radius.
@Mehmet_Baykar I hear you, and the frustration makes sense. I won’t try to justify it with release pace. Frontend updates and fixing this specific backend code path are handled by different teams with different cycles, but I agree that’s not a good argument from the user side.
There’s still no ETA for the fix. As soon as we have something real, we’ll post an update here.