Repository navigation
Report pace for the window actually running hot - #256
Conversation
A provider that reports both a weekly and a monthly quota could show a reassuring verdict about the window nobody is spending. OpenCode Go is the clear case: the weekly window sits at 0% while the monthly quota is 61% used against roughly 46% elapsed, and the pane read "Weekly pace · Far below budget · -15.0%" directly beneath a monthly bar whose own marker showed it fifteen points over. The monthly window was doubly unreachable. Pace looked only at the primary and secondary slots, and monthly quotas live in the tertiary slot; even passed in, the cadence test capped at fourteen days and would have rejected it. Selection is now by risk rather than by cadence. Every window the provider reports is a candidate, and the one running hottest against its own clock wins. The twelve-hour floor stays, matching the rule the expected-usage markers already use, so a five-hour session still gets no verdict rather than a meaningless one. The upper bound is gone. An exact tie keeps the window the UI lists first, so the verdict does not hop between refreshes. This is the displayed verdict only. Predictive pace notifications (commands/providers.rs) and `ceiling usage` (cli/usage.rs) still read the primary and secondary slots alone, so a hot monthly quota cannot yet raise a warning. Left for a follow-up rather than changing notification behavior in a release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ceiling | 74e5a4a | Commit Preview URL Branch Preview URL |
Aug 11 2026, 01:43 AM |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughPace selection now evaluates all windows longer than 12 hours, selects the highest pace delta, and uses that window’s label and pace in provider snapshots. Tests cover selection order, short-window exclusion, and ties. ChangesPace selection and snapshots
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/desktop-tauri/src-tauri/src/commands/bridge.rs`:
- Around line 241-244: Use a single captured Utc::now() timestamp for all
usage-pace comparisons and tests: at
apps/desktop-tauri/src-tauri/src/commands/bridge.rs lines 241-244, pass the
shared timestamp to each UsagePace::weekly call; at lines 904-910, pass it to
window_at; and at lines 960-967, use it when building both tie candidates. Run
focused tests, cargo fmt --all, and Clippy with -D warnings, reporting any
skipped checks.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 271d58a3-1f4a-4e7d-ba14-f1110125fd59
📒 Files selected for processing (1)
apps/desktop-tauri/src-tauri/src/commands/bridge.rs
Automated reviewFound 5 issues:
For coding agents: fix BLOCK and FIX IF QUICK findings now; everything else is tracked or informational; never exceed one CodeRev fix round per PR. Advisory. Findings generated by |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Compare every candidate against one captured instant. Each call read the clock separately, so two windows could be judged microseconds apart — harmless in the app, but it meant the tie-break test never built an exact tie and passed for the wrong reason. Name an unnamed window "Extra", the way the bars already do. The tertiary fallback said "Monthly", which would have labeled a verdict for a fourteen-day or weekly window sitting in that slot as monthly, disagreeing with the bar right beside it. Blank provider-supplied titles take the same fallback rather than rendering a verdict with no name. Pace a window of exactly twelve hours. The floor is documented as matching the expected-usage markers, and `expectedPace.ts` skips `minutes < 12 * 60`, so exactly twelve hours draws a marker; a strict `> 720` would have shown that marker with no verdict beside it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary Cuts 1.5.27 and supersedes the 1.5.26 draft, which was built and signed but never published — its Claude account-isolation fix ships here rather than sitting in a draft nobody can install. The stale draft release has been deleted; the `v1.5.26` tag stays as a marker of what was built. Version bumped in all five locations from `VERSIONING.md`, `BUILD_NUMBER=129`, `Cargo.lock` regenerated. ## What's in it Six user-facing entries covering everything merged since the `v1.5.26` tag: - **Cursor on-demand at a glance** (#254, reported in #191) — the reason for cutting this now - **Codex no longer overcharges `gpt-5.1-codex-mini`** (#250) — billed at $1.25/M instead of $0.25/M - **Pace describes the window actually running hot** (#256) - **Concurrent writes can no longer lose settings or credentials** (#245) - **Configured Claude accounts no longer collapse onto one session** (from the unpublished 1.5.26) - **Tab strips can be driven from the keyboard** (#255, closes #219) Browser cookie import (#247) is written up under **Changed** rather than buried in Fixed, since it removes a capability: it says plainly that a provider authenticated that way will ask to be set up again, and that CLI, IDE, OAuth, and Claude Desktop detection are unaffected. The date reads 2026-08-11, matching the established pattern — 1.5.22, 1.5.24, 1.5.25 and 1.5.26 all use the UTC date of their tag, and each was cut late-evening local. ## Validation `scripts\local-check.ps1 -All -Version 1.5.27` passed in full: clippy and tests on both Rust manifests, frontend tests and build, store submission preparation, and release doctor. Release doctor's 3 warnings are all "tag / assets / GitHub release do not exist yet", which is expected before tagging. Two flakes on earlier runs of that script, both confirmed environmental and not regressions: - `cli::tty_runner::tests::test_run_sends_script_through_pty` resolves npm's `cmd` shim as the PTY shell and fails with Windows error 193 unless System32 leads PATH — the same failure recorded in #245 and #247. Worth a follow-up to resolve `cmd.exe` from `%SystemRoot%` rather than PATH. - `TokenAccountsPanel.test.tsx` timed out on a `findByText` under load; it passes in 144ms on its own, against a 1000ms default timeout. ## Not in this release Predictive pace notifications and `ceiling usage` still do not see monthly quotas. Follow-up PR next. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: tsouth89 <tsouth89@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Follow-up to #256, which fixed the displayed verdict but not the toast. Predictive pace warnings looked at the primary and secondary slots alone. A provider reports its monthly quota in the tertiary slot, so a month on course to run dry before it reset could never say so, while the weekly window beside it warned freely. Everything else was already in place: PredictiveWarningWindow::Monthly exists, predictive_window_for already maps anything past fourteen days onto it, and the dedup key includes window_minutes, so a tertiary window cannot collide with the secondary. The candidate list moved out of the loop into predictive_pace_candidates so the set of windows a warning can come from is testable on its own, rather than only observable by emitting a toast. Extra windows stay excluded. The displayed verdict can weigh every window because it shows one; here each candidate raises its own toast, and the extras are supplementary lanes that would multiply warnings rather than add information. `ceiling usage` is still weekly-only, but for a different reason: the CLI never renders tertiary or extra windows at all, so its pace line matches what it prints. Making the CLI monthly-aware means new output lines and belongs on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary Follow-up to #256, which fixed the displayed pace verdict but not the toast. - add the tertiary slot to the windows a predictive pace warning can come from - extract `predictive_pace_candidates` so that set is testable on its own, rather than only observable by emitting a toast ## Why Predictive pace warnings looked at `primary` and `secondary` alone. A provider reports its monthly quota in the **tertiary** slot, so a month on course to run dry before it reset could never say so — while the weekly window beside it warned freely. That is the same blind spot #256 fixed for the on-screen verdict. Everything else was already in place: `PredictiveWarningWindow::Monthly` exists, `predictive_window_for` already maps anything past fourteen days onto it, and the dedup key includes `window_minutes` (`notifications.rs:52`), so a tertiary window cannot collide with the secondary. ## Deliberately not included **Extra windows.** The displayed verdict can weigh every window because it renders one; here each candidate raises its own toast, and the extras are supplementary lanes (Codex Spark, pooled team usage) that would multiply warnings rather than add information. Easy to widen if you'd rather. **The twelve-hour floor.** Display pace skips windows under twelve hours because a marker on a bursty window is meaningless. An explicit "on course to be exhausted before it resets" toast is still actionable for a five-hour session, so warnings keep their existing reach. **`ceiling usage`.** Still weekly-only, but for a different reason than I first thought: the CLI never renders tertiary or extra windows at all (`cli/usage.rs:433-434`), so its pace line is consistent with what it prints. Making it monthly-aware means new output lines and belongs on its own. ## Validation - `cargo test --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml` (489 passed; +3 covering the monthly case, absent slots, and cadence-over-slot naming) - `cargo clippy --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml --all-targets -- -D warnings` - `cargo fmt --all --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml` 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: tsouth89 <tsouth89@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Summary
Why
Reported from an OpenCode Go pane. The weekly window sits at 0% while the monthly quota is 61% used against ~46% elapsed. The pane read "Weekly pace · Far below budget · -15.0%" directly beneath a monthly bar whose own marker showed it fifteen points over. Both statements were true and about different windows; the one carrying the words was the one that did not matter.
An exact tie keeps the window the UI lists first, so the verdict does not hop between equally-hot windows across refreshes.
Scope
This is the displayed verdict only. Predictive pace notifications (
commands/providers.rs:960) andceiling usage(cli/usage.rs:467) still read the primary and secondary slots alone, so a hot monthly quota cannot yet raise a warning. Deliberately left for a follow-up rather than changing notification behavior inside a release.Validation
cargo test --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml(484 passed; +4 covering the reported case, the short-window skip, the promoted-weekly case, and tie-breaking)cargo clippy --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml --all-targets -- -D warningscargo fmt --all --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml -- --checkFrontend is unchanged —
ProviderDetailViewalready renders{pace.windowLabel} pace, so the heading becomes "Monthly pace" on its own.🤖 Generated with Claude Code
Summary by CodeRabbit