Fleet and usage

Where the dashboard's usage numbers come from. Real model burn from run accounting, and a cached view of the sandbox fleet.

The usage figures on the dashboard are not estimates. They come from GET /api/fleet, which combines real run accounting with a live view of the sandbox fleet.

What the endpoint returns

{
  "models": [
    { "model": "…", "runs": 0, "completed": 0, "avgMs": null, "tokens": 0, "cost": 0 }
  ],
  "totalTokens": 0,
  "totalCost": 0,
  "totalRuns": 0,
  "machine": {
    "snapshot": "…",
    "sandboxes": { "active": 0, "idle": 0, "liveThreads": 0 }
  }
}

Two fields are nullable by design. avgMs is a number or null when no run has a recorded duration yet. machine.sandboxes is the counts object or null when the sandbox provider is unconfigured or the inventory cache is still cold. snapshot reflects the deployment’s image configuration per provider (DAYTONA_SNAPSHOT or CUBE_TEMPLATE_ID).

Where the numbers come from

Because burn is derived from what runs actually emitted rather than a meter, the figure reflects real consumption. One caveat: only OpenCode’s part.step-finish provider events carry token and cost usage. A model whose runs came from an engine that emits no usage shows real run counts, status, and duration with zero tokens and zero cost. That zero is honest, never invented, so do not read it as no spend. Aggregation is per model and scoped to today, so the limits card reads as “today’s burn.”

Freshness

The sandbox inventory is cached with a 30-second time-to-live and served stale-while-revalidate: a request gets the last known inventory immediately while a single refresh runs in the background. On a cold cache the response reports sandboxes: null until the first refresh completes, rather than blocking the response or inventing counts.