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 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 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 for the same mechanism under manual control.
Keeping the bill down
Model choice is the biggest lever you have. 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 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 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.
- 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.
Who sets the limits
Caps are set by admins, not negotiated per thread — roles & 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 travel with you across every team you belong to.