When using Gloo as an OpenAI-compatible provider, Cursor rejects valid model IDs with:
AI Model not found: Model name is not valid: “”
This happens even though the same token + base URL + model IDs work via direct /ai/v2/chat/completions curl calls.
Steps to Reproduce
1 - Open Cursor Settings → Models
2 - Turn on OpenAI API Key and paste valid Gloo bearer token
3 - Turn on Override OpenAI Base URL and set https://platform.ai.gloo.com/ai/v2
4 - Ensure Anthropic key is off
5 - Add custom model (examples):
gloo-anthropic-claude-opus-4.7
gloo-anthropic-claude-opus-4.6
gloo-anthropic-claude-sonnet-4.6
gloo-openai-gpt-5.4
6 - Select model in chat and send a prompt
7 - Cursor returns model-not-valid error
Expected Behavior
Cursor should accept the model IDs and send requests successfully to the configured OpenAI-compatible base URL.
For AI issues: add Request ID with privacy disabled
I don’t have a Cursor request ID because request fails at model validation stage before successful completion call.
(If you have any request IDs from failed chat attempts, paste them here.)
Additional Information
Direct OpenAI-compatible API calls succeed with same token/base URL and same model IDs, e.g.:
POST https://platform.ai.gloo.com/ai/v2/chat/completions
with model gloo-anthropic-claude-opus-4.7 returns valid completion (“ok”).
This suggests Cursor-side validation/routing incompatibility.
On the first error (Model name is not valid: ""), it happens when Override OpenAI Base URL is enabled, but the OpenAI API Key toggle is off. You already fixed that, so we’re good there.
On the new error ('function' is required when type is 'function', Request ID ac946cd2-b099-48ea-a39d-3a32c3d844af), it looks like a mismatch in the tool-calling format between what Cursor sends and what Gloo expects on that endpoint.
A few things to try:
Rename the custom models to neutral names without claude or anthropic or gemini in the name, like gloo-opus-4.7, gloo-sonnet-4.6, gloo-gpt-5.4. Then on the Gloo side, route those names to the right underlying models.
Make sure the Anthropic API Key toggle in Cursor is off.
Test gloo-openai-gpt-5.4 separately using a neutral OpenAI-style name and see if it fails with the same tools error.
Let me know what you find, and I’ll pass the report to the team with your Request ID. I can’t share an ETA for a fix yet.
Thanks for the quick triage — here’s full context in one place.
1) “Model name is not valid: ""”
That lines up with Override OpenAI Base URL on while the OpenAI API Key toggle was off. I’ve fixed that by keeping the key toggle on when using Gloo. No further issues with the empty model name once that’s set correctly.
2) 'function' is required when type is 'function' (Agent / tools)
I hit this after the key toggle was correct:
Request ID:ac946cd2-b099-48ea-a39d-3a32c3d844af
Error indicates a tool-calling payload mismatch: what Cursor sends vs what Gloo validates on https://platform.ai.gloo.com/ai/v2/chat/completions (e.g. tools where type: "function" without the nested function: { name, parameters } shape Gloo expects).
Environment: Anthropic API Key toggle is off; only OpenAI override + Gloo bearer token.
Sanity check: Same token, same base URL, and real catalog IDs (e.g. gloo-anthropic-claude-opus-4.7, gloo-openai-gpt-5.4) work from plain curl to /ai/v2/chat/completions with a minimal body (no tools). So auth and model IDs look fine; the failure appears tied to Cursor’s request shape when tools/Agent are involved.
3) Neutral custom model names
I tried renaming the custom model entry to neutral strings (along the lines of gloo-opus-4.7). That did not behave like a harmless fallback — Cursor became unresponsive until I force-quit and removed that custom model.
Important detail: in Cursor, the custom model string is what gets sent as the API model field. Unless Gloo actually accepts those strings (documented aliases / routing), “neutral names” aren’t something I can safely invent client-side; it can wedge the app, not just return a typed error.
Ask
Please pass this to the team with the Request ID above, framed as BYOK + Gloo + Agent/tools schema compatibility (and optionally hardening when an unknown model is configured so the UI doesn’t hang).
I’m also talking to Gloo about tool definition compatibility on their side. If you need more traces, tell me what repro you want (e.g. chat-only vs Agent, specific model ID).
Thanks for the detailed write-up and the Request ID, it really helps.
Point by point:
Empty model name: yep, confirmed this was caused by having Override Base URL enabled while the OpenAI API Key toggle was off. Consider this one closed.
'function' is required when type is 'function': confirmed, this is a tools schema mismatch. Cursor sends tools in a flat shape (type/name/description/parameters at the top level), while Gloo, and some other OpenAI-compatible endpoints, expect a nested function: { name, parameters }. I filed this internally using your Request ID and the framing BYOK + OpenAI-compatible provider + Agent/tools schema. I can’t share an ETA yet.
UI hang on unknown model: logged separately as a hardening issue. Even if the provider returns an error for an unknown alias, the frontend shouldn’t hang until you have to force-quit. Agreed that inventing neutral model names client-side without provider support isn’t safe, so I’m removing that suggestion from the workaround.
While the issue is being tracked, I’ll post an update here once there’s a fix. If you need more repro data, like chat-only vs Agent on the same model ID, or the raw tools payload, tell me and I’ll suggest what to collect.
