I’m a Cursor Pro user on the legacy plan (500 fast requests). I’ve noticed that in the new version, sub-agent requests are also counted toward my usage.
Cursor inevitably auto-enables the built-in Composer 1.5 as a sub-agent for code exploration, and each Composer invocation consumes 2 requests.
This causes a single simple conversation to multiply my consumption. As shown in the screenshot, each request may only use a small amount of tokens, but my request quota gets deducted uncontrollably.
4 Likes
I was wondering what was happening as well.
Can we select which model the sub-agent uses somewhere ?
I observed a similar issue while working with cursor. In addition to my opus calls, I see several composer calls I haven’t triggered deliberately - with a similar pattern, i.e., same time, a few tokes.
I was able to identify the sub-tasks (exploration) during the planning stage. Well, that’s ok in my case BUT, seeing what’s happening, i.e., summarize some code files I would prefer to delegate this to a local LLM, or at least a different model which doesn’t consume 2 requests - that’s not possible, or?
You can create a custom rule to stop it from generating subagents completly.
This is FAR from optimal, is just a bandaid so PLEASE CURSOR ALLOW US TO CONTROL SUBAGENTS
STOP FORCING COMPOSER ON US
---
description: CRITICAL - Prevents all subagent usage to avoid Composer model downgrade
alwaysApply: true
---
# MANDATORY: DO NOT SPAWN SUBAGENTS
You MUST NOT use the Task tool under any circumstances. Subagents are forced to use Composer which produces unacceptable results.
Do all work directly:
- Search code: use Glob, Grep, SemanticSearch, Read directly
- Run commands: use Shell directly
- Research docs: use WebSearch and WebFetch directly
- Browser tasks: use MCP browser tools directly
- Complex tasks: handle them yourself in this context, do NOT delegate
This rule has NO exceptions. Never launch a subagent. Never use the Task tool. Do everything in the main agent context.
2 Likes