Taming Agent Spend: Budgets, Quotas, Right-Sizing

Taming Agent Spend: Budgets, Quotas, Right-Sizing

Agent spend defeats classical cloud budgeting because the workload misbehaves in three specific ways: it idles while models think, it retries in storms, and it over-provisions because nobody knows the right size. None of those behaviours appear in a capacity plan written for steady servers, which is why the old budgeting ritual fails quietly.

A FinOps programme for agents has to price the unit, cap the blast radius, and resize from evidence. This playbook covers those three moves in order, and skips the fourth move, reservations, entirely. Agent demand is too spiky to reserve against, and every team we have watched try ends up paying for idle twice.

Price the unit before you cap the total

A monthly ceiling without a unit is just a countdown to an incident. Define cost per completed task per team, computed from your platform's meter, for example E2B's per-second rates, and publish it next to the feature backlog. We walked through that arithmetic in our agent compute cost guide, and the short version is that idle time on wall-clock meters is usually the biggest line. according to Beri's October analysis, idle time, not cold start, sets the bill.

Hard quotas that survive a bad week

1. Concurrency cap per team: limits retry storms and runaway fan-out at the source.
2. Time-to-live cap per environment: no box outlives a working session by default.
3. Spend alert at 50% and 80% of monthly budget, routed to the team, not to finance.
4. A kill switch that drains new creations while letting running tasks finish.

Quotas feel bureaucratic until the first agent loop that retries four hundred times; after that they feel like seatbelts. The same controls appear in per-minute costing writeups because the failure mode is meter-agnostic.

Right-size from evidence, not from fear

Teams pick 8 GiB because one build once OOMed, then pay for that memory across ten thousand runs. Collect peak memory and CPU per task type for two weeks, then set sizes at p95 plus headroom, not at p100 plus fear. Fly's RL rollout pricing page shows why this matters at scale: the same 10,000 rollouts cost $28 on an actual-use meter and $119 on a provisioned meter, a gap driven mostly by sizing and idle policy.

Where isolation choices hit the budget

Isolation technology is a cost lever too. MicroVM snapshots shrink retry cost by skipping cold phases, as we detail in speeding CI with microVMs, and ephemeral lifecycles remove the keep-alive tax we describe in per-minute hosting economics. FinOps and platform engineering converge exactly here: the cheapest compute is the compute that never starts.

Reporting cadence that people read

One page, weekly: cost per task by team, top five environments by spend, idle percentage, and quota headroom. Anything longer gets skipped, and a skipped report is worse than none because it trains people to ignore the channel. We found the idle percentage is the number that changes behaviour fastest, because teams recognise it as their own lifecycle debt.

A sample one-pager

Ours fits ten lines: cost per task by team, top five environments by spend, idle percentage, quota headroom, and the week-over-week delta for each. Nothing else earns the slot, because a report people skip is worse than no report.

The idle percentage row does the behavioural work. Teams recognise it as their own lifecycle debt, and it drops within two sprints of being published. We found shame scales better than memos. Publish it where standup happens, not where dashboards go to die.

Verdict

Unit price, hard quotas, evidence-based sizing, in that order. Teams that start with discounts or reservations optimise the wrong layer, because agent spend is dominated by duration and idle policy, both of which are under engineering control.

Limitations

• The rollout cost figures are Fly's published model, but not our measurement of other platforms.
• Quota thresholds are starting points; however, calibrate them against your own retry distribution.
• We sell compute, so our incentive is honest metering rather than maximal usage; judge accordingly.
• Two weeks of peak data is a minimum; seasonal suites cannot be predicted from it anyway.

FAQ

What is the first control to add?

A concurrency cap per team. It is trivial to implement and it stops the most expensive failure mode, the retry storm.

Should agent compute go into unit economics?

Yes, as cost per task or per pull request. Anything monthly hides the feedback loop that changes behaviour.

How do we handle shared eval fleets?

Tag by experiment, budget by experiment, and kill experiments by TTL rather than by human memory.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "Taming Agent Spend: Budgets, Quotas, Right-Sizing",
      "datePublished": "2026-10-25",
      "dateModified": "2026-10-25",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/taming-agent-spend-budgets-quotas-right-sizing"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What is the first control to add?",
          "acceptedAnswer": {"@type": "Answer", "text": "A concurrency cap per team. It is trivial to implement and it stops the most expensive failure mode, the retry storm."}
        },
        {
          "@type": "Question",
          "name": "Should agent compute go into unit economics?",
          "acceptedAnswer": {"@type": "Answer", "text": "Yes, as cost per task or per pull request. Anything monthly hides the feedback loop that changes behaviour."}
        },
        {
          "@type": "Question",
          "name": "How do we handle shared eval fleets?",
          "acceptedAnswer": {"@type": "Answer", "text": "Tag by experiment, budget by experiment, and kill experiments by TTL rather than by human memory."}
        }
      ]
    }
  ]
}