> ## Documentation Index
> Fetch the complete documentation index at: https://chatcli.edilsonfreitas.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Live Dashboard
> Watch what every chatcli process on your machine is doing, in real time, as a graph that lights up while things happen: agents, LLM requests, tools, skills, MCP servers, the seven harness patterns, background work and outbound connections.
`/dash` opens a live graph of the runtime in your browser. Every agent, every LLM request, every tool call, every skill that activates, every MCP server, every harness pattern that fires, every background job and every outbound connection is a node; an edge pulses each time something happens on it.
It is end-to-end telemetry with no setup: no collector, no agent, no account. It is **off by default and costs nothing while off**.
***
## Opening it
| Command | What it does |
| -------------- | ------------------------------------------------------------------ |
| `/dash` | Start the dashboard and open it in the browser |
| `/dash url` | Start it and only print the address |
| `/dash status` | Show whether this process is recording, and which processes report |
| `/dash off` | Stop it |
| `chatcli dash` | Serve the dashboard from a terminal of its own, until `Ctrl+C` |
`/dash` works **while a turn is running** (type it mid-run) and **over ACP**, where the address comes back to the IDE chat.
The browser only opens from an interactive terminal. From a daemon, a pipe or an IDE, the address is printed instead.
***
## It sees every process, not just this one
Opening the dashboard makes **every chatcli process on the machine** start reporting: the REPL you typed `/dash` in, a second terminal, the gateway daemon, the ACP agent inside your IDE, the MCP server another client is driving, the scheduler daemon. Each one is a band on the page.
This is what `chatcli dash` is for: the ACP agent, the MCP server and the daemons have no prompt to type `/dash` into, and their stdout is a protocol stream. A dashboard in another terminal is the only window into them.
### How recording turns on and off
1. Whoever serves a dashboard keeps a small **lease** file renewed under `~/.chatcli/pulse/`.
2. Every chatcli process checks that lease every two seconds. While it is unexpired, the process records to its own spool.
3. The lease is renewed **only while a browser is actually polling**. Close the tab, and about 30 seconds later every process goes quiet again on its own. Nothing stays on by accident.
To record from boot without waiting for a dashboard (useful for the surfaces with no prompt), set:
```bash theme={"system"}
export CHATCLI_DASH=1
```
It is read live: changing it in `.env` takes effect on `/reload`.
***
## What you see
Sessions and agents are **one node each**, linked by their real parent, so a multi-agent dispatch reads as a tree. Everything else is a **hub aggregated by name** (the `@coder` tool, the `github` MCP server, the `self-refine` pattern) showing calls, how many are active right now, errors and average latency. The graph stays stable and *fires*, instead of exploding into one node per call.
| Node kind | What is reported |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **session** | The process: surface (`repl`, `acp`, `gateway`, `mcp`, `daemon`, `tool`, …), pid, provider and model, the session's running **cost**, tokens and requests, and **how full the context window is** (`ctx 37%`, the same projection the turn footer prints; past 100% means the next turn compacts) |
| **agent** | Every orchestrator, [squad worker](/features/agent-squad), subagent, [MoA](/features/mixture-of-agents) member and [task graph](/features/task-graph) run: turn `3/30`, tool calls, current action, outcome |
| **llm** | One hub per `PROVIDER:model`. Each request hangs from **the agent that made it**, with payload size, history length and tool count. Every usage report adds what the call consumed (input, output, cache read and write tokens), the lane it ran in (main, worker, background) and the model's running tokens, requests and **cost**: the numbers [`/cost`](/features/cost-tracking) shows, as they change |
| **tool** | Every tool execution: the orchestrator loop, squad workers, and the RPC / `chatcli tool` path. A call refused by the [security policy](/features/coder-security) shows as `blocked` |
| **skill** | A [skill](/features/builtin-skills) counts as activated when it is actually delivered to the model (after trigger match, dedup and cooldown): at run start, mid-loop or on a chat turn. Aging out of the window shows as `collapsed` |
| **mcp** | One node per [MCP server](/features/mcp-integration) with its state (`starting`, `connected`, `failed`, `disconnected`, `stopped`, `auth required`) and tool count; every `tools/call` is a timed span carrying the tool name |
| **pattern** | The [seven harness patterns](/features/quality/overview), each with **what it concluded** (see below) |
| **background** | [Scheduler](/features/scheduler) jobs, `@proc` processes, the memory worker, history compaction, language servers, the `@browser` session, auto-update staging |
| **conn** | Outbound HTTP by **hostname**: method, status, latency, bytes. A token stream shows as one live connection with its real duration |
| **rpc** | chatcli acting as a server ([MCP server](/features/mcp-server), [ACP](/features/acp)): every inbound method, and what the server asks of the client |
| **turn** | Chat and one-shot turns |
### The seven patterns, with outcomes
[Self-Refine, CoVe and Reflexion](/features/quality/overview) run silently: they rewrite a worker's output, flag a discrepancy or queue a lesson without printing a line. The dashboard shows not only that a pattern fired but what it concluded.
| Pattern | Outcome shown |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| [ReAct](/features/quality/react) | every loop, with the turns it took (a park is a deliberate outcome, not a failure) |
| [Plan-and-Solve](/features/quality/plan-and-solve) | `routed to @taskgraph`, `dry run preview`, `executed N steps` |
| [Reflexion](/features/quality/reflexion) | the trigger and `lesson queued`, then from the background worker: `lesson saved`, `no lesson`, `retrying`, `dead letter` |
| [RAG + HyDE](/features/quality/rag-hyde) | `augmented retrieval`, `fell back to plain hints` |
| [Self-Refine](/features/quality/self-refine) | `rewrote draft`, `kept draft`, `rolled back`, `failed`, with the pass count |
| [CoVe](/features/quality/cove) | `verified clean`, `found discrepancy`, `corrected draft` |
| [Reasoning backbone](/features/quality/reasoning-backbone) | the effort tier it attached, and to which agent |
A pattern that is disabled, or whose guards reject the result, did nothing and stays dark.
### Things that are easy to miss without it
* **A compaction looks like a hang.** History compaction summarizes the conversation with an LLM call of its own and holds the turn for as long as that takes. On the dashboard it is a `compaction` span that ends with `applied` or `skipped`.
* **A permission dialog nobody answered.** Over ACP/MCP it shows as a `client:session/request_permission` call that never ends.
* **The dev server you started an hour ago.** `@proc` processes are replayed when the dashboard opens, so they show up even if they started long before.
* **Which worker spent the requests.** Each LLM request hangs from the agent that made it.
### Using the page
Drag to pan, scroll to zoom, `0` or **Fit** to fit, `Space` or **Pause** to freeze, click a node for details. The chips at the top show and hide processes; the legend at the bottom shows and hides node kinds. The page follows your terminal [theme](/features/ui-theme) and language.
A dashboard opened in the middle of a run starts from **what is live right now** (running agents, connected MCP servers, background processes), not from empty.
***
## Privacy and safety
**Events carry metadata only**: names, sizes, durations, statuses, token counts. The following never leave the process, and tests enforce each one:
* prompt text, the task given to an agent, model output, error text
* tool arguments and tool output, MCP call arguments and results
* file paths touched by a tool
* URL **paths and query strings** (where API keys and bot tokens travel): only the hostname is shown
* a process **command line**: only the program name, and only when the first word is a plain program rather than a `VAR=value` assignment
* a browser URL or anything on a page; a scheduled job's payload, message or output
**The server is local but not open.** It binds to `127.0.0.1` on an ephemeral port, and on top of that:
* every API call needs a random token minted at start. It reaches the page through the address once, moves to memory and leaves the address bar;
* every request must carry the exact `Host` it was bound to, which closes DNS rebinding from a web page;
* `GET` only, a strict Content-Security-Policy, no CDN, no network calls.
The dashboard is a **read-only observer**: it reads the spool from disk and holds no state. Closing it, reloading it or opening a second tab never affects a running session.
***
## Cost
With the dashboard off, each instrumented point costs **one atomic load**, and a process does one `stat` every two seconds to check the lease. No spans are built, no bodies are wrapped.
While recording, emitting **never blocks**: a full queue drops the event and counts the drop, and a slow consumer loses events instead of slowing the others. `/dash status` and `/config dash` show published and dropped counts.
***
## Storage
Each process writes to `~/.chatcli/pulse//` in size-rotated segments capped at roughly **16 MB per process**, with a heartbeat that tells live processes from dead ones. Spools of dead processes are removed after **24 hours**, at boot and on demand:
```bash theme={"system"}
/storage prune pulse # simulate
/storage prune pulse --apply # remove
```
A process that is still recording is never a candidate. See `/storage` in the [command reference](/reference/command-reference).
***
## Configuration
| Variable | Default | Description |
| -------------- | ------- | ----------------------------------------------------------------------------------------------- |
| `CHATCLI_DASH` | unset | `1` / `true` / `on` / `yes` records from boot without waiting for a dashboard lease. Reloadable |
`/config dash` shows the variable, whether this process is recording, the spool directory and the event counters.
***
## Relationship to other observability
| You want | Use |
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| To **watch the runtime live**, as a graph, across processes | **`/dash`** (this page) |
| To watch one [task graph](/features/task-graph) run in depth: gates, verdicts, critical path, cost per task | `/taskgraph dash` |
| Tokens, cost and cache behavior of the session | [`/cost`](/features/cost-tracking) |
| Metrics in your own backend (Grafana, Datadog, …) | the [OpenTelemetry exporter](/features/server-mode#opentelemetry-export-otlp) (`OTEL_EXPORTER_OTLP_ENDPOINT`) |
| A tamper-evident record of every LLM request | the [audit trail](/features/security) (`CHATCLI_AUDIT_LOG_PATH`), which also records **which agent run** made each request (`caller`) |