Task accepts Grok 4.5 Low Fast but executes Composer 2.5 (IDE Agent, Agent Window, Cloud Agent investigation)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

I investigated how Cursor routes custom Task subagents when requesting Cursor Grok 4.5 Low Fast.

Across multiple environments, the Task accepted the requested model, but the actual execution model recorded in Usage did not always match.

This looks like either:

  • a model routing bug
  • an undocumented fallback
  • or intended behavior that is currently unclear.

Environment

Cursor Version

Version: 3.13.25 (Universal)
Commit: 31e8d61c448c7472e371505838a0fe34083dad50
Stable
macOS Sequoia 15.3.2
Apple M4 Pro
24 GB RAM
Privacy Mode: ON
Plan: Pro ($20)
BYOK: OFF

Custom Agent

The custom probe agent was configured through Cursor’s Agent UI.

Frontmatter:

---
name: grok45-low-fast-model-probe
model: grok-4.5[effort=low,fast=true]
description: Minimal read-only probe.
---

The Task itself requested:

cursor-grok-4.5-low-fast

This exact configuration was created through Cursor’s Agent UI.

Test 1

IDE Agent → Task

Expected

Parent

Cursor Grok 4.5 High Fast

↓

Child

Cursor Grok 4.5 Low Fast

Actual Usage

Parent

cursor-grok-4.5-high-fast

Child

composer-2.5

Task completed successfully.

No errors.

Request ID

51e37959-39d6-4a2a-836c-57c73124bc02

See bug001.jpg

The Task accepted the requested model, but the corresponding child execution was recorded as Composer 2.5.

Test 2

Agent Window → Task

Same configuration.

Actual Usage

Parent

cursor-grok-4.5-high-fast

Child

composer-2.5

Again the Task accepted the requested model without error.

See bug002.jpg

The same behavior occurred when launching the Task from Agent Window.

Test 3

Agent Window (direct execution)

No Task.

No subagent.

I selected:

Cursor Grok 4.5 Low Fast

Usage correctly recorded

cursor-grok-4.5-low-fast

So the model itself is available on my account.

See bug003.jpg

This control test confirms that Grok 4.5 Low Fast works correctly when executed directly.

Test 4

Cloud Agent → Task

Cloud Agent Copy ID

bc-c9e14f13-3137-4e61-a12d-7383575fff00

The Task completed successfully.

Usage only showed

cursor-grok-4.5-high-fast

There was no separate child Usage entry, so I could not verify which model the child actually used.

Conclusion

Current observations:

Scenario Result
IDE Agent → Task Child became Composer 2.5
Agent Window → Task Child became Composer 2.5
Agent Window direct Correctly used Grok Low Fast
Cloud Agent → Task Child Usage not visible

The Task accepted:

cursor-grok-4.5-low-fast

but Usage later recorded:

composer-2.5

The direct Agent Window test confirms that Cursor Grok 4.5 Low Fast is available and functions correctly, suggesting that the model mismatch occurs specifically when launching a custom Task subagent.

I’m trying to determine whether this is:

  • expected model routing behavior,
  • an undocumented fallback,
  • or a model-routing bug.

Any clarification from the Cursor team would be greatly appreciated.

Unlike the IDE Agent and Agent Window tests, Cloud Agent did not expose a separate child Usage entry, so I could not determine whether the requested child model was honored.

Steps to Reproduce

  1. Create a custom agent through Cursor’s Agent UI with the following configuration:

name: grok45-low-fast-model-probe
model: grok-4.5[effort=low,fast=true]
description: Minimal read-only model-routing probe.

  1. In Cursor IDE, select Cursor Grok 4.5 High Fast as the parent model.

  2. Start the custom agent through the Task tool with:

subagent_type: grok45-low-fast-model-probe
model: cursor-grok-4.5-low-fast

  1. Run only a minimal read-only task:

pwd
git branch --show-current
git rev-parse --short HEAD
test -f webhome/shop.php

  1. Confirm that the Task accepts cursor-grok-4.5-low-fast and completes successfully without an error.

  2. Open Plan & Usage and inspect the matching execution time.

  3. Observe that the child execution is recorded as composer-2.5 rather than cursor-grok-4.5-low-fast.

  4. Repeat the same parent → Task child test from Agent Window. The child is again recorded as composer-2.5.

  5. As a control test, select Cursor Grok 4.5 Low Fast directly in Agent Window and run the same minimal task without Task or subagents.

  6. Confirm that direct execution is correctly recorded as cursor-grok-4.5-low-fast.

Expected Behavior

When the Task tool accepts the requested model slug:

cursor-grok-4.5-low-fast

the child should run using Cursor Grok 4.5 Low Fast.

If that model cannot be used for a Task subagent, Cursor should return an explicit model-selection error instead of silently routing the child to Composer 2.5.

The requested model, actual execution model, and Usage record should be consistent.

Screenshots / Screen Recordings

bug001.jpgbug002.jpgbug003.jpg

Operating System

MacOS

Version Information

Cursor Version: 3.13.25 (Universal)
VS Code Extension API: 1.128.0
Commit: 31e8d61c448c7472e371505838a0fe34083dad50
Date: 2026-07-28T06:17:45.069Z
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

Device: MacBook Pro 14-inch, November 2024
Chip: Apple M4 Pro
Memory: 24 GB
Architecture: Apple Silicon / arm64
macOS: Sequoia 15.3.2

