Product / Version
Cursor IDE version: 3.1.14
OS: Windows 10 (10.0.19045)
Same account on Mac: works
What happens
In Settings > Models, when I add a custom model (Qwen via DashScope OpenAI-compatible API), clicking Add makes the model disappear immediately.
No usable saved model entry remains in Settings.
Expected
Model should persist in Settings after Add.
Validation already done
API key is valid from terminal:
GET /compatible-mode/v1/models returns full model list including qwen-plus, qwen-plus-latest, etc.
Chat/completions endpoint also reachable.
Tried cache reset on Windows (globalStorage, workspaceStorage) and full restart/relogin.
Still reproduces on Windows.
Same account/config on Mac can add models successfully.
Why this seems like Cursor-side regression
Credentials and endpoint are valid (proven by direct API calls).
Cross-device behavior differs (Mac OK, Windows fails).
Looks like Windows-side custom model persistence/UI state issue.
Logs
Please inspect latest logs under: %APPDATA%\Cursor\logs
(especially latest window*/renderer.log and related workbench logs around the Add click time)
Hey, thanks for the detailed report. Great work validating the API and doing cross-platform testing.
This is a known bug that was logged just yesterday, April 14. The issue is that after you click Add, it triggers a model refresh from the server, which removes custom models that aren’t in the Cursor catalog. The team is aware, and it’s currently in triage.
Unfortunately, there isn’t a working workaround yet. The only option for now is to use Mac, like you’re already doing. I’ll link your report to the ticket to help raise the priority.
Hey @Yufei_Huang,
The issue with custom models not saving has been addressed and the fix should be available on the nightly release channel. If you’d like to try it out before it hits stable: open Cursor Settings > About and switch the Release Track to Nightly, then restart Cursor. Let me know if that resolves it!
After switching Cursor release track settings (to Nightly), adding DashScope/Qwen as a custom OpenAI-compatible model on Windows fails consistently.
When I add qwen-plus, Cursor shows:
Model name is not valid: "qwen-plus"
or the model disappears immediately after clicking Add.
Environment
Cursor (Windows): affected
OS: Windows 10 (10.0.19045)
Same account on macOS: works normally
Base URL used: https://dashscope.aliyuncs.com/compatible-mode/v1
Model ID tested: qwen-plus
What changed before issue
I changed release track settings to Nightly (per local settings workflow), then restarted Cursor.
After that, custom model add flow started failing on Windows.
Reproduction Steps (Windows)
Open Settings > Models
Set OpenAI API key (DashScope key)
Enable override base URL and set: https://dashscope.aliyuncs.com/compatible-mode/v1
Enter model name: qwen-plus
Click Add
Actual Result
Error: Model name is not valid: "qwen-plus"
and/or model entry disappears immediately after Add.
Expected Result
Model should be accepted and persist in Settings.
Validation already completed
Provider/API is healthy
Direct terminal call to DashScope OpenAI-compatible GET /models succeeds.
Response includes qwen-plus, qwen-plus-latest, etc.
Model ID is valid at provider side
qwen-plus is present in provider model list.
Cross-device comparison
Same account + same provider config works on macOS.
Only Windows side is failing.
Local cache cleanup attempts
Cleared/rebuilt parts of local Cursor user state (globalStorage, workspaceStorage) and restarted.
Issue persists.
DevTools observation
Network mostly shows telemetry/events to Cursor endpoints (e.g. api3.cursor.sh with 202).
No clear successful provider validation request observed at Add click moment in failing path.
Technical Hypothesis
Likely a Windows-side regression in custom model validation/persistence flow (UI-side validation/state writeback), not a provider-side model-name issue.
Request for engineering
Please help verify:
Which validation API is called when clicking Add Custom Model on Windows for OpenAI-compatible providers.
Whether base URL override is actually applied in that validation step.
Why valid provider models (confirmed via /models) are rejected as “Model name is not valid”.
Whether Nightly track introduces a model-metadata/state regression on Windows.
Hey, thanks for testing on Nightly and reporting back, this really helps.
Looks like the persistence part is fixed now the model no longer disappears right after Add. But on Windows a separate model name validation layer is firing Model name is not valid: "qwen-plus". From the symptoms, this looks similar to another known case with BYOK and custom model names. I’ve forwarded it to the engineers as a follow-up to the original bug. I can’t share an ETA yet.
To confirm the diagnosis and speed this up, can you send:
The exact Nightly version Help > About or Cursor Settings > About build number and date
A screenshot or the text from DevTools Console at the moment you click Add Help > Toggle Developer Tools > Console. I need the requestId and the full errorDetailsDebug
The Network tab there as well the AvailableModels request and any validation request during Add, with status and full response body
On macOS, keep working as before, the flow isn’t broken there. Once I have an update on the Windows fix, I’ll reply in the thread.
Hey, I can see the screenshot and the version. That’s Stable 3.1.17 with Release Track: Default, and the fix for the persistence issue is only in Nightly right now. It hasn’t reached Stable yet, so the symptoms will be the same.
Confirm the version in Help > About (it should be Nightly with a build date)
Also for the Windows error Model name is not valid: "qwen-plus" on Nightly, we need these details at the moment you click Add:
Console Help > Toggle Developer Tools > Console: the full error text, requestId, and errorDetailsDebug
Network: the AvailableModels request and any validation request at the moment of Add, including status, headers, and the full response body (not just rgstr or full_stripe_profile, that’s background telemetry and not related to validation)
Right now the screenshot only shows telemetry, so we can’t diagnose it from that.
