SDK API key ListModels / CreateAgent only returns 4 models (no GPT/Claude) while CLI on same host shows full catalog

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Our Team plan Integrations API key suddenly only sees 4 models via the SDK catalog. GPT and Claude are gone and cannot be selected even by hardcoding model IDs.

This is not a UI filtering issue on our side: we call Cursor.models.list() and surface that list. The server rejects any other model at CreateAgent time.

Important: this does not look like the usual “regional restriction / CN IP” case that staff have been pointing people to:

  • Exit IP is US Bay Area (San Mateo, CA / AWS AS16509), not a restricted region.
  • On the same machine, agent --list-models still returns the full catalog (GPT, Claude, etc.).
  • Only the API key / SDK path is restricted.

Environment

  • Plan: Company Team Plan
  • API key: Integrations / User API Key (crsr_…), key name next_team
  • Account email associated with key: the linked email to my current account
  • Python package: cursor-sdk 0.1.8
  • Agent CLI (same host): 2026.07.23-e383d2b
  • Host egress (ipinfo): San Mateo CA, US

What we observe

1. SDK catalog (API key)

Cursor.models.list() →
  auto-smart
  grok-4.5
  composer-2.5
  composer-2

2. REST catalog (same API key)

GET https://api.cursor.com/v1/models
Authorization: Bearer $CURSOR_API_KEY
→ items: auto-smart, grok-4.5, composer-2.5

3. Agent CLI on the same host (user session, not the API key)

agent --list-models
→ full list including gpt-5.5-*, claude-opus-*, etc.

4. CreateAgent rejects non-catalog models
Hardcoding IDs that used to work fails immediately:

BadRequestError: invalid_argument: Cannot use this model: gpt-5.5.
Available models: auto-smart, grok-4.5, composer-2.5, composer-2.
Use Cursor.models.list() to discover valid selections.

Same rejection for claude-opus-4-8, gpt-5.4, CLI-style ids like gpt-5.5-high / claude-opus-4-8-thinking-high.

5. Models that still work
composer-2.5, grok-4.5, and auto-smart (with optimize_for) create and finish successfully.

Why we don’t think this is regional filtering

Forum answers for “only Composer/Grok/Kimi/GLM” usually cite provider regional restrictions based on request IP. That doesn’t fit here:

  • US Bay Area egress
  • Same host, same network: CLI full catalog vs SDK/API key 4-model catalog
  • Rejection message enumerates exactly those 4 IDs as the allowed set for this key

Impact

Our internal SDK-backed agent UI (solo chat model picker) can no longer offer GPT/Claude because the server catalog for this API key no longer includes them, and CreateAgent hard-rejects those IDs.

Happy to provide request IDs, timestamps, or a minimal repro script if useful.

Steps to Reproduce

  1. Export a Team Integrations API key as CURSOR_API_KEY.

  2. Run:

    from cursor_sdk import Cursor
print([m.id for m in Cursor.models.list()])

  3. Observe only auto-smart, grok-4.5, composer-2.5, composer-2.

  4. Try:

    from cursor_sdk import Agent, AgentOptions, LocalAgentOptions
Agent.create(AgentOptions(
    api_key=...,
    model="gpt-5.5",
    local=LocalAgentOptions(cwd="."),
))

  5. Get Cannot use this model: gpt-5.5. Available models: auto-smart, grok-4.5, composer-2.5, composer-2.

  6. On the same machine, run agent --list-models and observe GPT/Claude still listed.

Expected Behavior

For a Team plan API key on a US Bay Area egress IP, Cursor.models.list() / GET /v1/models should expose the same GPT/Claude models that the Team account can use in CLI/IDE (or at least document why the Integrations API key catalog is intentionally narrowed to Cursor-owned models + Router).

If this is intentional policy for API keys / SDK, please confirm:

  1. Is the SDK/crsr_ key catalog now intentionally limited to auto-smart / Composer / Grok?
  2. How can a Team admin restore GPT/Claude for Integrations API keys?
  3. Why does CLI on the same host still see the full list while the API key does not?

Operating System

Linux

Version Information

  • Plan: Company Team
  • API key: Integrations / User API Key (crsr_…), key name next_team
  • Account email associated with key: the email linked to this account
  • Python package: cursor-sdk 0.1.8
  • Agent CLI (same host): 2026.07.23-e383d2b
  • Host egress (ipinfo): San Mateo CA, US

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hi @Colin @mohitjain,

The same API key works for agent CLI but not for SDK endpoint. Is it related to any sdk serving updates? Thanks!

9

Hey!

Two things would help us localize where the catalog is getting narrowed:

  1. Bypass the SDK and hit REST directly. Run curl -H "Authorization: Bearer <KEY>" https://api.cursor.com/v1/models to confirm the 4-model list is coming from the API itself (not the SDK client). Then try creating an agent with gpt-5.5 hardcoded via the REST endpoint directly. Does the server accept it, or reject it? That tells us whether the limit is in the model catalog or in actual enforcement.
  2. How are GPT/Claude granted to your account - enabled team-wide, or switched on for specific users/groups by your admin? If they’re group- or user-scoped rather than team-wide, that’s the key detail here.

If you can grab a request ID from any of those calls, drop it in and I’ll trace it on our side.

10

Thanks for the reply!

This happened yesterday afternoon. Not sure it is a Cursor side enforcement or a team admin setup.

Confirmed via REST: GET https://api.cursor.com/v1/models returns exactly 4 models (auto-smart, default, grok-4.5, composer-2.5) — same with Bearer and Basic auth. So the narrowing is server-side, not the SDK client.

Same API key with agent --list-models still returns ~106 models including GPT-5.5 / Opus / Gemini.

Cloud POST /v1/agents is blocked for our team by Privacy/Storage mode (403 feature_unavailable) for both gpt-5.5 and composer-2.5, so we couldn’t use cloud REST to test model acceptance.

Local SDK: Agent.create(model="composer-2.5") works; Agent.create(model="gpt-5.5") is rejected with 400 invalid_argument: Cannot use this model: gpt-5.5. Available models: auto-smart, default, grok-4.5, composer-2.5, composer-2.

No x-request-id on these responses. IDs: apiKeyName=next_team, userId=298574373, successful composer run=run-4c704b77-559f-4ae0-9e9a-0fc45a44c4ac, gpt-5.5 reject ~2026-07-30T17:26:45Z. GPT/Claude are available to this user in IDE/CLI with the same key — restriction appears specific to the API/SDK catalog.

11

Hi @mohitjain ,

Do we support using AWS Bedrock Claude API key and Azure GPT API key to run certain models in Cursor SDK? If we can do that, it will be a good workaround.

12

Thanks for running those, that confirms the narrowing is on our side (the API-key catalog), not your setup. This isn’t intended behavior. We’ve let the team know and it’s something we’re tracking. I’ll post here when there’s an update.

Two quick answers:

Bedrock/Azure keys won’t help here. The SDK/Cloud Agents API isn’t a model-inference API, so it doesn’t take your own provider keys. Models come from your Cursor catalog (Cursor.models.list()), and BYOK is an IDE-only feature. See the Cursor APIs Overview and Python SDK docs.

To get GPT/Claude into the API-key catalog today, have an admin enable those models at the team baseline under Team Settings → Models (docs). The API-key catalog picks up team-level models, so that’s the lever that surfaces them. It widens access team-wide, so it’s your admins’ call.

On the 403 creating a cloud agent: that’s expected in privacy/storage-restricted mode, since cloud agents need storage enabled at the team level. The local SDK path works without it, so that’s your route once the catalog is sorted.

Let me know if the team-level enable does the trick.