Daniele
0958264c6f
Nightly Build / build (push) Successful in 4m27s
The stats section was designed single-user: four global charts, no attribution. Request metadata rows now carry the session's source and the frame's agent_id/depth (additive ensure_column), denormalized at log time by the LoggingModel from the owner's pool — off the turn's hot path, degrading to NULLs, never to a lost row. The dashboard gains member scope chips filtering every chart, and a breakdown row splitting the range's billed tokens by member, kind (chat / sub-agents / cron / system agents / channels), agent, model and provider — a sub-agent's spend is attributed to the sub-agent itself. Rows predating the columns group under 'older data'.
69 lines
5.3 KiB
Markdown
69 lines
5.3 KiB
Markdown
# The Dashboard (the home overview)
|
|
|
|
Sidebar → **Dashboard**, just below Chat: the overview page. One glance answers three questions — *is the assistant usable right now, is anything waiting for me, how much has it been used?* It is visible to everyone in the full interface; members with the simple interface ([roles.md](roles.md)) go straight to chat and never see it.
|
|
|
|
## The status line
|
|
|
|
Under the title, one line summarising the configured LLM models:
|
|
|
|
- **Online & ready** — at least one model answered its last check. Nothing to do.
|
|
- **Degraded** — no model is fully healthy, but at least one is still partly answering. Expect slower answers and fallbacks to whatever works.
|
|
- **All models offline** — no model answered. Chats will fail until it recovers or an admin looks at the provider.
|
|
- **No LLM models** — the instance has no model configured at all. The banner below the hero says the same thing more loudly and points the admin at the Providers page.
|
|
|
|
The status reflects the **whole instance**, not one person's account: there is one set of models, shared by everyone.
|
|
|
|
## LLM usage stats
|
|
|
|
The section answers two questions: *how much is the instance being used?* and *who or what is spending the tokens?* A range switch (last hour / 24 hours / 7 days / 30 days) applies to everything on it, and — on an instance with more than one member — a row of member chips filters **all** the charts to one person; **Everyone** is the whole instance, as before.
|
|
|
|
Three charts show the trend over the range:
|
|
|
|
- **Requests** — how many LLM calls per minute, hour or day.
|
|
- **Tokens** — the metered volume, split into input (split again into cached and non-cached) and output. The tooltip shows the cache-hit percentage: repeated context that was *cached* costs less and answers faster, so a high hit rate is good news, not a sign something is stuck.
|
|
- **Avg latency** — how long a model call took on average.
|
|
|
|
Below them, **How the spend splits** breaks the range's billed tokens down into bars:
|
|
|
|
- **By member** — who consumed what (hidden while a member chip is selected: it would be a single bar).
|
|
- **By kind** — direct chats vs **sub-agents** (specialists the assistant delegates to) vs **scheduled tasks** and the other background system agents. Data from before this breakdown existed groups under *Older data*.
|
|
- **By agent** — which assistant or specialist consumed the most.
|
|
- **By model** and **By provider** — where the money actually goes.
|
|
|
|
A bar's tooltip shows the request count and the input/output/cached split.
|
|
|
|
Three honest answers to give with a straight face:
|
|
|
|
- **They record how much, when, by whom and on which model — never what was said.** The content of a request lives in the requester's own encrypted space; the charts read only counters.
|
|
- **The per-member chips are a consumption view, not a surveillance tool.** They show token counts, not conversations.
|
|
- **Empty is normal on a new instance.** "No LLM requests in the selected range" means exactly that: nothing has run in that window.
|
|
|
|
## Pending
|
|
|
|
The same cards as the [Inbox](inbox.md) — approvals, questions and sign-in prompts from background work — with a live count. It updates on its own while the page is open; answering here is the same as answering in the Inbox. An unanswered card means a stopped job, so this section is worth a look before "why hasn't it finished?".
|
|
|
|
## The tip and the quick guide
|
|
|
|
- A suggestion box appears when a long-term-memory plugin is available but not running — it is a nudge for the admin, not an error.
|
|
- The **Quick guide** at the bottom is seven cards pointing at the rest of the app (chat, inbox, agents, scheduled tasks, models, providers, security rules). It is a map for someone new, not a status of what is enabled.
|
|
|
|
## What this page is not
|
|
|
|
- **Not a monitor.** Nothing here alerts anyone; it shows the present state to whoever is looking.
|
|
- **Not where models are configured.** Adding providers and models, and their priority order, is the admin's Models and Providers pages.
|
|
- **Not a message log.** The per-member and per-kind charts show volumes of tokens, never what anyone asked or was answered.
|
|
|
|
## Common questions
|
|
|
|
- *"It says Degraded — should I worry?"* — it means the model checks are not all passing. Individual chats may still work on a fallback model; if it persists, the admin checks the provider (its key, its quota) on the Models/Providers pages.
|
|
- *"Why are the bars so high at odd hours?"* — scheduled background work (system agents, cron tasks) uses the same models. The **By kind** chart shows exactly how much of the spend is background work versus direct chats; the Tasks page and the system-agents page show what ran when.
|
|
- *"What is a token?"* — the unit LLM providers meter and bill by, roughly a word fragment. Input is what was sent (long history = more input; caching repeats cheaply), output is what was written back.
|
|
- *"Why doesn't my child see this page?"* — their role uses the simple interface: chat, inbox and projects only.
|
|
- *"Does the dashboard show what people asked?"* — no. Only counts, timings and model names; never content.
|
|
|
|
## Related
|
|
|
|
- [inbox.md](inbox.md) — the three kinds of pending request, and answering them
|
|
- [agents.md](agents.md) and [tasks-page.md](tasks-page.md) — what may be running in the background
|
|
- [roles.md](roles.md) — the simple interface, and who sees which pages
|