Has anyone noticed significantly higher token counts per Grok 4.6 XHigh Fast agent run since late August?

Support Bug Reports
,
1

Hi everyone,

I’m trying to determine whether anyone else has noticed a change in the token behavior of cursor-grok-4.6-xhigh-fast since late August.

This is specifically about raw token counts per agent run

I use Cursor for repeated evaluation and optimization work on the same repositories and pipeline, so my workload is relatively consistent.

What caught my attention is the difference between runs only a few days apart.

On August 31, cursor-grok-4.6-xhigh-fast runs in my usage history commonly showed values such as:

  • 73K
  • 130K
  • 298K
  • 593K
  • 1M
  • 1.6M
  • 2.2M tokens

On September 4, using the same model and similar tasks in the same repositories, I’m seeing many runs around:

  • 6.5M
  • 8.6M
  • 18M
  • 7.5M
  • 13.4M
  • 7.4M
  • 12.5M
  • 15.1M tokens

Obviously individual agent runs can vary significantly, so I’m not claiming these individual examples prove an issue by themselves.

However, the difference has been large and consistent enough that I’m wondering whether something changed recently in how Grok 4.6 XHigh Fast handles or reports context.

Has anyone else doing long-running agent/evaluation workloads noticed this?

In particular, I’m curious whether there have been changes related to:

  • context accumulation between tool calls
  • context reuse/caching
  • agent iteration behavior
  • token reporting/accounting
  • changes to the Grok 4.6 XHigh Fast implementation

Again, I’m specifically interested in the **technical token behavior

Where does the bug appear (feature/product)?**
:check_box_with_check: Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)

Describe the Bug

cursor-grok-4.6-xhigh-fast appears to be reporting/processing significantly higher raw token counts per agent run compared with only a few days earlier, despite using the same model on the same repositories for comparable evaluation and optimization tasks.

This report is specifically about the change in raw token consumption per agent run, not subscription pricing or a billing dispute.

On August 31, typical runs visible in my usage history were in the hundreds of thousands to low single-digit millions of tokens.

On September 4, many comparable runs using the exact same cursor-grok-4.6-xhigh-fast model are showing approximately 6M–18M tokens per run.

Steps to Reproduce

  1. Open an existing repository that has previously been used extensively with cursor-grok-4.6-xhigh-fast.
  2. Run long-running agent tasks such as repeated evaluation, debugging and optimization work.
  3. Check the raw token count for the completed requests in the Cursor usage dashboard.
  4. Compare recent runs with equivalent runs from late August using the same model and repository.

Expected Behavior

Some variation between agent runs is obviously expected. However, for comparable workloads using the same model and repository, I would not expect a persistent order-of-magnitude increase in raw token processing without a corresponding major change in the task or context.

Actual Behavior

My August 31 history contains cursor-grok-4.6-xhigh-fast runs such as:

73K, 130K, 298K, 593K, 1M, 1.6M and 2.2M tokens.

On September 4, I am seeing runs such as:

6.5M, 8.6M, 18M, 7.5M, 13.4M, 7.4M, 12.5M and 15.1M tokens.

The difference is large enough that I wanted to report it in case something changed in context accumulation, caching/context reuse, agent iteration behavior, tool-call accounting, or token reporting for Grok 4.6 XHigh Fast.

Additional Context

I have screenshots of the usage history from both periods and can provide additional examples or usage exports if useful for reproducing/investigating this.

I’d also be interested to know if other users running long-lived Grok 4.6 agent workloads have observed the same behavior.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey @eXBro,

I looked at the runs behind those figures and nothing has changed in how Grok 4.6 XHigh Fast builds context, caches, or reports tokens. The token count shown for an agent run is the total across every model call in that run: each tool call the agent makes is another call to the model that re-reads the whole conversation (mostly from cache), so tokens per run is roughly (number of tool calls) x (conversation size).

That second factor is what moved. Your Sep 4 runs made between 45 and 128 tool calls each (the 18M one ran for almost an hour with 128 calls), while the runs you listed from Aug 31 came from a chat where turns made 1 to 14 calls. The conversation size per call was about the same on both days (roughly 145k tokens, with 96 to 97 percent of it served from cache), and the fleet-wide averages for this model are unchanged over the same period, so the difference is how long each run iterated, not the model or the accounting.

If you want the per-run numbers to come down, the biggest lever is conversation size: the long-running chat you have been using since late August carries about 130 to 200k tokens into every call, so starting a fresh chat (or asking the agent to summarize and continue in a new one) cuts every call proportionally. Splitting very long autonomous runs into smaller asks also keeps individual runs from stacking up 100+ calls.

8

Thanks Colin, this explains the raw token numbers very well, especially the 18M run with 128 calls × ~145k context.

The remaining part I’m trying to understand is what caused the number of calls per run to change so dramatically.

If the context size per call was roughly the same (~145k) and the model/accounting behavior was unchanged, my Aug 31 runs making 1–14 calls versus Sep 4 runs making 45–128 calls seems to be the actual source of the increase.

What still concerns me is the practical impact: despite doing the same recurring evaluation and optimization work on the same repositories, my Ultra usage lasted almost the entire August billing cycle (around 25 working days). In the current cycle, I’m already over 50% of my included usage after only 4 days. So even if the accounting hasn’t changed, the effective amount of work I can get from the plan has changed dramatically. As additional notice in august i even worked with 3-4 agent same time on different hard tasks repo´s during now i am slowed down to just one and the same eval process run with just 1 agent.

Since these are the same repositories and the same recurring workflow, even less than before since i stopped the other 3 workflows, do you see anything in the run data that explains why the agent started iterating 3–10x more per run?

For example, did the Sep 4 runs simply involve substantially more tool work, retries or edits, or was there a change in how the tasks were being decomposed by the agent?

I understand now why 128 calls produce ~18M tokens. I’m mainly interested in understanding why comparable tasks went from up to ~14 calls to as many as 128.

12

Hey @eXBro!

I can’t speak to the exact details of your runs.

What I would try, in order of impact:

  1. In the model picker, set Grok 4.6 effort to High (the default) or Medium instead of XHigh. Reserve XHigh for the hardest tasks.
  2. Consider turning off Fast for long unattended runs. Fast is priced at exactly twice the standard rate per token, so it halves cost when latency does not matter.
  3. Start a fresh chat for each run rather than continuing long-lived ones, so each model call carries less context.