Loss of model granularity in beforeSubmitPrompt hook following the latest Agent update

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Data regression in the beforeSubmitPrompt hook. The model field no longer returns the full descriptive model name (e.g., claude-4.6-opus-high-thinking) and instead only returns the general group name (e.g., claude-opus-4-6). This breaks logic dependent on specific model variations (reasoning levels, speed, etc.).

Steps to Reproduce

  1. Use the latest version of Cursor with the new Agent model management.
  2. Implement or use a script that monitors the beforeSubmitPrompt hook.
  3. Start a chat in Agent mode selecting a specific sub-model (e.g., a “high-thinking” variant).
  4. Inspect the model parameter received in the hook.
  5. Observe that it only shows the base group name, not the specific variant selected.

Expected Behavior

The model field should provide the full, specific model identifier as it did previously, or include a new metadata field containing sub-model details (like low/medium/high thinking or fast/max modes)

Operating System

Windows 10/11

Version Information

Version: 3.2.11 (system setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

For AI issues: which model did you use?

claude-4.6-opus-high-thinking

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey, great find! We’re still rolling out the parameterized model picker (why you see claude-opus-4-6 and not the former model identifier.

I’ve flagged this for the team.

Would love to hear more about how you use this information in your hooks! What kind of logic do you have that depends on effort/speed?

8

Thanks for the quick response and for flagging this with the team!

To give you more context, we use this information to implement a User Profile & Governance system. Specifically, our logic depends on it for two main reasons:

  1. Access Control: We enable or restrict specific model variants (like ‘high-thinking’, ‘fast’, or ‘max’) based on the user’s assigned profile. Without the granular identifier, we can’t verify if the selected parameter matches the user’s permissions.

  2. Quota Management & Dynamic Recommendations: We track consumption based on the specific service level used. We use the hook to trigger recommendations (e.g., suggesting a switch to a different model or effort level to stay within the user’s allocated daily or monthly budget).

11

Hey @apeiro!

We’re shipping a fix for this that should land in 3.4. Thanks again for flagging this.