Cloud Agent ignores selected model (Grok 4.5) and switched to Opus 4.8 without any notification

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Cloud Agent ignores model selection and defaults to Opus 4.8 across multiple flows, resulting in unexpected high token usage:

When selecting ‘grok 4.5’ during the initial setup and clicking “Setup Cloud Agents”, the session starts using Opus 4.8 without notification. Furthermore, there is no option to view or change the active model in the Cloud Agent interface for sessions created this way.

For the same session, i enabled plan mode via cursor desktop. Even after enabling Plan Mode for Cloud Agent in Cursor Desktop, explicitly selecting ‘grok 4.5’, and clicking “Build”, the system continues to execute using Opus 4.8.

Also, i have chosen Grok4.5 as the default model for cloud agents, so anyway it should not be using opus4.8 for any reason.

Steps to Reproduce

  1. Go to Cloud Agent setup and select ‘grok 4.5’ as the model.

  2. Click “Setup Cloud Agents” → Notice the session initiates using Opus 4.8 instead(via cheking the usage page)
    -This already shows the bug for ignore model selection-

  3. In Cursor Desktop, enable Plan Mode for Cloud Agent.

  4. Select ‘grok 4.5’ again and click “Build”.

  5. Observe that the execution still runs on Opus 4.8.(check via account’s ‘usage’ page)

Expected Behavior

Cloud Agent should honor the chosen model (‘grok 4.5’) during setup and plan mode’s execution, and clearly indicate what model it is using for build.

Screenshots / Screen Recordings

this is a recording to reproduce this problem

I did explicitly chosen Cursor Grok 4.5 High and it says building.

But in fact it is using opus4.8 without notifying me, since i it still displays grok4.5..

As you see, i cant edit/see what model is being used for cloud sessions.(the area below the input bar is not showing models)

Operating System

Windows 10/11

Version Information

Version: 3.12.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Selected Grok 4.5(both at start and at build stage for plan mode), but system executed with Opus 4.8

For AI issues: add Request ID with privacy disabled

bc-5a24c3cf-1bfd-4a7d-bfb2-5ef2bab36ad5

Additional Information

To reproduce, open cloud agent web, choose a repo, choose ‘Cursor Grok 4.5’, and click the green ‘Set Up Cloud Agents’ button, and check the usage page, you will see a big ‘Opus 4.8 High’ inside…(Already reproduced inside the video uploaded)

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @Haoxuan_Li Thanks for the post! This is intentional behavior, but we could do a better job of making it clear to you what’s happening. Right now, for cloud agent setup, we force the setup process to be hardcoded to specific models like Opus 4.8. We do offer free cloud agent setup (up to the first 5 times), so that the usage for setting up your first five cloud agent environments is free and not drawn from your account’s usage. After those 5 free setups are exhausted, usage draws normally from your account, which is what your video indicates here. And it is drawn as Opus 4.8 for the setup.

One more thing worth calling out from your video: it looks like the whole flow stayed inside that initial setup session, including when you turned on Plan Mode and pressed Build. A setup session stays tied to the setup model, so anything you keep running from within it continues on Opus 4.8 rather than the model shown in the picker, which is why your Grok 4.5 choice wasn’t applied even at the Build step. Once the environment has finished setting up, starting a new cloud agent on that environment will run on your selected model, so choosing Grok 4.5 for a fresh agent (rather than continuing inside the setup session) will behave the way you expect. We know this isn’t obvious in the current UI, and we’re working to improve this flow and clarify model usage here.

Hi Kevin,

Thanks for the quick response and detailed breakdown!

While I understand the technical reason behind locking setup sessions to Opus 4.8, calling it purely a UI issue feels like it misses the core impact on the user side. From a user’s perspective, actively selecting Cursor Grok 4.5 multiple times (especially during Plan Mode and before clicking “Build”) creates a clear expectation of what model is handling the execution. When the backend quietly overrides that choice while the front-end confirms Grok, it becomes an unintended token drain rather than just a minor UI display glitch.

Because the system didn’t honor or visually reflect the model switch, I unknowingly burned through a significant amount of high-tier Opus 4.8 tokens that I had intentionally tried to avoid using.

I appreciate that the team is working on clarifying this flow for the future. In the meantime, given that these tokens were spent entirely due to the backend silently overriding the selected model, is there any chance support could take a look at the usage racked up from this specific session?

Thanks again for looking into this!:melting_face: :broken_heart:

Hi @Haoxuan_Li,

You’re right, and we’re going to work to improve this!

On this specific session: I looked into your account credit, but because your account is on the student plan, usage credits aren’t something we’re able to issue on it. Sorry about that!

To avoid this going forward: the Opus pinning only applies to the setup step. Once the environment finishes setting up, start a new cloud agent on it at https://cursor.com/agents (rather than continuing inside the setup session) and pick Grok 4.5 there. That agent runs on the model you choose.

No problem at all! Of course it’s fine—Cursor has already given me so much value through the student plan, so I really appreciate everything the team does.

Thanks again for looking into this, and hopefully, this setup/model lock issue can be fixed soon so others don’t get caught off guard by it!