Deficit/Reserve calculation

[ChrisGVE]

I have noted that just after the weekly reset (Claude), I tend to drop relatively quickly into a deficit, however it levels up after a few days in general.

This reminds me of the time estimate for copying files in older Windows OS: at the beginning small fluctuations make the estimate vary a lot, and the more progress is made, the more precise the estimate becomes, and of course toward the end it is no longer really an estimate, i.e. if 99% of the time has passed, the estimate remaining time is bang on.

I feel the same is happening with CodexBar, now it could be that I change my behavior because of CodexBar (which might be at least partially correct) or that the estimate is based on a too short baseline to be a robust estimate. I cannot say which is which.

In the event my assumption around a too short baseline is right, have you tried to use the previous week as an estimator helper, basically calculating the deficit/reserve on a rolling window until the current time and projecting the rate of usage until the end of the reset period? This would require to store some data from reset to reset, but I don't think that a lot of measures are necessary to improve the estimate.

I would love to look into it, but I am swamped unfortunately.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 19, 2026, 5:33 PM ET / 21:33 UTC.

Summary
Keep open for maintainer product direction. Current main deliberately uses a live linear reset-window calculation for Claude; historical learned pacing is implemented only for Codex, so this is a new forecast feature rather than a demonstrated bug.

Reproducibility: not applicable. this proposes a different forecasting model rather than a reproducible failure of the current calculation.

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.

Maintainer decision needed

Question	Recommendation
Should CodexBar add an account-scoped historical forecast for Claude weekly pace instead of retaining the shared linear reset-window calculation?	Keep the shared estimator: Retain the current Claude live-window reserve/deficit calculation and treat this as a considered enhancement request.

Why: This changes forecast semantics and adds persisted provider data; current source intentionally limits learned curves to Codex because its dashboard supplies an account-scoped daily curve.

Next step
A maintainer must choose the forecast and persistence policy before a safe implementation can be scoped.

Review details

Best possible solution:

If sponsored, add an account-scoped Claude historical forecast with a defined minimum history, transparent fallback to the current linear estimate, and focused ownership and forecast tests.

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

Not applicable: this proposes a different forecasting model rather than a reproducible failure of the current calculation.

Is this the best way to solve the issue?

Unclear: prior-period data may improve a personal forecast, but its retention, ownership, and fallback policy need maintainer direction first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Persisting and interpreting Claude history needs clear account ownership, reset-boundary, privacy-retention, and fallback rules; otherwise forecasts can be misleading or cross-contaminate accounts.

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

Label changes

Label changes:

• add P3: This is a speculative forecast-quality enhancement, not a demonstrated failure of the existing pace contract.
• add impact:ux-friction: Early-cycle estimates may be less useful, but users retain current quota, reset, and pace information.
• add issue-rating: 🌊 off-meta tidepool: 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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative forecast-quality enhancement, not a demonstrated failure of the existing pace contract.
• impact:ux-friction: Early-cycle estimates may be less useful, but users retain current quota, reset, and pace information.

Evidence reviewed

What I checked:

• Current Claude calculation: The shared pace function derives expected usage solely from elapsed time in the active reset window and projects run-out from current usage; it has no prior-period input. (Sources/CodexBarCore/UsagePace.swift:71, e7779924f98a)
• Historical pacing is intentionally Codex-only: The usage store documents that only Codex has an account-scoped daily curve for learned pace; all other providers, including Claude, use the generic linear calculation. (Sources/CodexBar/UsageStore+HistoricalPace.swift:19, e7779924f98a)
• Existing test contract: Tests verify that Codex preserves its historical estimate while generic quota providers use the linear calculation, establishing the present boundary. (Tests/CodexBarTests/HistoricalUsagePaceBackfillAuthorityTests.swift:354, e7779924f98a)
• Feature provenance: Blame attributes the Codex-only learned-pace boundary and evaluator to the v0.53.0 commit, which is contained by main and tag v0.53.0. (Sources/CodexBar/UsageStore+HistoricalPace.swift:19, 5a2a70458d95)
• Vision fit: VISION.md permits small UX work but requires sign-off for new features and behavior affecting data storage, both implicated by persisted Claude history. (VISION.md:8, e7779924f98a)

Likely related people:

• Peter Steinberger: Git blame attributes the Codex-only learned-pace branch and historical evaluator to the commit that shipped in v0.53.0. (role: current learned-pace implementation author; confidence: high; commits: 5a2a70458d95; files: Sources/CodexBar/UsageStore+HistoricalPace.swift, Sources/CodexBar/HistoricalUsagePace.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.

[steipete]

Triage note: this is real — the pace/deficit stripe compares linear elapsed-time against actual usage, so right after a weekly reset a single burst reads as a large deficit that "levels out" as the window accumulates baseline. Your Windows-file-copy analogy is exactly the failure mode of a linear extrapolation on a short baseline.

Options worth weighing (needs an owner call on direction before anyone builds it):

1. Confidence damping: scale the deficit display by elapsed-window fraction, so the stripe stays neutral-ish for the first ~10–15% of a window.
2. Personal usage curve: learn a per-window usage shape from history (most people don't spend linearly) and pace against that instead of a straight line.
3. Do nothing but label it: show "early in window — estimate rough" the way file-copy dialogs eventually learned to hedge.

Option 1 is cheap and safe; option 2 is the "right" fix but adds state and edge cases. Related: the "Show pace" toggle just shipped (#3055) if the early-window noise bothers you enough to hide the stripe today. Parking for @steipete's direction.