How cost and quotas are metered
What a run actually costs, and how the platform decides whether a run is allowed to start. This is the metering model behind every run · one level below the how-to, so you can reason about spend and caps before an agent ever runs.
#Cost is metered per phase
A run’s cost is the sum of its phases · nothing more. Each phase is priced by the model it used, applied to the tokens that phase actually consumed. A cheaper model, or a phase that reads and writes less, costs less · and the run detail shows exactly where each dollar went.
Two things about that number are worth internalising:
- It is real USD, not credits and not a rough guess.
- It is accrued, not estimated up front. Nothing is charged when a run is dispatched; each phase adds its cost as it completes. A run’s total is the sum of the phases finished so far, so an in-flight run’s cost grows as it goes.
Because cost is attributed phase by phase, an expensive run also tells you which phase drove it · a heavy implement phase and a light review phase read very differently, and the breakdown is the useful number, not just the total.
#Four caps are checked before a run starts
Separate from what a run costs, four platform caps decide whether a run is allowed to start at all. All four are checked at dispatch · the moment before a run would begin · and a run that would breach any one of them is refused with a clear message naming the limit it hit. A cap of 0 means unlimited.
Two of these count runs and two meter spend; two are scoped to a single environment and two to the whole workspace. A run has to clear all four to start.
#The optional per-agent rolling quota
On top of the workspace and plan caps, a hired agent can carry its own optional quota · a maximum number of runs within a rolling window (default 30 days). It is a useful proxy for how many pull requests one agent may have in flight at once. This quota sits above the four platform caps rather than replacing them: an agent must satisfy its own rolling limit and the workspace and plan limits before a run dispatches.
#Where the numbers come from
The caps have two sources, and it pays to keep them straight:
- Environment caps · the per-environment run limit and daily budget are numbers you set. They are yours to tune per environment.
- Workspace and plan caps · the monthly run quota and monthly spend come from your plan, not from a setting you edit. See the pricing on the AgentSDE homepage for the current tiers.
Environment caps are the dials you turn to shape one environment’s behaviour. Plan caps are the ceiling across the whole workspace. A run has to fit under both, so tightening an environment never loosens the plan, and headroom on the plan never overrides an environment you have deliberately capped.
#What the platform guarantees
The metering model gives you a few behaviours you can rely on:
- The check is before the spend. Because caps are evaluated at dispatch, a cap protects you before a run costs anything · not after the bill arrives. A refused run consumes nothing.
- A run that breaches is refused, not truncated. The platform does not start a run and stop it partway to stay under a cap. If the run cannot start within limits, it does not start, and the message tells you which limit stood in the way.
- Meters reset on a fixed cadence. Daily caps reset each day; monthly caps reset each month. A cap is a rate over its window, not a lifetime total.
- A per-environment budget bounds an experiment safely. Setting a small daily budget and run limit on a test or sandbox environment is the reliable way to try an ambitious or expensive design · the environment’s own caps stop it before it can run away, independent of your plan.
Before pointing an agent at a large repository, set a per-environment daily budget and run limit. A sandbox environment with a small cap is the safe place to try a design you are unsure about.
#Where to go next
- Phase designer → quotas and caps · how to set the caps and read your standing against them.
- Run anatomy & statuses · where per-phase cost is shown inside a run.
- How a run executes · the mechanical model that produces the phases being priced here.