Slow Claude usage refresh

[dstier-git]

Summary

The length of time it takes Claude limits to update since a refresh has triggered has ballooned recently. Observed using the "Auto" source for Claude usage.

Claude's refresh time was always slower than Codex and other major providers, but recently it has gotten far slower.

Empirical evidence

Here is a comparison of the amount of time it took today for the most current rate to be fetched from 3 common providers:

	Codex	Cursor	Claude
Time since app is opened	2.31s	1.98s	14.35s
Time since "Refreshing" shows	0.5s	Instant	13.1s

Environment

• Macbook Pro 2024, 24GB RAM, M4.
• CodexBar 0.42.1.
• Claude source="auto"

I cannot say with certainty when this issue began, although it was certainly before CodexBar 0.42.1 (current) and likely less than a full week ago.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 13, 2026, 1:41 AM ET / 05:41 UTC.

Summary
Keep open: the fresh report provides concrete release-build timings, and current evidence does not show that main already resolves the Claude Auto-source latency. The exact slow strategy still needs isolation before a safe fix can be selected.

Reproducibility: no. The report contains credible timings on v0.42.1, but there is no stage-level diagnostic or current-main run identifying which Auto-source strategy causes the delay.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A maintainer should first obtain stage-level timings or authorize a controlled live Claude probe; without that evidence, an automated timeout change could regress loading-state recovery.

Review details

Best possible solution:

Add stage-level timing around the Claude Auto-source strategies, reproduce with a no-UI or explicitly approved live setup, and optimize only the responsible strategy while preserving successful fallback and loading-state recovery.

Do we have a high-confidence way to reproduce the issue?

No. The report contains credible timings on v0.42.1, but there is no stage-level diagnostic or current-main run identifying which Auto-source strategy causes the delay.

Is this the best way to solve the issue?

Unclear. Shortening the CLI timeout may be appropriate, but only after timing data distinguishes slow successful probing from sequential fallback or upstream latency.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report does not identify whether OAuth, browser-cookie import, CLI startup, loading-state retry, or sequential fallback consumes the additional time.
• Reducing a timeout without stage-level evidence could restore stale-data or premature-loading failures previously seen in the Claude CLI path.

Codex review notes: model internal, reasoning high; reviewed against c852c135e10c.

Label changes

Label changes:

• add P2: The provider eventually refreshes, but the substantial regression in one common provider warrants normal-priority investigation.
• add impact:ux-friction: A roughly 13-second refresh indicator makes routine Claude usage checks feel stalled, although it does not fully block the app.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: The provider eventually refreshes, but the substantial regression in one common provider warrants normal-priority investigation.
• impact:ux-friction: A roughly 13-second refresh indicator makes routine Claude usage checks feel stalled, although it does not fully block the app.

Evidence reviewed

What I checked:

• Concrete release reproduction: The reporter measured Claude taking 14.35 seconds after launch and 13.1 seconds after the refresh indicator appeared on CodexBar v0.42.1, while Codex and Cursor completed in roughly two seconds.
• Current Claude pipeline: Current main retains a multi-stage Claude usage fetch path, including Auto-source selection and CLI probing, so the reported delay could come from source fallback or probe-settling behavior and is not disproved by source inspection. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, c852c135e10c)
• Earlier related timing behavior: Regression of #1031 on 0.28.0: "still loading usage data" error reappears with Claude CLI 2.1.148 #1116 documents an earlier Claude CLI PTY path that could observe an intermediate loading state and require a longer retry; that is relevant background but reported a persistent parse failure rather than this latency-only symptom. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, 1dd2804f)
• Release boundary: The report reproduces on the latest supplied release, v0.42.1 at 3e05988. Main is newer at c852c13, but no identified main commit proves that this latency was subsequently fixed. (3e05988f5c5f)
• Repository validation policy: Repository guidance requires parser tests, stubs, or no-UI stores unless a live provider probe is explicitly requested, because real Claude/browser probes may display Keychain prompts. (AGENTS.md, c852c135e10c)

Likely related people:

• steipete: The repository owner is the strongest available routing candidate for the Claude provider pipeline and the compatibility tradeoff around Auto-source fallback; exact line-level ownership remains uncertain. (role: repository owner and likely area integrator; confidence: low; commits: 1dd2804f, c852c135e10c; files: Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.