Usage metering and quotas

A plan does two things, and this page is about the second one: the limits. Where capabilities are on-or-off, quotas are the caps a plan puts on the countable parts of a workspace, how many projects it can hold, how many flow runs it can start in a day, how many hours of sandbox compute it can burn. Metering is how the platform measures use against those caps, and the Plan and Usage page is where you watch the two meet. The limits are visible from the start, measured in the open, and clear about what they allow, so you read them rather than discover them.

This page covers how a quota reads, the caps a plan sets, what happens when you reach one, how sandbox compute is metered across a team, and where to read your own usage. The plans and usage page is the companion, the tiers and the page itself, and the plans, entitlements, and quotas reference lists every cap by plan.

How a quota reads: capped, uncapped, or off

Every quota resolves to one of three states, and learning to read them is most of understanding the system.

• A number is a cap. Active projects: 3 means the workspace can hold three at once, and the fourth waits for room.
• No cap means uncapped. The countable thing is unlimited on this plan, and the Plan and Usage page says so in as many words.
• A cap of zero means the action is off. It is not a small allowance but a zero on purpose: a countable feature this plan does not include, switched on by a tier that does.

That three-way reading runs through the whole system. A higher plan does not so much grant new numbers as lift caps to uncapped: where Free holds three active initiatives, Business holds as many as you make. So the question a quota answers is never just "how many," it is "is this capped, free, or off," and the page is built to tell you which at a glance.

The quotas a plan sets

A plan sets caps on a fixed set of countable things. These are the limits you will see on the Plan and Usage page, each rising or going uncapped as the tier climbs.

The numbers behind these climb with the plan. Free is a working starter set, a handful of projects, a few flow templates, a small number of flow runs a day, a couple of compute hours per seat. Team widens each of them. Business takes most of them uncapped and pools compute across the team. Enterprise is uncapped across the board, with sandbox compute set by contract. The exact figures at each tier are part of the plan, and the Plan and Usage page always shows the ones your workspace is on.

What "active" counts

Most caps count what is active, and that word does the work, so it is worth pinning down. An active project, initiative, or plan is one that is open and live in the workspace. Archive it or carry it to a finished state and it stops counting against the cap, which is why room opens the moment you archive or complete something rather than only when you delete it. Nothing is destroyed to free a slot; the count reads the live set, not the full history.

The daily quotas count differently, by the day rather than the moment. Daily flow runs count the runs started since the last midnight-UTC reset, not the runs you have ever made, and sandbox compute counts the hours your sandboxes ran today. Both start fresh each day, so yesterday's busy afternoon never sits on today's budget. The two readings, a live count for the standing things and a daily count for the metered ones, are why a quota row either shows a current total or shows a total with a reset time beside it.

The effect is that a cap measures your present footing, not your past. A workspace that has run a thousand flows over a year and archived a hundred projects is read on what is live and what ran today, so the numbers on the page describe where the workspace stands now, which is the only thing a cap needs to govern.

What happens when you reach a limit

A quota is a clean stop, not a penalty. When a countable thing is at its cap, the next action that would cross the line is held, with a message that says which limit it met, rather than failing in a way you have to puzzle over.

The held action depends on the quota. Reaching the active projects, initiatives, or plans cap holds the next create: existing work is untouched, and room opens the moment you archive or finish something. Reaching the daily flow runs cap holds the next run until the count resets, which it does cleanly at midnight UTC, so a busy morning does not borrow against the afternoon. Reaching the seat cap holds the next member from taking a seat: the block lands when the seat would actually be filled, an invite accepted, a member added, a domain auto-join at sign-in, or an account merge that brings in a genuinely new person, which is the seat limit a workspace meets as its team grows. And reaching the sandbox compute cap holds the next sandbox from starting until the day rolls over.

In every case the limit applies at the edge, the moment of crossing, and never reaches back into what already exists. A workspace at its project cap keeps every project it has; a workspace out of compute hours for the day keeps every sandbox already running. The line sits in front of the next thing, not behind the last one.

Tom Asare goes to spin up a new plan and the create is held, with a message that the workspace is at its active-plans cap. He opens the Usage panel, sees the active-plans row at At limit, and reads the fix off the same line: the cap counts what is live, so finishing or archiving one of the plans already in flight opens room for the next. He closes out a plan the team shipped last sprint, the row drops to OK, and the create goes through. Nothing he had was lost; the limit only ever sat in front of the next plan, not behind the ones already there.

Sandbox compute hours

Compute is the one quota measured in time rather than count, and it is worth its own look because it is the limit a busy team feels first.

The platform meters the hours your sandboxes actually run on managed compute, the Azure Container Apps runtime Disco Parrot provides. A sandbox that starts, does an agent's work, and stops counts the real minutes it was alive; a sandbox sitting paused counts nothing. The tally runs by the UTC day and resets at midnight UTC, so each day starts fresh. Compute that runs on a host you bring yourself, your own Kubernetes or Docker operator, is yours to run as you like and is not metered against this cap, because it is your infrastructure and your bill.

Two shapes of compute cap exist, and a plan uses one of them.

• A per-seat cap gives each active member a daily allowance of their own. A workspace of ten people on a five-hour-per-seat plan has fifty sandbox-hours to spend across the day, and one heavy user does not starve the others of their share.
• A team-average cap pools the allowance instead. The workspace's daily budget is the per-seat figure multiplied by the active seats, spent from a common pool, so a team where a few people run long jobs and others run none still fits comfortably inside the same total.

