GPT-5.5 BYOK not working

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

GPT-5.5 is no longer working with BYOK/custom OpenAI-compatible endpoints. It was working until May 4th. Since then, Cursor no longer sends requests for the GPT-5.5 model to the configured custom backend.

Instead, Cursor blocks the request before it reaches the server and shows an error such as:

“User API key rate limit exceeded” / “User-provided API key rate limit exceeded”

Screenshot 2026-05-07 at 15.46.36
Screenshot 2026-05-07 at 15.46.36794×1960 19.7 KB

This error does not make sense in this case because the request is supposed to go to my own backend, not Cursor’s or OpenAI’s default endpoint. The same backend and API key work correctly in other IDEs/tools.

The issue appears to be specific to GPT-5.5. If I select GPT-5.4 with the same BYOK/custom endpoint configuration, requests are sent correctly and everything works as expected.

Steps to Reproduce

Configure your own OpenAI-compatible endpoint key and base URL in Cursor.
Select GPT-5.5 in the chat.
Send any message.
The issue happens regardless of reasoning level or Fast Mode.
Cursor does not send the request to the configured backend and instead shows a rate-limit error.

Expected Behavior

When GPT-5.5 is selected, Cursor should send the request to the configured custom OpenAI-compatible backend, just like it does with GPT-5.4.

Operating System

MacOS

Version Information

Version: 3.2.21
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

GPT-5.5

Additional Information

This is another serious regression in Cursor’s BYOK/custom endpoint support. There is already another open issue related to this area:

In that issue, image attachments do not work when using BYOK/custom endpoint override. Now GPT-5.5 requests are also not being sent to the configured backend at all.

This makes Cursor unreliable for users who depend on custom OpenAI-compatible endpoints for cost, privacy, routing, or backend-specific reasons.

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, before filing this as a bug, we should narrow down the cause. User Provided API Key Rate Limit Exceeded is usually a wrapper around a 429 returned by the upstream provider, not a client-side block by Cursor. A few questions:

  1. Can your backend see the request in the logs when you try to send gpt-5.5? This is the most important one. If the request reaches the backend and the backend itself returns 429, it’s a quotas or limits issue on the provider side. If the request never reaches the backend at all, then yeah, Cursor might be ignoring the override somewhere.

  2. Did you add gpt-5.5 to Custom Model Names in Settings → Models → the list under Override OpenAI Base URL? Or are you picking gpt-5.5 from the default catalog? The BYOK override only applies to models explicitly added to the custom list. If gpt-5.4 is in that list but gpt-5.5 isn’t, that would explain the difference. A screenshot of that screen would help a lot.

  3. What exact model string did you enter? gpt-5.5, gpt-5.5-chat-latest, or something else?

  4. What kind of backend is behind the base URL? LiteLLM, OpenRouter, Azure, or self-hosted. No need to share the actual URL.

  5. Is Privacy Mode enabled?

Related thread about not being able to add gpt-5.5 as a custom model: Custom model addition failed. You might be hitting the same issue, just with a different symptom.

7

Hey @deanrie ,

Thanks for the questions. Here are the answers:

  1. I checked the backend logs, and the request never reaches my server when GPT-5.5 is selected. This is the main issue. Cursor shows User Provided API Key Rate Limit Exceeded, but my backend receives no request at all, so the 429 is not coming from my server.

  2. I did not add any alias or custom model name manually because GPT-5.5 was already available in Cursor’s model list and was working correctly before May 4th with the same setup.

  3. The model string is gpt-5.5. Before May 4th, my server was receiving requests for these model names:

("gpt-5.5-extra", "gpt-5.5")

Since then, GPT-5.5 requests no longer reach my backend.

  1. The backend is self-hosted.

  2. Privacy Mode is disabled. I do not think this should affect whether Cursor sends the request to the configured custom backend. The whole reason I use BYOK/custom base URL is to route requests through my own backend.

To re-emphasize the issue: this appears to be a new regression. GPT-5.5 was working with the same BYOK/custom endpoint setup before May 4th. Now it fails, while GPT-5.4 still works correctly with the same backend, API key, and base URL.

So the issue does not look like a provider quota or backend rate-limit problem. The request is not reaching my backend at all when GPT-5.5 is selected.

This is urgent because it prevents users from using their own base URL and API key with the latest OpenAI model through Cursor.

8

Thanks for the detailed report, it helped confirm what we suspected.

