History and usage

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 can't delete them from History; they live on the ticket.

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.

• Generation tasks, each on its own row in the per-task split:

  • Doc and playbook drafts: generating a knowledge doc or playbook from a prompt.
  • Doc and playbook revisions: each Revise on a draft.
  • Dashboard proposals: Propose a layout on a new dashboard.
  • Dashboard builds: building the charts you kept.
  • Dashboard changes and repairs: adding, changing or repairing one chart.

  These five are the runs the per-run cap applies to. Opening, filtering and refreshing a dashboard uses no AI and never shows up here; the page says so under the per-task table.

• A daily stacked cost chart.

• The 50 most recent calls, each deep-linked back to the ticket or Console thread that caused it.

Organization-wide spend

Admins get a second scope on the same page: a This machine / Organization switch above the numbers. The Organization tab is every machine in the org, not just this one, and it adds a by member breakdown alongside the by-model and by-task splits, plus month-to-date spend against the cap if one is set.

The two scopes never blend. "This machine" is this install's own local records; "Organization" is the rollup each install pushes on its 15-minute sync tick, read back from the portal. The desktop proxies the portal's own usage endpoint rather than aggregating anything itself, which is why this tab and the portal's Usage page show identical figures by construction.

Consequences worth knowing:

• Members do not see it. The switch is not rendered for them, and the endpoint refuses them locally before any call goes out. Your role is re-checked upstream too, so an admin here who was demoted in the portal gets the portal's answer.
• The tab is there even when there is no rollup behind it. Every admin gets the switch, including on an install that was never linked to the cloud, a self-hosted webapp deployment, say. There the Organization tab has nothing to read and says so: "This install isn't centrally managed. Organization usage lives on cloud-connected installs only."
• New numbers lag by up to a sync tick. An org that has just started reports "No synced usage yet" rather than zero.
• The rows attributed to Background & unattributed are system-initiated work (auto-triage, classification, embeddings, playbook reports), which runs with no acting member, plus anyone since removed from the directory.

How cost is calculated

From a per-model rate table. Cost is recorded at the time of each call, 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.