A prompted agent costs roughly what you would expect: you asked N times, you pay for N interactions, and your intuition about your own habits is a reasonable guide to next month's bill.
A subscribed agent breaks that intuition completely. Cursor's Cloud Agent Subscriptions, shipped 19 August, wake on pull request activity, Slack threads or scheduled tasks with no prompt from you. GitHub's Copilot agent reaching Slack and Teams two days later adds another trigger nobody personally initiates: any teammate's @GitHub mention. The number of times work happens is no longer something you control by habit.
Why the old mental model breaks
Your intuition about cost was built on a simple relationship: more of your own effort meant more cost. An always-on agent decouples those completely. It can run more in a week where you personally did less, because the trigger volume — pull request comments, bot activity, scheduled checks — has nothing to do with how much you typed.
That decoupling is the entire point of the feature, and it is also the entire reason the old habit of estimating cost from memory stops working.
The variables that actually drive an event-driven bill
Four things determine cost here, and none of them is "how often did I use it":
- Trigger frequency — how often the subscribed event actually fires. A quiet repository and a busy one with the same subscription produce wildly different costs
- Task length per trigger — a subscribed agent fixing a one-line CI failure costs little; the same subscription responding to "make all tests pass" can run for hours
- Context size per run — how much of the repository the agent has to load each time it wakes, which per-token pricing (as introduced with Kimi K3 on 6 August) charges for directly
- Cache behaviour — whether repeated wake-ups on the same repository benefit from cached context or reconstruct it each time, which is exactly what the per-model token report GitHub shipped on 11 August is built to reveal
How to estimate before you commit, not after
Do not turn on a subscription for your most active repository first. Pick a moderately active one, enable it for a single week, and pull the per-model token report at the end of that week rather than at the end of the month.
That week gives you an actual trigger frequency for that repository, which is the number nobody can estimate from habit and the number the rest of the model depends on. Multiply cautiously rather than confidently — a quiet week is not evidence of a quiet month.
Build a circuit-breaker, because you cannot budget by habit here
For a prompted tool, a spend alert is a nice-to-have because you would probably notice unusual spend yourself. For an event-driven one, it is closer to necessary, because the entire premise is that the work happens without anyone watching it start.
Set the alert at a level that would surprise you if hit within the first week of a new subscription, not at a level calibrated to last month's prompted usage — last month's usage is not a valid baseline for a mechanism that did not exist yet.
Match the entry point to the cost tolerance
Not every trigger deserves the same trust, and that maps directly onto cost exposure. A subscription on a pull request the agent itself opened has a bounded scope — it knows what it is trying to finish. A subscription that reacts to any bot comment on any pull request is a much less bounded trigger, and it deserves a tighter budget ceiling specifically because you cannot predict how often it will fire.