Cloud Agent timers / “keep listening” behave like a serious product bug

Ideas Feedback
, ,
1

What I expected: a Cloud Agent watching QA / PR / Jira would work like Grok Bot event listeners—wake only when something happens, with a thin context.

What actually happens: a 5-minute timer fully wakes the same long-running coding agent, reloads the entire coding transcript and tool history (mostly Cache Read), and bills it even when there is nothing new.

Measured on my account (usage CSV, ~2026-09-19 to 09-25):

  • Agent bc-d0f4f064-d207-5360-a35e-fea2a83905d9 (“new admin requirements”, RD-89): I sent only 3 human messages; timer rd89-rebate-qa-5m woke it ~474 times; ~476 steps and ~317M tokens (~53% of that period’s Cloud usage). ~99% of wakes concluded “No new QA / unchanged”, yet each wake still averaged ~600k+ total tokens (~95% Cache Read).
  • Agent bc-960d4ef7-e982-54ab-880b-98ac232d67a6 (RD-135): ~6 human messages, ~322 timer wakes, ~144M tokens.
  • Same account, Grok Bot automation averages ~48k tokens per call; these Cloud Agent calls average ~660k—about 14× per wake. The bot also watches Jira / Slack / GitHub and does more real work, but it is event-driven with thin context. Cloud timers use the fattest coding session as a heartbeat poller.

Core issues:

  1. Listening / polling must not share the same executor and history as a long-running Cloud coding session.
  2. Usage UI barely shows that idle timers are burning quota, so it looks like model price or “I used it a few times.”
  3. Cloud Agents can hang a 5-minute QA loop with no hard stop, no cost warning, and no push toward event subscriptions.

Please fix:

  • Do not reload the full coding transcript on timer/poll wakes; or block long polling on already-fat agents.
  • Route QA watching through PR comment / Jira status events, not “wake the whole agent every 5 minutes.”
  • On the Usage page, label timer/automation wakes and cache share clearly, and warn when idle burns look abnormal.

This is not a single miscounted line item. It is a wrong product abstraction, and for users it is effectively a severe billing / UX bug.

9

Hey @chiayu0816, thanks for the detailed write-up and the numbers.

You’re right that a recurring timer is the wrong tool for watching QA. Timers wake the agent on a fixed schedule whether or not anything changed, and each wake runs the full conversation.

Event subscriptions are the intended way to do this. The agent subscribes, ends its turn, and uses no tokens while it waits. It only wakes when a matching event arrives. Today agents can subscribe to GitHub (PR comments, reviews and CI results), Slack (thread replies and channel messages) and Linear (issue status changes and comments). You can ask the agent to “watch this PR for review comments” or invoke the /subscribe skill. More details: Capabilities | Cursor Docs

Jira isn’t one of the supported event sources yet. In the meantime, one option is a Jira automation rule that calls a Cursor Automation webhook trigger when an issue changes status. That starts a fresh agent per change instead of polling: Automations | Cursor Docs