Project child cloud agents do not share a prompt-cache prefix

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A Cursor Project is supposed to give child cloud agents a shared static
prefix (rules, skills, AGENTS.md). In practice each child starts cold.

On All Events, siblings launched minutes apart each carry a full
first-row uncached prompt. The only shared text in the first user
message is a short parent/task header. Skills and rules are loaded
with read_file after that header, so they cannot sit in a reusable
prompt-cache prefix.

Around 2026-09-21 17:30 UTC the default mix on these runs moved from
auto / cursor-grok-4.6-* to grok-4.7 and grok-4.7-high-fast
without a user model pin. In the same period Projects started
spawning many short-lived children instead of fewer long-lived
agents. A large share of those children have a single usage row:
one uncached write, no later turns that could reuse a warm cache.

Aggregate cache-hit rate can still look fine (~90%+) because later
turns inside one agent hit that agent’s own cache. The waste is
across siblings: the same project block is written N times.

The 2026-09-23 harness write-up posted by Cursor on X said cold misses should fall and
that variable setup had been moved behind cache breakpoints. Child
Project agents do not behave that way. And the quota efficiency got significantly worse, with the update that was supposed reduce spending.

Steps to Reproduce

  1. Open a Project with always-on rules / skills / AGENTS.md.
  2. Let the coordinator spawn several child cloud agents on one task.
  3. Export All Events for those children.
  4. Compare first-row uncached input on each child, and the start of
    each first user message.

Expected Behavior

The static project block is written once and read by siblings
(shared prompt_cache_key / x-grok-conv-id or equivalent).

Operating System

MacOS

Version Information

Version 26.924.22138

For AI issues: which model did you use?

Auto

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @Michael_Fischer, thanks for the report!

You’re right that agents within a Project don’t share a prompt cache. Each worker (and the coordinator) maintains its own cache, so every new worker pays the write cost once for its opening context.

One thing that may help when reading All Events: each worker’s row covers that worker’s entire run — usually dozens of model requests — rather than a single request. The cache reads on that row reflect the worker reusing its own context, and the opening context accounts for only a small share of the total (~1%).

Either way, this is great feedback as we continue improving the harness.

7

Hi Colin,

I think that is a bug not a feature. Especially in projects that is supposed to use lots of subagents.

Also, at the exact same day, that Cursor posted about reducing cost by 7%, you changed the defaults so projects suddenly started using short lived agents.

I’m honestly a bit ■■■■■■■ that this pulled 60% of my ultra monthly quota in 2 days until I figured it out and you/support still don’t acknowledge this is a serious issue. If cache cost can spiral to 93% of all cost in your harness that is not something you should accept.