The agent billing problem.

Every agent sandbox I have seen running on a provisioned VM has the same cost profile: a small amount of real work, then long stretches where the only thing happening is a websocket waiting for tokens. The machine keeps billing through the wait because that is how provisioned compute works. You rented an hour, you get an hour, whether the agent used it or not.

Picture an agent investigating a spike in checkout errors. It queries logs across services through an MCP server, writes and runs a reproduction script, tests a fix, then opens a pull request for a teammate to review. The CPU-heavy parts, the log queries, the script runs, the test suite, each demand substantial compute for a few seconds. Between them, the agent waits on model responses, tool results, or a human approving the PR. During those waits it consumes little or no CPU at all. But its context, files, and working state have to stay available the whole time, so it can pick back up exactly where it left off.

On a traditional VM you have two bad options. Keep spare machines warm so agents start fast, and pay for idle capacity all week. Or provision on demand, and eat minutes of environment setup as part of every agent's first answer. Billing for provisioned CPU continues while the agent waits, which is the tax that never shows up on anyone's FinOps review because it looks like ordinary compute spend.

The billing basis is the change

DigitalOcean's Managed Agents launch this week meters CPU on actual consumption, not allocation. When an agent is waiting on the model and using no CPU, its CPU charge falls to zero. Their published rate card:

Run their worked example: a session with two vCPUs averaging 25 percent utilization and a measured memory peak of 4 GB across an hour costs $0.060 in compute charges. The same allocated capacity, billed provisioned for the full hour, costs $0.126. The active-CPU model roughly halves the compute line for a typical agent session, and the more bursty the workload, the larger the gap.

Pausing goes further. Snapshotting the working state stops CPU and memory charges entirely while storage stays billable, and the benchmark they publish shows resume to readiness in 305 milliseconds, with the resumed session answering in 2.43 seconds versus 2.47 seconds for one that never paused. That delta is small enough that pausing between turns stops being a responsiveness tax and becomes pure savings.

Two things about that benchmark table are worth noting. First, they publish the row where they lose: 189 milliseconds for a command round trip inside a running session versus 79 for Sprites, and they say plainly that the 110 millisecond overhead is the cost of routing exec through their edge and control plane for authentication and audit. Disclosing the slow lane in a launch post is rare. Second, they footnote that the Sprites resume figures are derived, not measured, because Sprites has no resume API, so the comparison is not apples to apples there.

The part nobody prices

There is a second cost lane in agent work that rarely appears in the budget conversation: credentials. Most agent sandbox setups hand the API key to the environment, which means it sits in the same filesystem where the agent executes untrusted code. One leaked log line, one overly permissive tool, and you pay for the breach twice, the incident response and the reissuance across every integration.

Their Action Gateway brokers credentials at execution time, the key never reaches the model or the sandbox, and when a tool needs mid-workflow authorization it hands the agent a sign-in link and resumes the call once the human approves. That is the security side of the same FinOps problem: the cheapest credential is the one that never enters the environment you are paying to secure.

What to check on Monday

1. 01
   Measure your agent idle ratio. If your sandboxes average under 50 percent CPU utilization, provisioned billing is leaving money on the table. The ratio is the whole argument; the platform is just one way to act on it.
2. 02
   Pause, don't kill. Anything that snapshots working state and resumes in a few hundred milliseconds makes pausing between turns rational. If your current stack can't resume cheaply, that is your migration criterion, not the vendor's marketing.
3. 03
   Keep keys out of sandboxes. Whatever runtime you standardize on, credential brokering at execution time should be a selection requirement. The exec-latency overhead for doing it properly is a rounding error next to one leaked key.

What I would not carry from the post: the "16,000+ tools" catalog count, a number with no production evidence behind it, and the "one AI-native stack to power your intelligence" headline, which is the vendor telling you what the story should be. The billing basis, the resume economics, and the credential model are the parts a real cost center can use. The rest is launch-day packaging for a product that is still in public preview, with its own benchmark admitting the runtime is behind the specialists on the one path every agent exercises constantly.