History and usage
Finding past conversations, and reading the cost and latency numbers.
History
History is one list of every conversation you are part of.
Console threads are private to you. Nobody else can read or delete them. Clicking one resumes it, replaying its stored tool and cost chips.
Ticket follow-up chats are shared per ticket, not per person. They appear in your History because you posted in them, and they deep-link to the ticket rather than the Console. You cannot delete them from History — they live on the ticket.
Very old chats may not appear
Chat rows written before threads had owners have nobody to attribute them to, so they never show up in History. That is expected and is not backfilled.
Usage
Usage is the cost and performance view for this install.
Every LLM call writes its own row: model, prompt/completion/cached tokens, latency, and cost in USD. That includes agent iterations, the playbook classifier, ticket metadata extraction, and embeddings. One investigation is several calls; the UI folds them into the single chip you see under an answer, but the rows underneath are individual.
The page shows:
- Totals for the period.
- Per-model p50 and p95 latency — the p95 is the one to watch. A model whose median is fine and whose p95 is terrible makes investigations feel unreliable.
- A per-task split — triage vs. console vs. classification vs. embeddings vs.
playbook_report. This is how you find out that classification is quietly costing more than investigations. - A daily stacked cost chart.
- The 50 most recent calls, each deep-linked back to the ticket or Console thread that caused it.
How cost is calculated
From a rate table keyed by model. Cost is snapshotted into each row at write time, so editing rates later never rewrites history.
An entry marked unverified shows an amber est. badge — the rate is an estimate and
should be corrected against your provider's pricing page. An unknown model still
logs; it just logs at $0.
Usage recording can never break a live run: if it fails, it fails silently rather than taking the investigation with it.
The runtime default model
The Usage page is also where the install's default model is set. That default governs background triage and the playbook classifier, and is the fallback for any Console thread without its own override. See The Console.
Spend caps
If your organization has a monthly cap, the desktop meters against it. When the cap is reached:
- Background triage defers the ticket and retries later with backoff, rather than failing it outright. Only that organization's tickets are affected.
- Console and ticket chat refuse before the response starts streaming, with the cap and month-to-date spend in the message — you get a clear refusal instead of a half-written answer.
- A long run that crosses the cap mid-flight is stopped rather than allowed to finish.
The cap is set by an admin in the web portal. The month-to-date total lives here, on the desktop, and is never uploaded.