Pro + Override Base URL: custom models fail in Agent (BAD_MODEL_NAME / Free named-models gate) — 3.17.19

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Pro plan. Cursor 3.17.19 macOS arm64.

Override OpenAI Base URL plus custom model IDs worked in Agent until 2026-08-24. Broken since 2026-08-25.

Catalog Auto and catalog Kimi K3 still work. Same custom IDs work via curl outside Cursor.

Failure A: ERROR_BAD_MODEL_NAME with bring_your_own_key false
9926f36f-e1b7-42f9-bb2d-937d43a82863 kimi-for-coding-highspeed
940d0647-2612-476e-835a-83bcd87761d6 k3-256k

Failure B: ERROR_RATE_LIMITED_CHANGEABLE Free named models gate despite Pro
a2bcc770-9ed6-4ea6-b42d-592209997bd5 k3 bring_your_own_key true

Please inspect those Request IDs.

Steps to Reproduce

Settings Models. Enable OpenAI API Key. Enable Override Base URL to Kimi coding v1 endpoint. Add custom IDs kimi-for-coding k3-256k k3. New Agent chat. Select custom ID. Send ping.

Expected Behavior

Agent should call Override endpoint with custom model ID and my key. Pro should not get Free named-models gate.

Operating System

MacOS

Version Information

Version: 3.17.19
VSCode Version: 1.128.0
Commit: ae3a2b7231dd56194447fe4570dfdc61640b1e90

For AI issues: which model did you use?

kimi-for-coding-highspeed k3-256k k3

For AI issues: add Request ID with privacy disabled

9926f36f-e1b7-42f9-bb2d-937d43a82863
940d0647-2612-476e-835a-83bcd87761d6
a2bcc770-9ed6-4ea6-b42d-592209997bd5

Additional Information

membershipType=pro, subscriptionStatus=active.
Same custom IDs worked on this install through about 2026-08-24.
Workaround: catalog Kimi K3 with Key OFF (Cursor-billed). Not acceptable as replacement for Override BYOK.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @gshevchenko, thanks for the detailed report. The request IDs helped a lot, so let’s go through it piece by piece.

Failure A (AI Model Not Found / BAD_MODEL_NAME, requests 9926f36f-... and 940d0647-...): both reached us without an attached API key (bring_your_own_key false), so the custom ID got rejected. In Settings → Models under OpenAI API Key, double-check that the “Use OpenAI API key” toggle is actually enabled. Pasting the key and turning on the toggle are two separate steps, and Override Base URL only applies while the key is active. If it still fails, delete the key and add it again, then flip the toggle off and on once. This is the same scenario as in this thread: BYOK + Databricks AI Gateway — custom model names rejected ("Model name is not valid")

Failure B (request a2bcc770-... with k3): here the key was attached (byok=true), but the request hit a plan check that shouldn’t apply to a Pro account. This shouldn’t happen, and it’s not something in your setup. I’ve sent it to the team and we’re tracking it. I can’t share a timeline yet.

If Failure A still happens after checking the toggle, please retry and send a fresh request ID. If possible, do it with Privacy Mode turned off for that one request so we can confirm on our side. Let me know how it goes.

Update: Failure A fixed after Use OpenAI API Key ON + new chat.

Fresh short Agent chat with kimi-for-coding: success (request 828ef1b8-7ac8-4189-b70f-d46b08e6973f).

Long existing Agent chat with same model/BYOK: User Provided API Key Rate Limit Exceeded (request af71dc47-9b9e-4acf-bd42-0ed3d633588c) — likely large conversation context vs Allegro limits. Fresh chat still works after that (db0960e9-f212-4663-959e-3b1288b6ddbc).

Failure B (Free named-models gate on Pro) still tracked on your side as before.

Hey, glad Failure A is fixed. Yep, Use OpenAI API Key and Override Base URL only apply while that toggle is on, so starting a new chat after enabling it was the right move.

About User Provided API Key Rate Limit Exceeded on the long chat (af71dc47-...), your guess is correct. With BYOK, the request goes straight through your key to the provider endpoint, so you hit the provider limits, both per-request context or token limits and rate limits. A big existing chat sends the full accumulated context in one request, which is why it can exceed the limit, while a fresh chat starts with a small context and works. This is a provider-side limit (Kimi/Allegro), not Cursor. Options are to trim context, like start a new chat for a new task, run /summarize on long threads, or check your provider plan limits.

Failure B, the free named-models gate on Pro, is like I said, not something in your setup. We’re tracking it on our side, no timeline yet. I’ll reply in the thread when we have an update.