For AI issues: which model did you use?

Parent model:
Cursor Grok 4.5 High Fast
Effort: High
Fast: Enabled

Requested Task child model:
Cursor Grok 4.5 Low Fast
Task model slug: cursor-grok-4.5-low-fast

Custom-agent UI/frontmatter model:
grok-4.5[effort=low,fast=true]

Actual Usage result for the Task child:
composer-2.5

Control test:
Direct Agent Window execution correctly used cursor-grok-4.5-low-fast.

For AI issues: add Request ID with privacy disabled

Privacy Mode was enabled during the reproductions.

IDE Agent Request ID:
51e37959-39d6-4a2a-836c-57c73124bc02

IDE Task child agent ID:
024aee41-ad9d-4365-be64-1f197ce3c9fc

Agent Window Copy ID:
bc-c9e14f13-3137-4e61-a12d-7383575fff00

Cloud Agent Task child agent ID:
b03d6249-56a2-441e-a803-5402ce0df9cf

Additional Information

Plan: Pro ($20/month)
Pricing: Current usage-based plan
Privacy Mode: Enabled
BYOK: Off

The issue was reproduced through both Cursor IDE Agent and Agent Window.

IDE Agent → Task child:

  • Requested child: cursor-grok-4.5-low-fast
  • Usage result: composer-2.5

Agent Window → Task child:

  • Requested child: cursor-grok-4.5-low-fast
  • Usage result: composer-2.5

Agent Window direct execution:

  • Selected model: Cursor Grok 4.5 Low Fast
  • Usage result: cursor-grok-4.5-low-fast

This control test indicates that Grok 4.5 Low Fast is available on the account and works when executed directly. The mismatch appears specifically in the Task-subagent routing path.

Cloud Agent → Task child:

  • Task accepted cursor-grok-4.5-low-fast
  • Usage displayed only one aggregated cursor-grok-4.5-high-fast row
  • The child model could not be independently verified from Usage

The Task model value grok-4.5[effort=low,fast=true] was rejected as an invalid Task model selection.

The Task model slug cursor-grok-4.5-low-fast was accepted, but the execution was recorded as composer-2.5.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the super detailed write-up with the tests and the request ID. That really helps.

Your interpretation is correct. This is not intended behavior. When a Task uses cursor-grok-4.5-low-fast, the child shouldn’t silently switch to composer-2.5. In this case we expect a clear model selection error, like with the bracket syntax. I shared this with the team.

Why this happens: the list of models available to a Task subagent mirrors what’s selected in the model picker, one option per family. Your picker was set to Grok 4.5 High Fast, so Low Fast isn’t in that list. Because of that, a slug with the -fast suffix falls back to Composer fast instead of throwing an error. This is the same limitation discussed here: Cannot spawn agents of a different thinking level

Two working workarounds:

  • Before running the Task, set Grok 4.5 in the picker to Low + Fast. Then cursor-grok-4.5-low-fast will show up in the subagent list and routing should work correctly.
  • Or don’t set model in the Task call at all. Then it will use the model from the custom agent frontmatter grok-4.5[effort=low,fast=true]. This routes correctly. Important: the Task model arg overrides frontmatter, which is why frontmatter didn’t apply in Test 1/2.

For Cloud Agent (Test 4): the child doesn’t show as a separate line in Usage, so you can’t verify the child model via Usage right now. That’s a display limitation, not a sign the child ran with the wrong model.

I can’t share a timeline yet, but if I get an update I’ll post it in the thread. Let me know if either workaround helped.

7

Thanks for the detailed explanation. I tested both workarounds.

Workaround 1: omit the Task model argument

Configuration:

Parent picker:
Cursor Grok 4.5 High Fast

Custom agent frontmatter:
grok-4.5[effort=low,fast=true]

Task model argument:
omitted

Request ID:

f6af786d-30ee-4f2e-aa24-27f2b6fd461f

Usage showed two entries, both as:

cursor-grok-4.5-high-fast

So in my environment, omitting the Task model argument did not appear to use the custom agent frontmatter model.

Instead, the child appeared to inherit the parent picker model.

Observed behavior:

Parent High Fast
+ Task model omitted
+ Child frontmatter Low Fast
→ Parent High Fast
→ Child High Fast

This avoided the Composer fallback, but it did not route the child to Low Fast.

Workaround 2: set the picker to Low + Fast and explicitly request Low Fast

Configuration:

Parent picker:
Cursor Grok 4.5 Low Fast

Custom agent frontmatter:
grok-4.5[effort=low,fast=true]

Task model argument:
cursor-grok-4.5-low-fast

Request ID:

902e536a-6ef9-4c32-adf1-ff506d9b1b82

Usage showed two entries, both as:

cursor-grok-4.5-low-fast

So this workaround succeeded.

Observed behavior:

Parent Low Fast
+ Task model explicitly set to Low Fast
→ Parent Low Fast
→ Child Low Fast

Current interpretation

Based on these two tests, the behavior in my environment appears to be:

Task model omitted
→ child inherits the parent picker model

Task model explicitly set
→ works only when that variant is also selected in the parent model picker

So the first workaround did not use the custom agent frontmatter as expected, while the second workaround worked correctly.

Thanks again for sharing this with the team.