Cursor CLI lists blocked Fable 5 as available and current on Enterprise

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On an Enterprise account, agent models lists multiple Fable 5 models as available and marks claude-fable-5-thinking-high as the current model.

Attempting to use that exact model fails immediately with:

ActionRequiredError: Model Blocked Please ask your admin to enable access to Fable 5.

The authenticated model catalog therefore presents an Enterprise-blocked model as available/current.

Steps to Reproduce

  1. Sign in to Cursor CLI with an Enterprise account where Fable 5 is blocked by Model Access Control.

  2. List Fable models:

   agent models | grep fable

  1. Observe that Fable variants are listed and claude-fable-5-thinking-high is marked (current).

  2. Attempt to use that model:

   agent --model claude-fable-5-thinking-high \
     --sandbox enabled \
     -p "Reply exactly OK. Do not use tools."
  1. Observe that Cursor rejects the model as blocked.

Full output:

$ agent models | grep fable
claude-fable-5-thinking-high - Fable 5 1M Thinking (NO ZDR) (current)
claude-fable-5-thinking-xhigh - Fable 5 1M Extra High Thinking (NO ZDR)
claude-fable-5-low - Fable 5 1M Low (NO ZDR)
claude-fable-5-medium - Fable 5 1M Medium (NO ZDR)
claude-fable-5-high - Fable 5 1M (NO ZDR)
claude-fable-5-xhigh - Fable 5 1M Extra High (NO ZDR)
claude-fable-5-max - Fable 5 1M Max (NO ZDR)
claude-fable-5-thinking-low - Fable 5 1M Low Thinking (NO ZDR)
claude-fable-5-thinking-medium - Fable 5 1M Medium Thinking (NO ZDR)
claude-fable-5-thinking-max - Fable 5 1M Max Thinking (NO ZDR)

$ agent --model claude-fable-5-thinking-high --sandbox enabled -p "Reply exactly OK. Do not use tools."
ActionRequiredError: Model Blocked Please ask your admin to enable access to Fable 5.

Exit status: 1

Expected Behavior

agent models should reflect effective Enterprise Model Access Control.

Models blocked for the authenticated account/team should either:

  1. be omitted from the available-model list; or
  2. be clearly marked unavailable/blocked.

A model that cannot run should not be marked (current).

Programmatic model discovery should likewise expose account-effective availability or policy metadata so SDK clients do not offer unusable models.

Operating System

MacOS

Version Information

About Cursor CLI

CLI Version         2026.07.16-899851b
Model               Fable 5 1M Thinking (NO ZDR)
Subscription Tier   Enterprise
OS                  darwin (arm64)
Terminal            ghostty
Shell               zsh

For AI issues: which model did you use?

Fable 5 1M Thinking (NO ZDR)
Model ID: claude-fable-5-thinking-high

For AI issues: add Request ID with privacy disabled

No request ID was emitted. Cursor rejected the blocked model before starting the request.

Additional Information

This appears inconsistent with Cursor documentation.

Cursor CLI documentation describes agent models as:

“List available models for this account”

The TypeScript SDK documentation instructs clients to use
Cursor.models.list() to discover valid model IDs. Its Known limitations
section does not state that discovery may include models blocked by effective
Enterprise policy:

Cursor’s Enterprise documentation also states that Enterprise teams can
control which models team members can use.

Requested resolution:

  • Make CLI and SDK model discovery reflect effective Enterprise policy; or
  • return explicit blocked/unavailable metadata; and
  • document any intentional broader-catalog behavior under SDK Known limitations.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @EmaCurFor, Thanks for the forum post!

You’ve found a real gap. Two things are going on:

The block itself: This isn’t the Model Access Control allowlist. Fable 5 models require your org to acknowledge the model’s data retention policy before use (the “NO ZDR” note in the list). Requests are rejected before they start, which is why no request ID was emitted. A team admin can enable Fable 5 by acknowledging that policy in the Cursor dashboard’s model settings.

The bug: The IDE hides these models until the policy is acknowledged, but agent models and SDK model discovery don’t apply the same filter yet. The (current) marker is also read from local CLI config without being validated. We’ve confirmed this and are working on making CLI and SDK discovery consistent with the IDE.

In the meantime, any model your org has enabled will work via agent --model <id>. Thanks again for flagging this.