Oauth usage endpoint#39
Conversation
…ng out at 5 minute period).
Main had reverted PR HermannBjorgvin#29 (commit 1218454) so this branch could be re-investigated. Branch now contains the original /api/oauth/usage change plus follow-ups a5b5708 (exponential backoff) and 1cbc747 (daemon→device error passing). Conflict resolution keeps HEAD's oauth version for daemon/claude-usage-daemon.sh, daemon/claude_usage_daemon.py, and install.sh, restoring the reverted change. README updates from main are picked up as-is.
|
Me and @tobby168 had some similar discussions in #32 I think maybe it is a related topic, since credentials expiring was also a concern there. There is one quirk about using Claude Code to refresh the credentials and that is that it starts a new 5 hour session for the user which they might not want since a lot of people including me and my coworker have specific times when it works best for us to start a new 5 hour window. Not sure what the best solution is here to be honest. Is the 5 minute window too broad or is it fine? Should we leverage hooks maybe to see a session start event and start fetching usage data at that point for x number of hours? |
For me, the initial up-to-5-minute-delay is totally fine. I'm not really concerned about my usage within the first 5 minutes of my session 😛 . That said, it would be nicer to have a more reactive solution.
I think this would be great. Maybe use watchfiles or something? I imagine ClaudeCode updates some file in the |
|
Yeah wondering what the best non-invasive way to do this is. Perhaps changing the polling to ~5 minute intervals is best, right now it's polling every minute and storing the usage stats for the past 5 polls and using that to calculate the rate and displaying different splash screens based on that. I like this way better indeed, can you tell me how does the splash animations work now did you update the rate calculations to account for the new time intervals? |
I worry this would be too sluggish, especially for Pro ($20) users. I think the 1min interval is fine, no actual limiting happens during real sessions.
I didn't touch any of that calculation since the normal operating rate is still the default 60s |
Would work for Claude desktop users, doesn't give the 5h/7d window in the data that's sent over from what I can tell... maybe they could add it for us? |
…Bjorgvin#39 resilience) Port the endpoint-independent resilience work from upstream PR HermannBjorgvin#39 onto our existing /v1/messages poll path. The PR's headline change — switching to the zero-token GET /api/oauth/usage endpoint — was evaluated and rejected: that endpoint needs an OAuth token with broader scope than the 1-year `claude setup token` the device is provisioned with, so it returns HTTP 403. Confirmed empirically (setup token -> 403, full-scope claudeAiOauth token -> 200, garbage -> 401, proving 403 is a scope issue not expiry). A scope-limited long-lived token and a usage-scoped short-lived token are mutually exclusive for an always-on device, so we stay on /v1/messages. Kept from HermannBjorgvin#39 (all endpoint-independent): - Exponential backoff on consecutive poll failures (60s -> 5min cap) on a counter separate from the Wi-Fi-connect counter, so a rate-limited API can't trip the captive-portal fallback. Cuts TLS-handshake heap churn during outages (SRAM is tight with NimBLE + HTTPS). - Error categorisation: 429 -> WIFI_POLL_RATE_LIMITED ("Rate limited"), 5xx -> WIFI_POLL_API_DOWN ("Anthropic API down"). - 401 now retries 3x with backoff before stopping, to ride out Anthropic auth-server wobbles rather than stopping on the first 401. WIFI_FORK.md documents the scope finding ("Why not /api/oauth/usage?") and the new error states. Verified on device: HTTP 200, s/w/status/reset parsed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 participants
Revamp of #37. Changes from #37:
errfield to the BLE payload. If supplied, the string will be displayed instead ofanim_messages.So here are my findings on the rate-limiting behavior:
So ultimately, in real workflows, the rate-limiting-errors aren't really an issue. It would be nice to somehow detect when we send our first message in a while to instantly update usage (instead of up to 5min of stale data for the initial successful usage poll).