All docs

Usage and fleet analytics

The Usage view breaks spend and token burn down per provider and per model over the last 7, 30 or 90 days, so the question of which model is actually costing you money has an answer. A provider filter narrows the totals, charts and rows. /usage is separate: it reads the provider's own quota windows and reset clocks, not the local history.

The Usage view breaks spend and token burn down per provider and per model over the last 7, 30 or 90 days, so the question of which model is actually costing you money has an answer. A provider filter narrows the totals, charts and rows. /usage is separate: it reads the provider's own quota windows and reset clocks, not the local history.

For models that report tokens but no cost, set prices in Settings, Spending, Model prices (USD per million tokens for input, output and optional cache read and write). They fill only the missing costs, never override a cost the provider reports, and re-price past usage when you edit them.

Fleet analytics asks the harder question: is the work any good. It is computed from git and GitHub ground truth rather than from what the agents report about themselves: merge rate, review tax (how much human review each PR pulls in), rework (work that had to be redone), and cost per merged PR. Failure modes are clustered across threads, so a mistake several agents keep making shows up as one pattern instead of ten separate red threads.

When a thread finishes, a one-tap card asks how much time it felt like it saved (15 min through 4 h+, or Skip). Fleet analytics sums those estimates against wall-clock and agent-active time for the same threads and reports the perception gap as felt divided by wall-clock. Skip records a decline so the card does not ask twice. Threads with no estimate are left out of the ratio rather than treated as zero.

The orchestrator also emits OpenTelemetry GenAI spans, so runs can be sent to whatever tracing backend you already have.