To use Cloud Agents (background agents) we need to enable on-demand usage. Am I interpreting it right that this is purely a technical limitation and that subscription/included usage is consumed first? (I can’t find anything to the contrary online)
The reason I ask is because I would like to shift agent runs online. My codebase is already deeply integrated in cursor’s harness so I could do this immediately. My hesitation is that I can’t start a new agent session (fresh context) on an existing cursor VM. At the same time I’m using a ralph-inspired workflow that regularly resets context.
I can work around this, but before I go and spin up dozens of VMs to simulate a context reset I want to understand if this has cost implications or if it’s “just tokens, let’s go!”.
This is incorrect. Cloud Agents are not included in standard usage plans (e.g. Pro, Ultimate etc.) and are billed at API-pricing. On-demand usage must be enabled so that usage can be billed. Additionally, you’ll be asked to set a spending limit before launching your first cloud agent.
This is correct. There is no supported way to clear or reset the agent’s conversational context while remaining in the same VM.
My recommendation here is to start small, set limits, and see how you’re doing!
Interesting. In that case: What’s the lag of the usage/billing dashboard?
I’ve enabled on-demand billing to test cloud agents and debug the VM (and environment.json). The first ever run was billed at $0.21, which totally checks out because I ran Opus and had exceeded my included API usage long before that. By now I have spun up probably a dozen Cloud Agents with Composer 2 or Composer 2 Fast and, so far, my billing dashboard still shows $0.21 of on-demand usage.
My plan still has about 55% of included usage left for Composer models. I had assumed that this is why on-demand billing doesn’t tick up while I use cloud agents, but your answer sounds more like there being a delay/lag in usage reporting
Hi @FirefoxMetzger, just reviewing some old open threads, and I realized that I gave you an incorrect answer on this. Cloud agents actually do consume included API usage first before moving on to on-demand usage. My earlier response was incorrect in stating that they skipped the included usage and went straight to on-demand billing.
You do have to have on-demand billing enabled first regardless, so that part was correct. But the reason you weren’t seeing the bills for the cloud agent runs was most likely because you still had included usage which it was drawing against.
One small gotcha worth knowing: the spend-based rate limiter requires at least ~$2 of headroom under your hard limit before a Cloud Agent run will start, so make sure your hard limit isn’t set right at your current spend.
AND there is one more thing that you might be noticing. We currently have some promotional allocations so that the first few times you spin up a cloud agent environment, you’re actually not charged - these are free setup runs. I apologize for the long delay in getting back to you but I thought you might find this info helpful.
This thread looks stale, but I figured I would ask it here anyways. I find it hard to believe using cloud agents wouldn’t cost more than running them locally. VM’s consume compute and mem resources in a DC, thus one would expect to see a marginal increase in per token costs for VM overhead. Is there a marginal OH cost for cloud agents? And if not, is this a temporary product onboarding strategy, to get customers engaged, then you will roll out pricing increases later?
