Hey, thanks for the report. This isn’t about case sensitivity. The comparison field is case-sensitive. The issue is that gpt-5.5 is the name of a built-in Cursor model (an internal ID), so if you add a custom model with the same name, Cursor sees a collision and shows already available.
Two ways to work around it:
If your goal is to run gpt-5.5 through your own OpenAI-compatible endpoint, don’t add it as a custom model. Turn on Override OpenAI Base URL in Settings → Models, then set your URL and API key. Requests to the built-in GPT-5.5 will go to your endpoint.
If you need a separate custom model, give it a name that doesn’t match Cursor’s built-in models.
This limitation is known. I can’t share an ETA for a change yet. Let me know if the override option doesn’t solve your use case.
The API I requested gave me the model name “gpt-5.5”, an exact name match. Any incorrect capitalization or anything else prevented the call from being completed.
I get the concern, but here’s the good news. When you route through Override OpenAI Base URL, Cursor does not change casing and does not rename the model. Your endpoint will receive exactly gpt-5.5 the internal lowercase ID. “GPT-5.5” is only the display name in the UI. So your case-sensitive API will get gpt-5.5, as you need.
Setup:
In Settings → Models, enable your OpenAI key and Override OpenAI Base URL, then set your URL.
Don’t add gpt-5.5 as a custom model. Just use the built-in GPT-5.5, and the request will go to your endpoint with the name gpt-5.5.
To confirm what’s actually sent to your endpoint, the easiest way is to check your proxy or gateway logs. You’ll see the exact model name in the payload. Or temporarily set an obviously wrong Base URL. If the request fails with a network error, routing is going through your endpoint.
If you still get a payload format error on /chat/completions, that’s a separate known issue. If that happens, send the Request ID and we’ll take a look.