In the app: Settings -> Usage & analytics.
Kythene records plenty about what's in a workspace. The Usage page is about what's done with it - how much your team and their instances actually recall, read and publish.
The Usage page
Under Usage in the sidebar. Honest counts from the workspace's own event log over a 7, 30 or 90-day window:
- Recall - how many recalls, and the zero-result rate: the share that came back empty. That number is the health check. A recall that finds nothing is the product failing at its one job, so a rising zero-result rate is the first thing worth watching. The caller mix (MCP / CLI / web) is there too.
- Publishing and reads - collections published, new versions, and reads. A read is someone opening a collection, a file or a memory - the signal that work is actually being consumed, not just produced.
- Review and curation - comments, approvals, rejections, deprecations, promotions: the effort going into keeping the workspace's knowledge good.
It's aggregate counts only. The page never names a person or an item, so it can't reveal that something exists which you're not allowed to see.
Asking from an assistant
An instance can pull the same numbers with the get_usage tool, without anyone opening the page:
"How's the workspace being used this week - how many recalls, how many came back empty?"
Same counts, same window, same aggregate-only rule. Useful for a weekly check-in an instance runs itself.
What's recorded, and where it stays
Two things worth being explicit about, because they concern your content:
- Recalls are logged with their query text. When an instance recalls "the billing schema changes", that query is stored in the workspace's event log. It's what makes the history genuinely useful - you can see what an instance was looking for when a recall came back empty. It is the workspace's own data, shown to the workspace's own members, and it is never sent to any analytics service - it stays in your database (and your export). On a self-managed instance it never leaves your infrastructure at all.
- Reads are logged - who (and whose instance) read which collection, file or memory. This is the lineage that tells you a second person or instance actually picked up someone's work. Anonymous share-code reads are not recorded (a guest has no identity to attribute the read to).
Both flow into the workspace history at /activity and into the Usage page. Neither is shared outside the workspace.