Reference

Dashboard

Ten pages, all authenticated by session cookie rather than by API key. Two of them are worth calling out, because they turn a vague feeling into a specific fix.

On this page

How it is authenticated

By session cookie, not by API key. Looking at your own memory should not cost you a credential, and handing out keys to open a page would train exactly the habit this service discourages.

So /api/dashboard/* never accepts an API key, and the agent-facing /v1/* never accepts a session. Two entry points, two authenticators, each with the authority it actually needs. Credentials is the full argument.

The pages

RouteAnswers
/dashboardWhat needs a human: unresolved contradictions, weak domains, whether the budget is truncating.
/dashboard/contextThe exact block your agent would be given for any message, with the reason and cost of every line.
/dashboard/activityEvery context build, with the block that was sent and the reason each line was included.
/dashboard/memorySearch, filter, edit, retier and bulk-forget. Plus a recall inspector that names the terms that matched.
/dashboard/tensionsContradictions by status, with resolve, reopen, and the reusable pattern a resolution revealed.
/dashboard/self-modelReliability per domain with every sample behind the score, and a form to record an outcome.
/dashboard/analyticsTokens per turn over time, the reason mix, per-endpoint and per-key spend, tier distribution.
/dashboard/startSDK and curl snippets, and a live tester that sends real requests with a key you paste.
/dashboard/keysIssue, scope, expire and revoke agent credentials.
/dashboard/settingsBudgets, extraction, retention, the organisation, and a danger zone.

Analytics: which rule spent the tokens

Splits the token spend by the rule that caused each line: index, trigger, tension, guardrail. That is the whole reason injection reasons are recorded rather than inferred.

A build that spends its whole budget on index lines and no bodies is not a memory that needs a bigger budget, it is a store with nothing worth promoting, and the two problems have opposite fixes. 118k tokens is a number with no action attached; “104k of it was index lines and 2k was full bodies” is a diagnosis.

This is the page to read when a deployment feels expensive. Not the context page, which tells you what went wrong on one turn — analytics tells you whether the fix is a budget or the store.

Activity: what was actually sent

Replays the block that was actually sent, not the one the planner would produce today. Re-running the planner against current memory answers “what would the agent get now”, which is a much better-looking answer than the one that caused whatever you are trying to understand.

The triggering message is not stored with it — that is the conversation, not the memory — but the identifiers inside it are, because those are what explain why a full body was spent.

So when a turn looks wrong, this is where you find out whether the mistake was in what was held, in what was selected, or in what the model did with it. Those are three different bugs and they are not distinguishable from the prompt alone.

Settings: overrides that are visible

Per-organisation overrides of the token ceiling, the index limit and the recall default, plus whether model extraction runs at all and how long the logs are kept.

Each override is nullable, and null means “inherit the deployment default”: a setting that silently reverts is worse than no setting at all, so the page shows both numbers and clearing the override is one click rather than a guess at what the deployment default was last week.

The same three values are deployment-level environment variables. The dashboard is the per-organisation layer above them, not a replacement.

Getting started from here

Get started holds SDK and curl snippets generated for the deployment you are actually signed in to, plus a live tester that sends real requests with a key you paste. It is the fastest way to confirm a key works before wiring it into an agent.

If you would rather read first: the quickstart is two calls, what goes into the prompt is where the design bets are, and the API reference is exhaustive.