Hey, I’ll reply to the latest posts for everyone at once.
@riccardo.bevoni about question #29. System prompts are just an internal implementation detail, and they’re not what triggers the issue. The actual bug mechanism is this:
For GPT-5 family models, including gpt-5.5, Cursor converts the request body to the Responses API format using input instead of messages.
Rewriting the URL to /v1/responses happens only for the native OpenAI provider. With Override OpenAI Base URL, the URL stays /v1/chat/completions, but the body is already in Responses API format, so you get a mismatch.
The check for “this is gpt-5.5” is done based on the model name before the override is applied. So a name without the gpt-5.5 substring, like gpt-55-xhigh, avoids this path and the request actually reaches your backend.
So yeah, what matters is the model name, whether it contains gpt-5.5, not “different prompts for different models”.
About the error in post #27, routing_unsupported: GPT-5.5 routing only supports Responses-compatible requests, Request ID 5966d05e-29be-4c57-91f4-e7c23503ca51. It’s the same root case, just with a different error message. I’ve shared it internally as an extra signal.
@b13l1, @Devi_Tripathy: I see your reports, they’re logged as additional confirmations. I can’t share an ETA for the fix yet. The issue is tracked and the team has the technical context.
Workarounds haven’t changed:
gpt-5.4 with BYOK, works.
gpt-5.5 without overriding the custom base URL.
A custom model name without the gpt-5.5 substring, for example gpt-55-xhigh, mapped to your backend. It’s a hack, but requests go through.
Thanks @deanrie , that clarifies the bug mechanism.
My previous question was not phrased very clearly. What I meant to ask was slightly different:
Do different model names in Cursor trigger different internal system prompts or model-specific handling? I assume there may be some model-specific behavior on Cursor’s side.
So my concern is this:
If I select gpt-5.4 in Cursor, but my proxy maps/overrides the actual backend request to gpt-5.5, could that lead to worse performance because Cursor is preparing the request as if it were gpt-5.4 rather than gpt-5.5?
And similarly, if I use a custom model name like gpt-55-xhigh to avoid the current routing bug, does Cursor still apply the right behavior for GPT-5.5, or could that also affect performance/quality because Cursor no longer recognizes it as the real gpt-5.5 model?
In other words, I understand that the current issue is caused by the model-name check and the Responses API / Chat Completions mismatch. My remaining question is about quality: whether using gpt-5.4 or a custom model name as a workaround changes Cursor’s prompting/request handling in a way that could make GPT-5.5 perform worse than when it is used natively.
@riccardo.bevoni short answer: yes, the model you pick in Cursor affects how the client builds the request, not just routing. Different models have different built-in request params, tool call formats, and for the GPT-5 family it also converts the body to the Responses API format. This isn’t a separate system prompt, it’s model-aware request scaffolding.
What this means for workarounds:
Picking gpt-5.4 in Cursor and mapping it to gpt-5.5 on your proxy. The request will be built for gpt-5.4 with no Responses API conversion and with its own params. The gpt-5.5 model will still run, but it’ll get scaffolding that wasn’t made for it. On simple tasks you probably won’t notice, but on more complex agent behavior you can see a quality drop.
Using a custom name without the gpt-5.5 substring like gpt-55-xhigh. Cursor won’t recognize it as GPT-5 family, so it won’t apply the Responses API conversion. That’s why the workaround works at all. Same downside: GPT-5.5-specific scaffolding won’t be applied, so the request goes out in a generic Chat Completions format.
Both options get you to the backend, but neither is the same as native GPT-5.5 via BYOK. If you care about 5.5 answer quality, the cleanest option for now is gpt-5.5 with no custom base URL override. Once the fix rolls out, normal BYOK should work like before.
@user691 thanks, that’s a useful signal. To figure out if a fix already rolled out or if your setup is a bit different, can you share:
Cursor version: Help → About or Cursor -> About Cursor
OS
Are you using Override OpenAI Base URL with a self hosted endpoint, or a different BYOK setup?
Model name in Cursor: gpt-5.5 directly, or a custom one?
@Mehmet_Baykar, @riccardo.bevoni, @nunesmatheus, @Devi_Tripathy, @b13l1, @YIRU_YE if you have a minute, can you retest on the latest Cursor version with your usual BYOK setup, without the gpt-55-xhigh hack, and tell us if the request reaches the backend. That’ll help us quickly confirm whether the issue is gone for all setups or only some.
Until we confirm the fix, the same workarounds apply:
gpt-5.4 with BYOK
gpt-5.5 without a custom base URL
A custom model name that doesn’t include gpt-5.5, for example gpt-55-xhigh, mapped on the backend
@user691, thanks for the details, that’s a helpful signal. Version 3.6.12 is on the Nightly track, so the fix is already there. For Stable, I’m waiting for confirmation from others in the thread so we can make sure it works for all setups.
For everyone else, as soon as you can update or try Nightly, please reply and confirm whether requests for gpt-5.5 reach the backend with a normal BYOK setup, without the gpt-55-xhigh hack. That will let us close the thread.
A couple quick notes from your post:
Slow gpt-5.5 vs Composer 2.5 is about model or proxy latency, not this bug. If you want us to look into it, please open a separate thread with a couple Request IDs from slow requests. Chat > top right menu > Copy Request ID.
Composer 2.5 not working with this BYOK setup is also separate, with a different root cause. Best to open a separate thread with the exact error, your version, and steps to reproduce, so it doesn’t get mixed up with the GPT-5.5 fix here.
@nunesmatheus, @Devi_Tripathy, @user691, thanks for confirming. That matches what we’re seeing on our side: the fix is in Nightly 3.6.12 and it’s already in Stable starting from 3.5.38. So BYOK plus gpt-5.5 with the normal Override OpenAI Base URL should work again without any hacks.
@Mehmet_Baykar, @riccardo.bevoni, @YIRU_YE, @b13l1, when you have a minute, please update to 3.5.38 or newer and test your usual BYOK setup without gpt-55-xhigh and without switching to gpt-5.4. If requests reach the backend, reply here and we’ll close the thread. If it still doesn’t work for anyone, please share your Cursor version, OS, and Request ID, and we’ll take a separate look since that would be a different case.
I’ll keep the workarounds here for now, just in case you’re on an older version:
gpt-5.4 with BYOK
gpt-5.5 without a custom base URL
A custom model name without the gpt-5.5 substring, like gpt-55-xhigh, mapped on the backend
Hey, good news, we’ve fixed the BYOK issue for gpt-5.5 on our side. Update to the latest version of Cursor, and requests should start going to your custom endpoint again, like they did with gpt-5.4.
Thanks for the detailed reports, and special thanks to @YIRU_YE for spotting the model name matching issue, it helped us pin down the root cause quickly. If anything’s still acting up after the update, post here.