Usage & limits
See balances and consumption, configure compute limits, and understand the current model-spend caveats.
The Usage & limits pane shows usage attributed to your organization and lets an admin cap it — reliably for compute, and for managed-model spend only where a member's gateway enrollment attributes it to the org rather than to them personally.
| Scope | |
|---|---|
| Who | Owner or admin only — the pane is admin-only. Members see their own compute and LLM usage in the app sidebar, not here |
| Applies to | Cloud compute and the managed gateway — local work is not metered |
| Plan | Hosted cloud billing enabled on the organization |
| Affects | The organization and individual members |
What the pane shows
Balances, a consumption timeseries over the selected range, and a per-member usage drill-down — all live, reflecting usage attributed to the organization as above. This is the admin view of the whole organization; a member's own compute and LLM meters live in the app sidebar.
Configuring limits
Each limit is one row. Add an organization-wide row that applies to everyone, or a per-member row for a single person.
Per row, set:
- Resource — Compute (capped in PCUs) or LLM spend (capped in USD).
- Window — Daily or Monthly.
- Cap — the amount for that window.
- Enabled — a per-row switch; a disabled row is kept but not applied.
Rows take effect when you Save.
Enforcement
Every applicable enabled limit is evaluated in its own UTC daily or monthly window. Reaching any applicable limit blocks that resource.
Compute limits are enforced. The reconciler pauses over-cap sandboxes within about 15 minutes, and the resume gate blocks a paused sandbox from waking until it is back under its cap. A paused sandbox keeps its work and chat history and can resume once it is under cap again.
Org LLM limits are incomplete today. A configured LLM limit applies only to gateway usage attributed to the organization — not to all managed-gateway usage. Because normal enrollment can attribute spend to a member's personal subject rather than to a shared organization subject, treat org-level LLM budgeting as incomplete today. Usage on your own keys or gateway is outside it entirely.
Two details in how usage is attributed are why:
- Normal agent authentication renders a member's personal model-gateway enrollment, not the organization's, so gateway spend is attributed to the member rather than to a shared organization subject.
- Which organization a member's usage lands against resolves through the server's current membership, not the org selected in Desktop, so for a member in more than one organization it can attribute to a different org than expected.
The pane manages and stores these limit rows and evaluates them per window. It does not change what a member's own provider keys or a bring-your-own gateway allow. See Model gateways.
What members see when blocked
When a cloud workspace can't start or wake for a billing or capacity reason, the banner names the cause instead of a generic error:
| What members see | What it means |
|---|---|
| Cloud runtime unavailable | The organization is out of hosted compute capacity. |
| Model gateway unavailable | Gateway-routed model calls are unavailable or have reached their configured budget. |
| Payment or account needs attention | Hosted access is paused until the account issue is resolved. |
| Sandbox limit reached | The maximum number of concurrent cloud sandboxes is already running. |
| Repository not covered | The repository isn't covered by the GitHub App installation or cloud setup. |
The reason appears in the sidebar when creating a cloud workspace, and on the workspace itself if it is still starting. The member-facing walkthrough of these states is Billing issues.