When adding custom model kimi-k2-7-code under custom OpenAI endpoint pointing to Volcengine Ark coding gateway, Cursor throws AI Model Not Found, model name is not valid error on chat panel. Verified via standalone curl requests that the backend API gateway can properly accept this hyphenated model alias and route requests to native kimi-k2.7-code model with normal response returned. The API key, base URL, network connectivity and backend model permission are all functional; this validation failure only occurs inside Cursor client.
Steps to Reproduce
Configure custom OpenAI Base URL to Volcengine Ark coding endpoint, input valid API key in Cursor Models settings.
Add custom model with name kimi-k2-7-code and save configuration, fully restart Cursor to reload local config.
Select kimi-k2-7-code as active model in chat sidebar, send any chat request.
Cursor immediately returns AI Model Not Found error locally without sending valid request to backend.
Use identical base URL, API key and model name to send curl request externally; backend gateway processes request normally and returns correct response, proving backend service works fine.
Expected Behavior
Cursor should send chat requests to the configured custom endpoint using the user-defined custom model name, without extra local model existence validation that blocks outbound requests. The custom model kimi-k2-7-code can be selected and used for coding/chat interactions normally, same as when calling the API via curl directly.
Hey, thanks for the detailed report and screenshots. I can see what’s going on in the second screenshot in the API Keys section. The key itself is saved (Secret saved), but the OpenAI API Key toggle is turned off. When that toggle is off, Cursor doesn’t attach your key to the request, so the backend rejects the unknown model name with the AI Model Not Found error. That error is coming from the backend, which is why curl works directly (it sends the key) but Cursor doesn’t.
What to do:
Settings > Models > API Keys section
Turn on the toggle next to OpenAI API Key (it’s OFF right now)
Leave Base URL override as-is, and keep the model name as kimi-k2-7-code (the dash instead of a dot is correct, it helps avoid a conflict with a managed model in the catalog)
Send the request again
If the error still happens after turning the toggle on, send me the Request ID (in chat: top-right menu > Copy Request ID) and I’ll dig deeper. Also let me know if the toggle turns itself off after restarting Cursor.
Hello support, I have two related model calling issues on Cursor:
Native built-in models (Cursor Grok 4.5 High Fast) return Bad Request: This model does not support custom API keys once I turn on the secret saved toggle, request ID: fd398dbd-fbfb-4bae-84d5-0e2df3dff6f5;
My custom added model kimi-k2-7-code returns Provider Error: We're having trouble finding the resource you requested when making requests, request ID: 2f5d0c49-5a94-4721-8dff-82d0ca35f0c7.
Neither built-in nor custom models work properly now. Please help resolve this, thanks a lot.
Thanks for the update and the Request ID. Things are clearer now, so let’s go through each error one by one.
Cursor Grok 4.5 High Fast → This model does not support custom API keys
This is expected. The OpenAI API Key toggle plus the Base URL override works globally for all OpenAI-family models. While it’s ON, you can’t use Cursor built-in models like Grok, Auto, Composer, etc. They don’t accept a custom key. The toggle is either or:
toggle ON → only your custom models through Volcengine Ark will work
toggle OFF → Cursor built-in models will work
You can’t mix a built-in model and a custom endpoint at the same time.
2 and 3. glm-5-2 → Unauthorized User API key and kimi-k2-7-code → Provider Error / trouble finding the resource
This is actually good news because it means the request is now really going to your endpoint and local validation is not blocking it anymore. Both errors are coming from Volcengine Ark itself, not from Cursor:
Unauthorized User API key 401 means the endpoint rejected the key for glm-5-2
resource not found 404 means the endpoint couldn’t find the kimi-k2-7-code model
One important detail: BYOK requests go client → Cursor backend → your Base URL, so it’s not the exact same path as a direct curl call. A request that works via curl might not match what Cursor sends one to one.
Can you check on the Ark side:
the exact model IDs the endpoint expects for glm-5-2 and kimi-k2-7-code, sometimes the provider needs the full slug, not an alias
that your key is authorized for both models
If the errors are still there after confirming the model IDs, send the new Request IDs for each model and I’ll check what’s being sent to the endpoint.
