Cursor CLI secretly switched to max mode and burnt up the majority of my monthly allowance

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Cursor cli randomly switched to max mode on opus 4.6 without any indictation in the terminal UI and burnt up the majority of my monthly allowance. I would not be using opus 4.6 if I wanted max mode enabled. This was in the same session as I was previously using it without max mode.

Steps to Reproduce

No idea why this has happened but also see reports of model switching. Whether you are in max mode or not is extremely unclear as max mode was not shown but I am being billed.

Expected Behavior

I should not be selected for max mode when I previously explicitly disabled it

Operating System

MacOS

Version Information

CLI Version 2026.07.08-0c04a8a
Model Opus 4.6 200K High
Subscription Tier Pro
OS darwin (arm64)
Terminal apple-terminal
Shell zsh

For AI issues: which model did you use?

opus 4.6

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report and the screenshot. I can see the spend for claude-4.6-opus-high-thinking with the MAX tag on July 11.

Looks like Max Mode was still on, maybe from a previous session, so requests were billed as token-based and the cost ended up higher than expected. In older CLI builds, the Max Mode indicator was easy to miss.

What to do now:

  1. Run /max-mode in the CLI to turn it off, and check that the footer no longer shows “· MAX”.
  2. Update the CLI to the latest version when the update is available, then run /max-mode again just to be safe.

For a refund for the used limit, it’s best to email [email protected] so they can review your specific usage.

Let me know if after /max-mode the footer still shows MAX.

Hi @deanrie, specifically the bug was that this was a continuation of my previous session which did not have max enabled, no changes were made to my model selection or max mode at all and the ‘MAX’ indicator was not displayed in the terminal yet my billing showed it was charged as max requests.

I have also noticed that it can be unclear whether max mode is enabled when switching between models in the terminal or whether a model requires max. Sometimes max can be disabled for a model that requires it but when a request is made it will bypass the ‘this model requires max warning’ and silently switches it on anyway to complete the request, this is unexpected for the user.

Thanks for the extra details, that helps confirm what’s going on.

What you’re describing matches a known bug on our side. In the CLI, Max Mode could get stuck in the on state and carry over globally between sessions without you doing anything. On older builds, the · MAX indicator might not show up, so requests were sent as token-based even though nothing looked different.

The second case, where max is off for the model but the warning “this model requires max” gets silently bypassed and max turns on by itself, is part of the same issue (auto-enable). Both cases are fixed by the same change.

The fix is already merged and will ship in one of the next CLI updates. One important note: it won’t migrate configs that are already stuck, so:

  1. Run /max-mode now to turn it off, then check the footer no longer shows · MAX.
  2. After you update the CLI, run /max-mode one more time just to be safe and clear the old state.

For a refund for the used limit, like I mentioned earlier, the best option is to email [email protected] so they can check your exact usage history.

Let me know if the footer still shows MAX after you run /max-mode.