Usage: support token sources that aren't coding agents

What problem are you trying to solve?

I track Claude Code and Codex through the Usage tab, but some of my token spend goes to a model API that Superset has no way to see. In my case it is TypeSafe's System One ("jev"), a classification endpoint that returns a calibrated probability rather than text, called from a thin CLI we wrote ourselves. It reports usage on every call ({"input_tokens": 271, "output_tokens": 20}), so the data exists; it just has nowhere to go.

Reading the shipped scanner, discovery is per-agent: each supported agent has its own root and parser, and RATES_BY_AGENT lists twelve of them. A log directory belonging to no registered agent yields no entries at all, and the "unknown" model fallback does not help, because it only covers a missing model name inside an agent that is already being scanned.

So rather than writing a parser and hoping, I would like to ask the scoping question first: is usage tracking meant to cover coding agents specifically, or any token source a user cares about?

I am aware this is the stronger version of the ask, since the same payload feeds the leaderboard as well as the Usage tab. If the answer is "coding agents only, and the leaderboard is why", that is a perfectly good answer and worth having written down.

Proposed solution

If you are open to more sources, two possible shapes:

1. A typesafe agent like the existing ones: a sessions root, a parser, and a rates table. I already have the CLI writing ~/.typesafe/sessions/<session>/events.jsonl in the same shape fx uses (session_started plus cumulative usage_checkpointed events), so the parser is close to a copy of the fx one. Happy to open that PR.
2. A documented generic format any tool can write, so sources like this do not each need a core patch. More work up front, but it turns a recurring class of request into configuration.

Workarounds you've tried

Writing the records into an existing agent's root would get them counted, but they would then publish under that agent's provider name, which is simply wrong, so I have not done it. For now the log accumulates locally and nothing reads it.