The guards, not the traffic
A page of these numbers is a page about how often the model is wrong in ways the application can catch, kept content-free by construction.
Most of what the console counts is not traffic. It is the guards: the times a reply came back with something in it that had to be taken out before the message was composed, and what that cost. A page of those numbers is a page about how often the model is wrong in ways the application can catch.
Every buffer here is in memory and content-free by construction: what is kept is that something happened, where, and how long it took, never the member's text and never the generated reply.
These counters reset when the process restarts. A quiet page means the process is young at least as often as it means the guards found nothing, and only one of the ten survives a restart at all.
Every counter, what it counts, and how long it lives
All ten, with the scope each is recorded at, what each buffer keeps and shows, and which single one survives a restart.
| Counter | What it counts | Recorded per | Buffer | Lifetime |
|---|---|---|---|---|
| "AI runtime" | resolver calls, successes, rule fallbacks and guard overrides, with average and last latency | Deployment | counters only | reset on restart, or by Reset operations telemetry |
| "Recently ignored (near misses)" | messages the guards dropped, with the reason each was ignored | Bot | 50 kept, 25 shown | reset on restart, never persisted |
| "Free conversation" | attempts and their outcomes: answered, dropped by the reply limit, the model unable to speak, or stopped by the repetition gate | Bot | 50 kept, 25 shown, content-free | reset on restart, never persisted |
| "Lines she wrote that are not hers to write" | application lines she reproduced anyway, removed before the message was composed | Bot | 50 kept, 25 shown; the total uncapped | reset on restart; one journal line per strip |
| "The member name taken out of her answers" | blocked-name catches, counted by what each cost: the name stripped, the draft lost, or the answer lost outright | Bot | 50 kept, 25 shown; the total uncapped | reset on restart, never persisted |
| "Refusals she invented" | first-person refusals of a capability this bot actually holds, judged against its own capability catalog | Bot | 50 kept, 25 shown; the total uncapped | reset on restart, never persisted |
| "Claims about members" | refused requests to set a rule aside, and removed verdicts about what a member said or did not say | Bot | 50 kept, 25 shown | reset on restart; one journal line each |
| "Denied seeing the chat while holding it" | replies denying she can see the conversation while the conversation was in her prompt, recorded and never removed | Bot | 50 kept, 25 shown | reset on restart; a warning and a dashboard error each |
| "Refused before searching" | pre-search gate refusals: requests that never reached a provider, with the last refused category and its time | Deployment | a total and the last one | reset on restart, never persisted |
| "recorded decisions" | the invocation record: rule id, kind, category and time for every gate decision, with pre-search refusals appearing as ceiling rows | Neither: the rows carry the group only | 25 shown of a 100-row fetch | the only persisted diagnostic: a database table that survives restarts, kept 90 days by default |
Counter names quoted from console export 05 · GET /interaction/diagnostics · card names as the console draws them · the complete list audited in site material Block 3 section 6
Where each one lives
8 of them are cards on the Diagnostics page itself. The other 2 live where the thing they count happens: the pre-search refusals sit with the web-search plugin, and the invocation record has its own page. Both of those are the two that belong to the hard limit, which is why the limits page names them and this page lists them: the same two rows, from the same source, not two descriptions that have to be kept matching.
The one that persists
One counter is a database table and survives a restart, kept 90 days by default. Every other row on this page is an in-memory buffer that starts again from nothing when the process does.
What none of these counters can tell you
The counter that does not exist, the filter that is not applied, and the reading a zero does not settle.
No counter for a model-side refusal
There is no counter that counts ceiling crossings in conversation, and that is deliberate rather than missing. A refusal the model makes leaves no row the application can attribute to a rule, and a record that guessed which rule fired would make the true rows unreadable. The two counters that do carry ceiling rows count the deterministic floor on the lookup path, where the application refused before any model was asked.
The streams interleave
Every record carries the bot it came from, and the page filters by none of them. On a deployment running two bots the streams interleave, so a number here is the deployment's, not one bot's, whatever the per-bot column says about how it was recorded.
A counter that reads zero has two readings and the page cannot tell you which: nothing went wrong, or nothing has run since the last restart. Only the persisted one distinguishes them.
What the guards themselves do, and why a reply is sometimes stripped rather than discarded, belongs to the pages the counters point at: the limit on the limits page, and what she may never claim on the system prompt page.