Savings report

Outcome: See frontier spend avoided, priced per model.

Steps

daari report
daari report --days 30
daari report --format json          # same payload as GET /v1/daari/report
daari usage --by-user
# Markdown export available via CLI flags / web UI export
curl -s 'http://127.0.0.1:11435/v1/daari/report?days=7' | python -m json.tool

The report payload includes clients, teams, and users (per OpenAI user on each virtual-key client_id). Virtual keys with request-count caps also contribute request_quotas: per-key used / cap / remaining plus soft: true when usage ≥ frontier.soft_budget_ratio (#519). Text and markdown daari report print that table; daari report --format json dumps the full HTTP JSON (including totals, frontier, and request_quotas) for FinOps scrapers without curling the daemon (#527). daari keys list marks soft windows as req used/cap soft. daari usage is an alias of daari report.

Includes cache-trust panels when shadow samples exist. For local pool pressure alongside spend, see backend_summary on traces and stats (GET /v1/daari/stats).

When routing.compact_to_fit actually trims history before L6, the same stats payload increments compact_to_fit_tokens_dropped (estimated tokens removed). The compact-to-fit trace step records tokens_before / tokens_after; routing behavior is described in routing tiers. That counter is local FinOps next to this report — it is not a cloud compact dashboard.

Where the numbers come from

Token counts are whatever the provider reported — prompt_eval_count / eval_count from Ollama, the usage block from OpenAI-compatible and Anthropic endpoints — recorded per model in the usage ledger alongside each request.

When a provider reports nothing (an interrupted stream, a backend that omits usage), daari falls back to a characters-per-4 estimate and marks it. Any response carrying an estimate sets usage_estimated: true in daari_meta, so a client can always tell a measured count from a guessed one rather than having to trust the number blindly.

Streams count once

A streamed request writes exactly one ledger row, whichever way the backend surfaces usage: a single usage-only chunk before [DONE] (Ollama, vLLM), running totals attached to every chunk, or nothing at all. daari keeps the last report it sees rather than summing them, so cumulative providers cannot inflate the count. The same figure feeds the client-visible usage — the final usage chunk on /v1/chat/completions, message_start.usage.input_tokens and the cumulative message_delta.usage.output_tokens on /v1/messages, and prompt_eval_count / eval_count on the final /api/chat line — so what the client sees is what the ledger, budgets and this report count. OpenAI-compatible local backends are asked for counts with stream_options.include_usage. A client that disconnects mid-stream never produces a second row.

Cost is then applied per model and per direction from pricing.models, since an output token typically costs several times an input token and rates differ by an order of magnitude across models. Models missing from that table are priced at the flat usage.frontier_price_per_1k_tokens fallback — run daari doctor to list them.

Verify

After cached traffic, estimated_saved_usd > 0 in totals. To confirm counts are measured rather than estimated, send a request with the X-Daari-Meta: 1 header and check that usage_estimated is false.

Next

→ Chargeback export · Caching and trust · Budgets and frontier