This is the quota that genuinely holds the line on cost, so it is enforced at the moment of starting. When a sandbox is about to start or resume, the platform checks that a short slice of compute still fits in today's remaining budget and refuses the start if the day is spent, so a long job learns the budget before it begins rather than halfway through. That check is admission only; once the sandbox is running, what counts against the cap is the real time it stays alive, so a three-minute run costs about three minutes and a long one keeps accruing its actual seconds. The Plan and Usage page shows the hours used, the cap, and the time the day resets, so the budget is never a guess.

Below the Business tier each seat carries its own daily compute allowance; Business pools it across the team; Enterprise's compute is agreed in the contract rather than carried as a standing daily cap in the product. Which model a workspace is on, and how much of today's budget is left, both read straight off the Plan and Usage page.

Mid-sprint, Priya Patel kicks off a sandbox for one more agent run and it does not start. The message tells her the team has used the day's compute budget, and the Usage panel shows the sandbox compute row at At limit with a reset at midnight UTC. Nothing she had running is lost and her finished work is untouched; she picks the run back up the next morning when the day rolls over. On the team's pooled Business plan, the budget she shares was spent for the day across everyone, not rationed away from her alone, which is exactly how a shared pool is meant to feel.

Reading your usage

All of this is visible, not inferred. The Usage panel on the Plan and Usage page, headed Runtime-enforced limits for this workspace, gives every quota a row, and each row tells the same short story: what it is, how much is used against the cap, and how close that is to the line.

A row shows the count and the cap together, Active projects: 3 / 3, with a bar that fills as the count climbs and a status word that calls it plainly, OK with room to spare, Near limit as it crosses 80 percent of the cap, At limit or Over limit when it arrives, Uncapped when there is no line to approach, or Unavailable for the rare row whose figure is not measured yet. The sandbox compute row shows the time the day resets; the daily flow-run count rolls over at midnight UTC the same way, by the same UTC day the rest of the daily metering uses.

The same panel carries the workspace's AI cost. Two rows sit alongside the quotas: the monthly AI spend, a running month-to-date total in dollars that rolls over at the start of each UTC month, and a count of unpriced AI usage, the events the platform recorded but has not yet costed. The dollar total covers both confirmed and estimated usage, so the spend figure is a working number you can watch all month; the unpriced count is the small remainder still waiting on a price. Both rows always show, so the cost of the work lives in the same view as the limits that bound it; the AI spend tracking switch on the workspace settings controls whether new usage is recorded into that total, not whether the rows appear, and it is on by default.

Because the usage is right there, a workspace can see a cap coming rather than discovering it. Before a busy Sprint 24, Sarah Chen opens the Usage panel and reads it top to bottom: active projects at Near limit, daily compute climbing through the week. She archives two finished projects to clear room and files a Request capacity note for the next tier before the compute row reaches the line, so the sprint starts with headroom instead of a held create halfway through.

For a finance owner, the two moving costs of an AI workspace read off this same panel: sandbox compute, metered by the UTC day against the plan's cap, and AI spend, running month-to-date. Both are measured the same way every day, so the spend you watch climb through the month is the figure to reconcile at its close, with no separate report to pull or log to reconstruct.

Raising a limit

Caps come from the plan, so the way to raise one is to change the plan. A workspace does not edit its own quotas; the figures are set when a plan is applied, and a higher tier lifts them, often all the way to uncapped. When a limit is in the way, the Request capacity form on the Plan and Usage page is the path: it routes the need to the team that can move the workspace up a tier, the same request flow that handles a plan change. A tier change usually lifts several caps at once and turns some all the way to uncapped, so the fix for a limit that keeps biting is rarely a bigger number on the same plan; it is the next plan up, applied once.

This keeps the limits honest. A quota that a workspace could quietly raise on itself would not be much of a limit, and a plan whose caps drifted from what was agreed would not be much of a plan. Setting the caps with the plan, and lifting them with a plan change, means the number you read on the Plan and Usage page is the number in force, every time.

Why metering works this way

The shape of this system comes from a single intent: limits should be legible. A cap you cannot see is a cap you hit by surprise, and surprise is the opposite of what an administrator or a finance owner wants from the parts of a workspace that cost money. So every quota resolves to one of three plain states, every one of them is metered in the open, and the measurement sits on the same page as the cap it is measured against. There is nothing to reconstruct and nothing to guess.

Metering sandbox compute by the hour, and holding the line at the moment a sandbox starts, is the same intent applied to the one resource that runs on real money. Reserving a slice up front and refusing a start when the day's budget is spent keeps a single long job from running the bill past the plan, and pooling the allowance across a team rather than rationing it per person means the limit fits how teams actually work, where a few people run the heavy jobs on any given day. The cap protects the cost; the pool keeps the cap from getting in the way.

For an administrator, the Usage panel is the one place to see how close the workspace is to every limit at once, with enough warning to act before a cap holds someone up. Near limit is your cue, not at limit.

For a team lead, the daily flow-run and compute rows tell you whether your team's pace fits the tier. When they sit high through a normal week, the workspace has outgrown its plan, and the evidence to make that case is on the page.

For a finance owner, compute hours metered by the day and AI spend tracked by the month put the two moving costs of an AI workspace where you can see them, measured the same way every day, with the cap that bounds them in the same view.

For an engineer, the limits are clean stops with clear messages, not mysterious failures. A held create or a sandbox that will not start until the daily reset tells you exactly what it met, so you spend your time on the work and not on guessing what went wrong.