[vietlubu]

Summary

Adds local Pi Agent usage tracking across all persisted sessions.

• Reads JSONL sessions from the default Pi session directory and supports
  PI_CODING_AGENT_DIR / PI_CODING_AGENT_SESSION_DIR overrides.
• Counts direct message, compaction, and branch-summary usage.
• Includes reasoning tokens in output totals and deduplicates copied fork/clone
  history by entry ID.
• Adds Pi as a token-only provider with daily, 5-hour, weekly, and monthly
  totals.
• Updates English, Korean, and Japanese documentation.
• Fixes Swift 6.3 build compatibility by explicitly isolating SwiftUI views
  on the main actor and makes the coverage gate select the LLVM toolchain that
  matches the active Swift compiler.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• Other:

UI changes

No user-visible layout or visual changes. Pi appears as an additional provider
tab when it has usage, using the existing provider-tab UI.

Before	After
Pi Agent usage was not detected or shown.	Pi Agent appears in the existing provider tabs with combined and per-provider token
totals.

Checklist

• swift build and swift test pass locally
• PR title and description are written in English
• UI changes are described above (before/after — images optional)
• No copyrighted assets, secrets, or private tooling references are committed (see CONTRIBUTING)
• Tests were added or updated for this change

[chattymin]

Thanks @vietlubu — the root handling here is careful work: a single piSessionRoots source shared by reader, cache, and tests, normalizedRoots folding the overlap between PI_CODING_AGENT_DIR and PI_CODING_AGENT_SESSION_DIR, and an injected home so the default-path test doesn't touch a real directory. That matches docs/reference/provider-extension.md exactly. I checked the three usage-bearing entry types against upstream and they are complete, and all three READMEs are updated.

I'd like to request two changes before this lands.

1. reasoning is double-counted.

piEntry computes output = output + reasoning, but upstream states reasoning is already inside output (@earendil-works/pi-ai@0.84.2):

• dist/types.d.ts:262-267 — reasoning is "a subset of output: output already includes these tokens."
• dist/api/openai-completions.js:1119 — "OpenAI completion_tokens already includes reasoning_tokens."
• dist/api/anthropic-messages.js:563 — thinking_tokens is "a subset of output_tokens".
• dist/api/google-generative-ai.js:167,170 — Google reports them separately, and pi normalizes by folding them in: output = candidatesTokenCount + thoughtsTokenCount, reasoning = thoughtsTokenCount.
• dist/core/compaction/compaction.js:87 — pi's own total is input + output + cacheRead + cacheWrite, with no reasoning term.

So a turn with output 10,000 of which 8,000 is reasoning is recorded as 18,000. This is the Codex case, not the Gemini case — the Codex reader already notes that output_tokens includes reasoning, while the Gemini reader adds thoughts because there it really is a separate bucket that the source does not fold in. Please drop the addition, and update the PiUsageTests expectations and the README line that describes the behaviour.

2. Please split the Swift 6.3 work into its own PR.

The @MainActor annotations, SwiftUIIsolationTests, @preconcurrency import Darwin, and the test-gate.sh llvm-cov selection are unrelated to Pi Agent. main builds and its test suite runs clean here on Apple Swift 6.3.3, and CI is green, so this targets swift.org/Homebrew 6.3 specifically — which is a decision about which toolchains this project supports. SwiftUIIsolationTests in particular establishes a repo-wide rule that every future View must carry the annotation; that deserves its own PR and its own discussion rather than riding along with a provider.

Two smaller things on the Pi parser, neither blocking:

• Messages with stopReason: "aborted" or "error" are counted here; upstream skips them as not having valid usage data. Was that deliberate? Either answer is defensible, I'd just like it to be a decision rather than a side effect.
• The totalTokens-only fallback assigns the whole total to input, so the per-bucket breakdown is wrong even though the total is right. It is only reachable on malformed lines, so leaving it is fine — a comment saying so would help the next reader.

Separately, the read-failure path you added to collect() — returning nil so the previous blob survives and the stale signature isn't frozen — is a nice touch, and the parser-version bump with a back-compatible snapshot decode is exactly right.

[vietlubu]

@chattymin
Thanks again for the detailed review — all requested changes are now addressed.

• Reasoning accounting: Pi reasoning is now treated as a subset of output, so it
  is no longer added separately. I updated the regression fixtures to preserve Pi’s input + output + cacheRead + cacheWrite == totalTokens invariant and bumped the Pi cache parser
  version so previously inflated cached entries are reparsed.
• Aborted/error messages: messages with stopReason: "aborted" or "error" are now
  deliberately skipped, matching Pi’s valid-usage handling. Both paths have regression
  coverage.
• Malformed totalTokens fallback: this remains as a compatibility fallback, with an
  inline comment clarifying that it preserves the aggregate total only because the original
  bucket split is unknowable.
• Documentation: updated the Pi wording in all three READMEs and recorded the upstream
  usage-contract rule in the defect log.
• Swift 6.3 work: removed from this PR and moved to the separate PR: fix: support swift.org Swift 6.3 toolchains #216.

I also rebased this branch onto the latest main. The Pi-focused tests pass after the
rebase, and the Swift 6.3 branch passes the full test/coverage gate independently.

Thanks for catching the provider-specific reasoning semantics.

[chattymin]

Thank you for your contribution!