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
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.