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 billing account. The project's Billing setting chooses Owner pays, Sender pays, or Sender, then owner. The default is Sender, then owner: a member's turn bills them while they can spend, then falls back to the team owner. Owner-sent work and work without a sender bill the owner.
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 |
Credits and the Auto plan
Usage is paid from credits you buy, or from the $200 Auto plan. The plan funds Auto work through a 5-hour window and a weekly window; you can stack units for more headroom, and turns on a model you pick by name draw on purchased credits instead. Account settings → Credits shows plan credit and prepaid credits as two separate balances, and when the plan renews or ends.
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 stops your runs with Usage limit reached 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 turn 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. Billing-account limits apply across teams; the project's Billing setting determines whose account pays. Git credentials remain per user; see git hosts & authentication.