[yourconscience]

Summary

Pi/OMP session JSONL carries the model id (vanilla Pi nests it in message.model; OMP-style forks write it at the envelope level, e.g. openrouter/stealth/ox-alpha), but every entry was hardcoded to model: "pi". This PR:

• attributes each Pi entry to its real model (envelope model → message.model → "pi" fallback), which also makes ModelPricing lookups hit the actual model id
• aggregates a per-model totalTokens breakdown into DailyUsage.models (optional field, backward-compatible decoding — old caches decode fine)
• renders the breakdown as compact per-model rows under the provider section when a day used more than one model

Useful for Pi forks like OMP that route several models (e.g. OpenRouter) through the same session logs.

Test plan

• swift test --filter PiUsageTests — 9 tests pass, including a new test covering envelope-level vs message-level model attribution and the daily per-model breakdown
• one existing assertion updated from the hardcoded "pi" to the fixture's real model id (the old expectation contradicted the fixture itself)
• swift build clean

[chattymin]

Thanks for this — attributing Pi usage to the real model instead of the literal "pi" is right, and handling both the envelope-level and message-level model fields is the correct read of the two writers.

There's a defect that needs fixing before this can go in, and it happens to hit the provider the PR is named for.

LocalUsageReader.daily now returns models, but two providers rebuild DailyUsage by hand instead of passing it through — LocalPiProvider and LocalCodexProvider, at Sources/PokeTokenBar/Core/LocalUsageProvider.swift:186 and :146. Neither forwards the new field, so models is always nil for them. Pi is one of the two, so the per-model breakdown never appears for Pi.

The inverse is also true and probably unintended: the other ten providers return daily(...) directly, so the new popover rows switch on for all of them — Claude, Gemini, Grok, OpenCode, Hermes, omp and the rest. That's a UI change across the whole popover, and it isn't mentioned in the description. Worth deciding explicitly whether you want it everywhere or gated.

On the tests: they pass because they call LocalUsageReader.daily directly, which is the one path where the field survives. The defect lives one layer up, in the provider that repackages the result. A test that goes through LocalPiProvider.fetchDaily() would have caught it.

One more thing to check while you're in there: Pi entries used to carry model: "pi", which matches nothing in ModelPricing, so cost computed to zero. Real model ids will now match the price table. LocalPiProvider overrides totalCost: 0 so nothing leaks today, but that invariant is now spread across two files.

Happy to look again once the field is forwarded.

[yourconscience]

All four are valid. Fixed and pushed.

Defect: LocalPiProvider and LocalCodexProvider no longer rebuild DailyUsage field by field. They take the value from daily(...) and mutate totalCost = 0 on it, so anything the reader adds later (models here) carries through instead of getting silently dropped. Kills the class, not just this case.

Scope: gated to Pi rather than turned on everywhere. daily(...) now takes includeModels: false by default and only Pi opts in, so models stays nil for the other providers and the popover rows don't switch on for Claude, Gemini, Grok and the rest. The breakdown was meant for Pi forks that route several models through one session log. The cross-popover change wasn't intended.

Test: added testLocalPiProviderFetchDailyForwardsBreakdownAndZeroesCost. It runs a two-model fixture (model at the envelope level and at the message level) through LocalPiProvider.fetchDaily() and asserts the breakdown survives the repackaging and cost stays 0. That's the layer that was uncovered. Also pinned the gate: daily(...) without the flag returns models == nil.

Cost invariant: holds. Pi cost is blocked at three layers now. reportsCost = false hides it in the UI, and totalCost is zeroed in both fetchDaily and the period totals. The mutate form keeps that override as one visible line per provider instead of buried in a reconstruction.

[chattymin]

Thank you for your contribution!