This is a known bug with BYOK for GPT-5 family models, including GPT-5.5. For these models, the request body gets converted to the Responses API format using input instead of messages, but the URL is only rewritten to /v1/responses for the native OpenAI provider. With a custom base URL, the endpoint stays /v1/chat/completions, so the payload doesn’t match what your backend expects and you get an error that we classify as User Provided API Key Rate Limit Exceeded. That also explains why GPT-5.4 was stable and why GPT-5.5 breaks.

We’re tracking this on our side and your thread is already linked to the issue. I can’t share an exact ETA yet, but we’ll post an update here as soon as we have one.

One note about “the request doesn’t reach the backend”. Can you check access logs instead of application logs, or use tcpdump or proxy logs in front of the app? The request might be arriving but getting dropped before it reaches your handler, which would match what we’re seeing on the Cursor side. If the access logs are also empty, that’s a useful signal, let us know.

For now, the workaround is to stay on GPT-5.4 for BYOK, or use GPT-5.5 without a custom endpoint override.

9

@deanrie

We checked our backend logs. We support both /v1/chat/completions and /v1/responses for gpt-5.5, and gpt-5.4 works against the exact same custom endpoint. In the failing gpt-5.5 BYOK case, no request reaches our backend at all.

So from our side this does not look like “the backend rejected the request.” It looks like Cursor never sent the request to the configured custom endpoint in the first place.

10

Hello @deanrie ,

This is a significant issue for us, and we are currently limited to using GPT-5-4 models. Could you please prioritize this request so that we can access GPT-5.5?

11

Thanks for the extra details, especially that your backend supports both /v1/chat/completions and /v1/responses, and you still don’t see any request reaching it at all. That’s a useful signal. I’ve shared it internally with the team, and it looks like the issue might be happening before the request even leaves Cursor, not just because of the payload format.

On prioritization, this thread is already linked to the right ticket and the team has context. I can’t share an ETA, but I’ll post here as soon as there are updates.

For now, practical workarounds are:

  • Stay on gpt-5.4 with your BYOK setup, since you confirmed that works.
  • Use gpt-5.5 without overriding a custom base URL, if that fits your workflow.

I’ll update the thread when there’s news.

12

I’m having a similar issue, and it only started appearing in the last week or two. It’s honestly very frustrating. Has there been any update on this issue yet? :frowning:

13

Hey, no updates since last week on this yet, so I can’t share an ETA. The bug is being tracked, and this thread is linked to the right issue.

To confirm you’re seeing this exact case and not something similar, could you share a couple details:

  • Which model are you selecting gpt-5.5 or something else?
  • Are you using Override OpenAI Base URL with a custom endpoint, or another BYOK setup?
  • What backend is behind the base URL self-hosted, LiteLLM, OpenRouter, Azure?
  • Does the request reach your backend do you see it in access logs, or is Cursor not sending it?
  • Your Cursor version and OS.

Current workarounds:

  • Stay on gpt-5.4 via BYOK, or
  • Use gpt-5.5 without overriding a custom base URL.

Once there’s an update on the fix, we’ll reply in the thread.

14

I’m not sure whether these messages from @deanrie is being triaged by a bot or by a person, but I think the core issue is being missed.

The problem is not the API key itself, nor the custom backend configuration in general. The issue is specifically that when GPT-5.5 is selected, Cursor does not send the request to the configured overridden OpenAI base URL at all.

The same custom endpoint and API key work correctly with GPT-5.4. The failure only happens with GPT-5.5, which shows that GPT-5.5 requests are bypassing the custom base URL path and are either being validated internally or routed against api.openai.com instead.

This may also be related to the existing BYOK/custom endpoint issue where image attachments appear to fall back to the official OpenAI endpoint instead of the overridden base URL.

So the expected fix seems straightforward:

When GPT-5.5 is selected and the user has configured an overridden OpenAI-compatible base URL, Cursor should send the GPT-5.5 request to that overridden base URL, exactly as it already does for GPT-5.4.

Repeatedly asking users to confirm their API key or endpoint does not address the bug. The request is not reaching the custom backend in the first place.

15

Same thing here.

  • Which model are you selecting gpt-5.5 or something else?

    • gpt-5.5

  • Are you using Override OpenAI Base URL with a custom endpoint, or another BYOK setup?

    • Yes, overriding Base URL with custom endpoint

  • What backend is behind the base URL self-hosted, LiteLLM, OpenRouter, Azure?

    • Self-hosted

  • Does the request reach your backend do you see it in access logs, or is Cursor not sending it?

    • It doesn’t reach my backend

  • Your Cursor version and OS.

    • MacOS, Cursor 3.3.30
16

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

