[Bug][Mobile] Usage fails on mobile although desktop returns usage data #9329

Activity

1. directfilm commented on Sep 4, 2026

   

   directfilm

   on Sep 4, 2026

   Last edited by directfilm

   More actions

   Confirming this independently — same symptom, different setup.

   iOS app 1.0.3, against T3 Code Nightly 0.0.39-nightly.20260904.1274 on macOS 26.6.2. Opening Usage on the phone, on the 30-day window, gives:

   • -- MacBook Pro could not report usage.
   • Raw token cost $0.00*
   • "No activity in this window"
   • Totals all zero: 0 processed tokens, 0 cached input, 0 uncached input, $0.00 cache savings

   This isn't a case of there genuinely being nothing to report. The scan cache on that same machine (~/.t3/userdata/usage-scan-cache.json, version 3) currently holds 242 sessions across 2,980 scanned files and 8 models. The data is on disk; mobile just can't get it.

   Worth flagging as a severity point rather than just a cosmetic one: the failure is not presented as a failure. The "could not report usage" notice sits above a fully rendered report showing $0.00 and zeroes everywhere, which reads as a legitimate result — "you used nothing this month" — rather than as an error. Anyone not cross-checking against desktop would take the zeroes at face value. If the environment can't be reached, suppressing the totals block (or greying it out) would be more honest than rendering zeros into it.
2. KoningSanderPander commented on Sep 5, 2026

   

   KoningSanderPander

   on Sep 5, 2026

   More actions

   Confirming on iOS T3 1.0.3, which reports "Up to date", connected to two environments. Desktop usage works, but mobile shows “could not report usage” for both environments across every time window. Cost and token totals remain zero.

   Reproduced a compatibility failure using a captured server response and the usage schema from the 1.0.3 release:

   Expected "claude" | "codex"
     at ["sources"][2]["fingerprint"]["provider"]
   

   The newer server returns usage contract v5 and includes a grok source even when Grok is unused. The older mobile schema rejects the entire response before the version-handling logic can run.

   As a control, filtering out unsupported providers and returning contract v4 makes the same captured response decode successfully. Changing the version number alone still fails.

   This points to a backward-compatibility regression. The zero totals shown after failure are misleading because the servers have valid usage data.
3. juliusmarminge commented on Sep 26, 2026

   

   juliusmarminge

   on Sep 26, 2026

   Member

   More actions

   Fixed by #10076 — usage buckets/sources now use ForwardCompatibleArray so unfamiliar provider variants (e.g. grok in sources) are skipped instead of rejecting the whole summary. Update the client to pick this up.
4. juliusmarminge

   closed this as completedon Sep 26, 2026