Development Choices

Metered billing when an agent drives the workload

Author
Gregory Mostizky Software Engineer
Published
Section
AI Agents
Length
5 min read3 sources cited

Metered vendor billing charges a single unit against several different resources at once. With Cloudinary, one credit buys 1,000 transformations, 1 GB of storage, or 1 GB of delivered bandwidth. Agent-driven work exhausts whichever axis it touches, and transformation and bandwidth totals keep counting for thirty rolling days.

What it is

Metered billing charges for what a workload consumed rather than for a seat or a reserved capacity. When the consumer is an agent — a loop that repeats an operation until some condition is satisfied, with nobody reading the usage page between iterations — the shape of the meter decides when the work stops, and the stop is rarely where the code looks for it.

One credit, three axes

Cloudinary’s Image and Video API bills in credits, and a credit is not one resource. It is a unit redeemable against several, at fixed rates set out in the credits FAQ in Cloudinary’s onboarding documentation (checked 2026-08-18):

One creditBuys
Transformations1,000 image or video
Managed storage1 GB
Delivered bandwidth1 GB
Video processingroughly 500 seconds SD, or 250 seconds HD

The consequence is that a run lands on whichever axis it happens to exercise, and two runs that cost the same in credits can look nothing alike. An agent that uploads forty large source files and derives two variants of each spends almost entirely on storage. An agent that regenerates a crop on every iteration spends on transformations. An agent that fetches its own output back to inspect it spends on bandwidth. The credit balance drops in all three cases; only the usage breakdown says which one happened.

Which operations increment which counter is the vendor’s definition and not something to reason out from first principles. Cloudinary publishes its rules for what registers as a transformation in its transformation-counting reference — worth reading before estimating, because an estimate built on the wrong counting rule is off by an order of magnitude rather than a few percent.

The counting window is rolling, not monthly

Transformations and bandwidth are measured over a rolling 30-day window rather than a calendar month (credits FAQ, checked 2026-08-18). There is no reset date to wait for. A run that overshoots on the 3rd keeps counting against the allowance until the 33rd, when it ages out on its own.

This separates the burst from the consequence in time, which is the part that catches people. The batch that consumed the headroom and the single call that gets refused three weeks later are in different sessions, different logs, possibly different weeks of work. It also means that when an agent does hit the limit, the remedy is frequently to wait — an action the agent cannot take and will not report. Keeping a per-run record of consumption at the time it happens, rather than reconstructing it from a monthly total afterwards, is what makes the 3rd traceable from the 25th; the same reasoning applies to attributing agent cost and latency to the work that caused it.

Storage is a current total

Storage is not windowed. It is what the product environment is holding right now, so deleting assets recovers that headroom immediately (credits FAQ, checked 2026-08-18).

That asymmetry is the one lever available after the fact. Whatever a run spent on transformations and bandwidth is locked in for thirty days and cannot be given back. Whatever it spent on storage can be handed back in a single delete call. For an agent that creates scratch uploads, intermediate renditions or one-off test assets, cleaning up at the end of the run is not housekeeping — it is the only part of the bill that is still negotiable. The corollary is that assets an agent creates need an owner and a lifetime from the moment they exist, which is the same problem as expiry semantics for resources an agent creates on a user’s behalf.

Twenty-five credits a month, and what burns them

The Free plan carries 25 credits per month, three users and one product environment, needs no credit card, and is usable in production, per Cloudinary’s pricing page (checked 2026-08-18). Spread across the axes above, that is 25,000 transformations, or 25 GB of storage, or 25 GB of delivered bandwidth, or any mix.

For development that is comfortable, with one specific exception: work that regenerates derived assets on every iteration instead of reusing them. The arithmetic is unforgiving. A hundred assets carried through twenty iterations with a settled transformation is a hundred derivations. The same hundred assets with a transformation string that changes each pass — a different width, a different quality setting, a re-tuned crop — is two thousand. Neither run looks different from the outside, and an agent tuning parameters in a loop is by construction the second one.

Two other Free-plan ceilings shape agent work: 10 MB maximum image size, 100 MB maximum video, 25 MP maximum image resolution, and 500 Admin API requests per hour (pricing page, checked 2026-08-18). A cleanup or inventory loop that enumerates assets one call at a time reaches the hourly cap well before it reaches the credit allowance, which puts it in the territory of agent execution under provider rate limits and concurrency caps rather than billing.

The failure mode is a ceiling

On a plan with no metered overage, passing the allowance does not produce a larger invoice. It produces errors. Calls that worked yesterday start being refused, against code that did not change, credentials that did not expire and an endpoint that is still up.

Combined with the rolling window, the cause is by then up to thirty days old and outside whatever log window an agent or its operator is looking at. Nothing in the failing response points at the run responsible. This is the practical reason to watch the usage breakdown per axis rather than the credit total: the total tells you that you are close, and the breakdown tells you which behaviour to change.

What to check next

Sources

  1. credits FAQ in Cloudinary's onboarding documentation cloudinary.com
  2. its transformation-counting reference cloudinary.com
  3. Cloudinary's pricing page cloudinary.com

See also