Pi provider in the Usage dashboard (V2 branch parity) — small PR on offer

[astarktc]

The gap

The Orchestrator V2 branch (#2829) ships Pi as a first-class provider (from #7211), but the Usage page only knows Codex, Claude Code and Grok. Every Pi session — including the ones T3 itself drives — is invisible in cost, tokens and the model breakdown. For anyone running Pi as their main provider the dashboard reads $0 while the real spend is elsewhere.

The mechanism already fits: UsageService scans each provider CLI's own on-disk transcripts (~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions), and Pi keeps the same kind of per-session JSONL under ~/.pi/agent/sessions/**/*.jsonl (PI_CODING_AGENT_DIR-aware), with per-message usage blocks (input / output / cacheRead / cacheWrite / cost / model / provider) that map 1:1 onto the existing UsageRecord.

What we have

We've been running the V2 branch daily with a small patch that adds Pi to the usage dashboard, since 2026-08-19, across five upstream rebases:

• packages/contracts/src/usage.ts — "pi" added to UsageProviderKind.
• apps/server/src/usage/usageTranscripts.ts + usageTranscriptReader.ts — Pi transcript reader (session header + message entries with usage), model normalised as <provider>/<model> so Anthropic-via-Pi and OpenAI-via-Pi rows stay distinguishable.
• apps/server/src/usage/UsageService.ts — one driver === "pi" branch inside the existing per-provider-instance transcript-dir loop, resolving the home through the merged instance environment (same shape as the Codex/Claude branches).
• apps/web/src/components/usage/usageProviders.ts — one presentation entry (driverKind: ProviderDriverKind.make("pi"), so it picks up the shared provider icon).
• Tests: reader fixtures, transcript aggregation, presentation order.

~400 lines including tests; no new dependencies, no schema/migration change (the usage contract version is untouched — pi is additive on the wire).

After

(Before = the same page with only the Codex and Claude Code rows and a $0.70 total; the Pi row and the Pi-served models in the breakdown are what the patch adds.)

Ask

Is this something you'd take as a PR against the V2 branch? Per CONTRIBUTING I'm asking here first rather than opening it cold. If yes I'll open it small and focused (the five files above + tests, before/after screenshots). If Pi-in-Usage is something you'd rather do yourselves or not at all, no problem — we'll keep carrying it locally.

For what it's worth, we double-checked the accounting while running this: UsageAggregator dedupes by provider message id across the whole scan before summing, so resumed Pi sessions (which repeat a shared prefix in a second transcript file) are counted once in the UI. The Pi reader emits the same dedupeKey shape as the other readers, so it inherits that correctly.

[astarktc]

Now that V2 (and Pi) are on main, I've reported the gap as a bug: #14866. The fix is on a clean branch on top of main (https://github.com/astarktc/t3code/tree/pi-usage), and I'm happy to open it as a PR if you want it.

[juliusmarminge]

Feel free to open a PR

[jal-co]

One thing worth settling before this lands: Pi is a harness, not a model vendor. My Pi threads run anthropic/claude-opus-5-5 and openai-codex/gpt-6-sol on the same Claude and ChatGPT subscriptions the Claude and Codex rows already track. With a separate pi row, that spend becomes a third bucket and the Claude and Codex totals undercount.

Every Pi assistant message already carries provider and model, so the reader can attribute by those: anthropic to Claude, openai-codex to Codex, and everything else (deepseek, xai, custom providers) to a Pi row. other examples like OpenUsage already read ~/.pi/agent/sessions for this, so the data is there.

@juliusmarminge if you're open to it, @astarktc perhaps you could expand the prs scope to include this?

[jal-co]

@astarktc I went ahead and opened #15793 with the by-provider attribution so this didn't stall. Your reader was a useful reference, thanks for scoping the problem and the original patch. Happy to add you as co-author, or close mine if you'd rather fold this into yours.

[astarktc]

Thanks @jal-co, and for opening #15793 so it didn't stall. Quick note on sequencing for @juliusmarminge: your go-ahead above predates the attribution proposal, so I don't think that direction has been settled yet. Here's the alternative I'd like you to pick between.

Today's Usage rows are harnesses, and Claude Code and Codex are harnesses too: a GPT model routed through Claude Code already counts in the Claude Code row. Moving Pi's anthropic turns into that row would make it mean "Claude Code, or a subscription that might be Claude's". It also double-counts sessions that use both, and still can't tell an API key from a subscription (#15793 notes this too).

I think the subscription question is better answered by grouping than by reclassifying. A Group by switch next to Cost / Tokens / Limits:

• Harness: today's view, plus a Pi row.
• Model family: Anthropic, OpenAI, Google, xAI, … derived on the client from the model id. A GPT turn through Claude Code lands under OpenAI. For setups like @jal-co's, this shows Claude vs ChatGPT spend across every harness.
• Endpoint: the configured provider each harness records (Pi's provider, Codex's model_provider, OpenCode's providerID). This is exactly feat(usage): count Pi turns toward the subscription they ran on #15793's attribution, as a view instead of rewritten rows. Claude Code doesn't record it, so its rows would be inferred and labelled as such.

My proposal: one PR now with the Pi row plus the family view (client-side grouping, no contract change; the family part is a small extension of what you approved, happy to split it out if you'd rather), and the endpoint view as a follow-up. @jal-co, I'd be glad to have you co-author that follow-up, since the provider attribution is your idea. If you'd rather go with #15793's approach, I'll close mine and help review there instead.

[astarktc]

Opened #15889: the Pi row plus the model-family Group by described above, as separate commits. It includes before/after screenshots from the same machine and history. If you'd rather have the family view as its own PR, or prefer #15793's approach, I'm happy to split or close mine.