# Usage & limits

> What darting.dev meters, where you watch it accrue, and what happens when you reach a cap.

Nothing runs on your laptop — the models and the [sandboxes](https://darting.dev/docs/isolated-sandboxes/) both live in the cloud, so both are metered. Usage is tracked **per person**, not per team, so one heavy week from one teammate doesn't quietly eat everyone else's headroom.

## Two meters

| Meter | What it measures | What moves it |
| --- | --- | --- |
| **LLM tokens** | Everything an agent reads and writes, priced per model | Model choice, how much context each turn carries, how many [sub-agents](https://darting.dev/docs/sub-agents/) a thread spawns |
| **Sandbox wall-time** | The clock time your cloud environments spend awake | Long builds and test suites, live desktop or terminal sessions, threads left running |

## Where you see it

The **Usage** tab in Settings shows your consumption as it accrues, so you're never guessing between invoices. You don't have to go looking, either: the workspace raises quota warnings as you approach a limit, well before anything stops.

## Caps pause, they don't fail

Admins set **per-user caps**. Crossing one **pauses** your runs rather than killing them, and paused work is not lost — it continues from exactly where it stopped once the cap is raised or the billing period rolls over. Resumption is automatic; you don't re-send the turn or rebuild the thread.

Because every message is a checkpoint, a pause is just a longer gap between turns — see [checkpoints, stop & rewind](https://darting.dev/docs/checkpoints-and-rewind/) for the same mechanism under manual control.

## Keeping the bill down

Model choice is the biggest lever you have. [Auto mode](https://darting.dev/docs/models-and-auto-mode/) exists mostly for this reason: it keeps simple turns on cheaper models and saves the expensive ones for work that needs them, per task rather than per thread.

A few habits help on top of that:

- **Let the swarm read for you.** An [explorer](https://darting.dev/docs/agent-roles/) can map a subsystem and report back in a paragraph, so the lead never carries a hundred files in its own context.
- **Invest in memory.** The [knowledge base](https://darting.dev/docs/structured-memory/) is injected as a cheap index and read on demand, so agents stay grounded in your architecture without you pasting background into every new thread — and without paying to carry it in every request.
- **Trust compaction.** Long threads compact themselves instead of dragging their full history forward; see [compaction & context](https://darting.dev/docs/compaction-and-context/).
- **Close the loop on wall-time.** Sandboxes pause on their own when idle, but a streamed desktop, terminal, or log view holds one awake by design — see [desktop, terminal & logs](https://darting.dev/docs/desktop-terminal-and-logs/).

## Who sets the limits

Caps are set by admins, not negotiated per thread — [roles & permissions](https://darting.dev/docs/roles-and-permissions/) covers who administers a team and what's gated behind that. Because metering is per person and git credentials are stored per user, your usage and your [GitHub access](https://darting.dev/docs/github-and-auth/) travel with you across every team you belong to.