in our project there arent any custom model id added, we use the ones in the builtin cursor model list.

Rquest ID:c8b018d5-0901-4657-b260-1eaccc5d020d

cursor version:Version: 3.3.30VSCode Version: 1.105.1Commit: 3dc559280adc5f931ade8e25c7b85393842acf30Date: 2026-05-09T18:28:42.332ZLayout: editorBuild Type: StableRelease Track: DefaultElectron: 39.8.1Chromium: 142.0.7444.265Node.js: 22.22.1V8: 14.2.231.22-electron.0OS: Linux x64 6.17.0-22-generic

for model selection i just select the respective gpt models like if i didnt have a basurl, no custom model again.just with 5.5 builtin model, the other seems to work(tested with 5.4 & 5.4mini)

Steps to Reproduce

.

Operating System

Linux

Version Information

Version: 3.3.30
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-22-generic

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

17

@Mehmet_Baykar fair point, and yes, I’m not a bot, it’s me replying. I want to confirm I got your key signal and passed it to the team right after post #9: your backend supports both endpoints (/v1/chat/completions and /v1/responses), and the request for gpt-5.5 doesn’t show up in access logs or anywhere else. That means the issue isn’t just “wrong payload on the right URL”. For gpt-5.5, the request from your side isn’t visible at all. This is already noted in the internal discussion on the ticket.

The questions in my post #13 weren’t aimed at you. They were for other users who might read the thread with a similar symptom, to make sure they’re hitting this exact case and not a related one. @nunesmatheus thanks for confirming, your case matches exactly.

On progress, honestly, I don’t have an ETA for a fix. The thread is linked to the right issue, the team has the technical details, including that for gpt-5.5 the BYOK request isn’t going to the override URL. As soon as there’s an update, I’ll post it here, no separate ping.

Current workarounds are still the same:

  • gpt-5.4 with your BYOK setup (confirmed working)
  • gpt-5.5 without an override custom base URL
19

image
image2218×1178 180 KB

20

I’m encountering the same issue. I found that as long as the model name contains gpt-5.5, the same problem occurs.

For example, when I added a custom model named gpt-5.5-xhigh, the same error occurred, and the backend did not receive any requests at all. However, if I use gpt-55-xhigh, the backend can receive requests normally.

I believe this is a bug on Cursor’s server side. I really like Cursor and have already subscribed to Ultra, so I sincerely hope this bug can be fixed as soon as possible.

22

@YIRU_YE, thanks, that’s a really helpful signal. The fact that any model name containing gpt-5.5 breaks, while gpt-55-xhigh makes it to the backend, narrows this down a lot. I shared it with the team and added it to the existing issue.

This supports the idea that the problem isn’t the payload format on the correct URL. It’s that the gpt-5.5 name detection happens before the custom base URL override is applied. Same thing @Mehmet_Baykar is seeing in the access logs the request never gets sent.

For everyone in the thread, while we’re fixing it, here are some temporary workarounds in addition to the existing ones:

  • Stay on gpt-5.4 with BYOK confirmed working
  • Use gpt-5.5 without a custom base URL override
  • If you specifically need gpt-5.5 via your own backend, try setting a custom model name that does not include gpt-5.5 for example gpt-55-xhigh like @YIRU_YE and map it on the backend side. It’s hacky, but at least the requests reach the backend.

I can’t share an ETA for the fix yet. Once there’s an update, we’ll post it here.

23

I am facing the exact same issue

27

today i got a new error instead of the one abt api limit:

Request ID: 5966d05e-29be-4c57-91f4-e7c23503ca51
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Unable to reach the model provider”,“detail”:“We encountered an issue when using your API key: Provider was unable to process your request\n\nAPI Error:\n\n\nRequest failed with status code 400: {\"error\":{\"type\":\"client\",\"reason\":\"routing_unsupported\",\"message\":\"gpt-5.5 routing failed: GPT-5.5 routing only supports Responses-compatible requests\",\"retryable\":false}}\n\n”,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
[invalid_argument] Error
DHe: [invalid_argument] Error
at Dlk (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35695:26781)
at kRw (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35695:25580)
at Olk (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35696:6852)
at vuf.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35696:11731)
at async WQs.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48061:21860)
at async Njf.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48129:12345)
at async Njf.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48129:19576)
at async Iyn.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35828:17397)
at async Ch (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47114:3889)

REQUEST ID:5966d05e-29be-4c57-91f4-e7c23503ca51

28

Got same issue, would like to have any ETA as I consider switching to alternative if the issue wont be fixed within reasonable time - it is blocking my workflow.