Skip to main contentClaim $5 in free credit — one-time, per account. Claim $5 free
Krova CloudKrova Cloud
AI Code Sandboxing

Agent Compute Cost: What One Task Really Costs

Per-month bills hide the unit that matters: one agent task. We price a realistic task on per-second sandbox billing and show where the money actually goes.

5 min read
Share
Agent Compute Cost: What One Task Really Costs

Agent Compute Cost: What One Task Really Costs

Agent compute cost per task, not per month, is the number a team can actually manage. A monthly invoice tells you what happened after the money is gone. A per-task number tells you whether the next automation is worth writing. This guide builds that number from public per-second rate cards and a realistic agent loop, then shows which line items dominate it.

Why the monthly bill lies

Agent workloads are bursty by nature. An environment lives for minutes, idles while the model thinks, spikes during test runs, then dies. Monthly VM pricing averages all of that into one number with no feedback loop. Per-second sandbox billing, which E2B, Modal and Fly Sprites all use in some form, at least matches the shape of the work. The management unit still has to be the task, because the task is what a product owner approves.

Anatomy of one task

We priced one representative task on 22 October 2026 against three public rate cards: clone a mid-size repo, install dependencies, run the test suite, let the agent iterate three times, then tear down. Wall clock was forty minutes; busy CPU time was closer to nine. On E2B's published rates of $0.0504 per vCPU-hour and $0.0162 per GiB-hour, a 2 vCPU and 4 GiB box bills about $0.17 for a fully busy hour, according to Developers Digest.

Our forty-minute loop with idle time included lands near a third of that on a wall-clock meter. On Fly Sprites, which bills CPU actually used, the same loop costs materially less because the idle window is free. We found the meter definition, not the headline rate, decides the bill.

Where the money leaks

  1. Idle provisioning: wall-clock meters charge while the agent waits on model tokens.
  2. Over-provisioned memory: teams pick 8 GiB because one build once needed it.
  3. Keep-alive environments: boxes left running "for the next run" that never come.
  4. Retry storms: a flaky suite rerun five times costs five environments unless cached.

None of these leaks show up in a rate-card comparison, which is why teams switch providers and save nothing. The meter and the lifecycle decide the invoice, while the vendor logo is rounding error.

Each leak is a lifecycle problem, not a pricing problem. Teams on per-minute billing already know this pattern from per-minute microVM costing and from why per-minute hosting changes SaaS math.

Making the number smaller

Start with the lifecycle: create on demand, kill on completion, and cap time-to-live hard. Then right-size memory from measured peaks, not from fear. Then cache dependency installs so retries skip the slow phase.

Only after those three does shopping for a cheaper rate card pay off, because the rate multiplies a duration you control. We checked the three rate cards again on 22 October while writing this guide. The spread between providers was smaller than the spread between two lifecycle policies on one provider, which tells you exactly where to spend effort first. Ephemeral microVM architecture makes the kill step safe, and eval environment design shows the same discipline at fleet scale.

A worked budget line

Take a team running 300 tasks a week at our modelled third-of-an-hour rate. On a wall-clock meter that is roughly $15 weekly, or $60 a month, before any discount tier. The number is small enough to publish in a team channel without frightening anyone.

The value is not the total. It is that a new automation can be priced before it exists, and killed before it becomes a habit. That conversation is the whole point of unit costing.

Verdict

Price the task, manage the lifecycle, then compare rate cards. Teams that invert that order optimise a multiplier while leaving the duration untouched, and the duration is where idle-heavy agent loops spend most of their money. A per-task budget with a hard ceiling beats any discount tier.

Limitations

  • Our task cost is a model built from public rate cards, but it is not a measured invoice.
  • Rates change often; however, the meter definitions move slower than the numbers do.
  • Idle-to-busy ratios vary wildly, so your task cannot be priced from ours alone.
  • We sell compute at Krova, so treat our framing as interested, and check the math yourself.

FAQ

What is the simplest unit for budgeting agent compute?

One completed task, including its retries. It maps to something a product owner can approve, and it exposes idle waste that monthly totals hide.

Does per-second billing always beat per-minute billing?

No. Per-second wins for short bursty lives; for long steady runs the difference shrinks and the floor price matters more.

Which line item should we attack first?

Idle time on wall-clock meters. It is usually the largest single component of agent compute cost and the easiest to remove with lifecycle rules.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "Agent Compute Cost: What One Task Really Costs",
      "datePublished": "2026-10-22",
      "dateModified": "2026-10-22",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/agent-compute-cost-per-task-ephemeral-microvms"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What is the simplest unit for budgeting agent compute?",
          "acceptedAnswer": {"@type": "Answer", "text": "One completed task, including its retries. It maps to something a product owner can approve, and it exposes idle waste that monthly totals hide."}
        },
        {
          "@type": "Question",
          "name": "Does per-second billing always beat per-minute billing?",
          "acceptedAnswer": {"@type": "Answer", "text": "No. Per-second wins for short bursty lives; for long steady runs the difference shrinks and the floor price matters more."}
        },
        {
          "@type": "Question",
          "name": "Which line item should we attack first?",
          "acceptedAnswer": {"@type": "Answer", "text": "Idle time on wall-clock meters. It is usually the largest single component of agent compute cost and the easiest to remove with lifecycle rules."}
        }
      ]
    }
  ]
}
For AI agents:llms.txtsitemap

Related posts