fix: skip elapsed reset times when picking LLMProxy next reset

[OfficialAbhinavSingh]

Summary

LLMProxyUsageFetcher.parseSnapshot(data:updatedAt:) computes the displayed next reset as the globally earliest reset across all quota groups:

let reset = quotaGroups.compactMap { Self.parseDate($0.resetTime) }.min()

There is no future filter, so if any quota group carries an already-elapsed reset_time (a group that rolled over and is momentarily stale until the next refresh), that past date wins the .min() and is surfaced as nextResetAt → RateWindow.resetsAt. A user then sees a "next reset" that is in the past.

Concrete: reset times [2023-11-01 (past), 2023-11-20 (soon), 2023-12-25 (later)] with a snapshot time of 2023-11-14 → shows 2023-11-01; correct is 2023-11-20.

Fix

Ignore reset times at or before the snapshot time (updatedAt) before taking the minimum:

- let reset = quotaGroups.compactMap { Self.parseDate($0.resetTime) }.min()
+ let reset = quotaGroups
+     .compactMap { Self.parseDate($0.resetTime) }
+     .filter { $0 > updatedAt }
+     .min()

This mirrors the existing convention in GrokWebBillingFetcher (filter { $0.date > now }) and ClaudeStatusProbe (first(where: { $0 >= now })). When every reset is in the past, nextResetAt becomes nil (honestly "unknown") rather than a stale past date; downstream (RateWindow.resetsAt) already accepts Date?. Normal all-future data is unchanged.

Test

TestsLinux/LLMProxyResetLinuxTests.swift (via the existing _parseSnapshotForTesting hook):

• past + two future → picks the soonest future (2023-11-20), not the past one
• all-past → nextResetAt == nil
• single future → preserved

Proof (real run)

Runs on CI in the build-linux-cli "Swift Test (Linux only)" step (swift test --parallel). Local red→green in swift:6.3.3, only the .filter line differs:

Before the fix — filter removed, the past reset wins:

✘ "next reset skips already-elapsed reset times":  #require(reset) == 2023-11-20  FAILED  (got 2023-11-01)
✘ "all-past reset times yield no next reset":       reset == nil                  FAILED  (got 2023-10-15)
✔ "future reset time is preserved"                                                passed
✘ Test run with 3 tests in 1 suite failed with 2 issues.

After the fix — all pass:

✔ "all-past reset times yield no next reset" passed
✔ "future reset time is preserved" passed
✔ "next reset skips already-elapsed reset times" passed
✔ Test run with 3 tests in 1 suite passed

Build clean, swiftlint --strict 0 violations, swiftformat --lint clean.

Small and self-contained — happy to adjust or close if the behavior isn't wanted.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 19, 2026, 10:05 AM ET / 14:05 UTC.

Summary
The PR filters parsed LLMProxy quota reset times to those after the snapshot timestamp before taking the earliest one, and adds Linux tests for mixed past/future, all-past, and future-only inputs.

Reproducibility: yes. from source: provide quota groups containing an elapsed reset_time and later future reset times, then parse at a snapshot time after the elapsed value; current main selects the elapsed minimum.

Review metrics: 2 noteworthy metrics.

• Patch scope: 2 files affected; 59 added, 1 removed. The production change is one parser-selection adjustment plus focused Linux regression coverage.
• Regression coverage: 3 cases added. The tests cover mixed elapsed/future values, all elapsed values, and a normal future-only value.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Attach redacted after-fix output from a real LLMProxy quota-stats response showing that a stale elapsed reset does not become the displayed next reset.
• After adding proof, update the PR body to trigger a fresh ClawSweeper review; if it does not rerun, ask a maintainer to comment @clawsweeper re-review.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body supplies red-to-green output only for synthetic fixture tests through _parseSnapshotForTesting; add a redacted after-fix run against a real LLMProxy quota-stats response or runtime output before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Next step before merge

• [P1] No code repair is needed from ClawSweeper; the contributor needs to attach redacted real behavior proof, after which a maintainer can make the normal merge decision.

Security
Cleared: The diff changes only local timestamp selection and synthetic parser tests; it adds no dependencies, execution paths, permissions, secret handling, or supply-chain surface.

Review details

Best possible solution:

Land the date filter with the regression cases after the contributor attaches redacted after-fix output from a real LLMProxy quota-stats response showing an elapsed reset is ignored while the nearest future reset is displayed.

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

Yes, from source: provide quota groups containing an elapsed reset_time and later future reset times, then parse at a snapshot time after the elapsed value; current main selects the elapsed minimum.

Is this the best way to solve the issue?

Yes for the parser bug: filtering timestamps after updatedAt before choosing the minimum is the narrowest solution and preserves all-future behavior; a redacted real-provider response should confirm the API’s stale-value condition before merge.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P2: A bounded provider-usage display bug can show an already elapsed reset time to LLM Proxy users, but it does not threaten availability, credentials, or stored data.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body supplies red-to-green output only for synthetic fixture tests through _parseSnapshotForTesting; add a redacted after-fix run against a real LLMProxy quota-stats response or runtime output before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: A bounded provider-usage display bug can show an already elapsed reset time to LLM Proxy users, but it does not threaten availability, credentials, or stored data.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body supplies red-to-green output only for synthetic fixture tests through _parseSnapshotForTesting; add a redacted after-fix run against a real LLMProxy quota-stats response or runtime output before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current-main behavior: The current parser flattens all provider quota groups and assigns nextResetAt from the minimum parsed reset_time without checking whether it is already elapsed, so a stale past timestamp can win. (Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift:264, 1d307430a13d)
• Narrow affected presentation path: The resulting nextResetAt is passed to both the primary RateWindow.resetsAt and provider-cost reset field, making the incorrect past time user-visible in the LLM Proxy usage display. (Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift:41, 1d307430a13d)
• Existing supported feature: The project’s release notes identify LLM Proxy quota-stats support as an established provider feature, including reset windows; this change corrects its existing behavior rather than adding a new product surface. (CHANGELOG.md, 97ccfff3d0fd)
• Repository policy: The fully read repository guidance prefers focused CLI/parser tests for provider parsing and requires PR evidence; this patch uses a focused Linux parser-test seam, while the evidence gate still requires real after-fix behavior for an external PR. (AGENTS.md:4, 1d307430a13d)

Likely related people:

• steipete: The repository’s published release history attributes the established LLM Proxy quota-stats/reset-window feature to the project’s maintained provider surface; no more specific current-main feature author could be established from the available read-only inspection. (role: repository owner and adjacent provider-feature owner; confidence: low; commits: 1d307430a13d, 97ccfff3d0fd; files: Sources/CodexBarCore/Providers/LLMProxy/LLMProxyUsageFetcher.swift, CHANGELOG.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.