Port upstream 0.69.0: mark Kimi windows blocked by an exhausted monthly limit (stacked on #691)

[Finesssee]

Summary

When Kimi's monthly membership pool (kimi-monthly, "Total usage") is exhausted, the shorter Kimi Code windows are shown as blocked, the way upstream 0.69.0 does it. The pool counts as exhausted when its remaining usage is <= 0 and its reset is in the future or unknown. A window without minutes counts as the 5-hour lane.

The affected windows are the primary, the secondary, and the kimi-code-7d extra window.

• Tray panel card (MenuCard): each blocked window shows only its title and a secondary "Blocked by monthly limit" line, matching upstream MetricRow with statusText. It has no bar, percent, reset, pace, reserve or session forecast. The pool's own row keeps its "100% used", reset and "Exhausted" text.

• Settings > Providers > Kimi: each blocked Usage row shows its label and the status with no bar or reset, matching upstream's .status inline row. The Pace section is hidden while its window is blocked.

• The block lifts at the pool's reset. The bridge carries monthlyLimitBlock: { resetsAt }, and the frontend re-checks it at render time. An open card re-renders at the reset, so a cached snapshot from a failed refresh does not stay blocked. If the reset is unknown, the block holds until the next refresh.

• Raw data is unchanged. Snapshot percentages stay the provider's numbers. These surfaces keep showing them, as upstream does:

  • tray icon
  • float bar
  • notifications
  • menu-bar metric
  • provider switcher
  • CLI

  Monthly pools that are unknown, expired or still available never block. Other providers never derive a blocker.

Upstream reference

• Release v0.69.0, fix(providers): clarify Kimi and z.ai quota availability steipete/CodexBar#4091 (with Kimi Code shows unused weekly/5h windows after monthly membership is exhausted steipete/CodexBar#3536):
  • RateWindow.bindingQuotaProjection
  • MenuCardView.blockingQuotaMetrics
  • KimiProviderDescriptor.blockingQuota = ("kimi-monthly", "Blocked by monthly limit")
  • the MetricRow status layout
  • the settings ProviderMetricInlineRow .status
  • KimiMonthlyBlockingTests
• CHANGELOG v0.69.0, Fixed: "Kimi Code: mark shorter windows as blocked when the monthly membership pool is exhausted, without fresh quota or pace forecasts (fix(providers): clarify Kimi and z.ai quota availability steipete/CodexBar#4091, Kimi Code shows unused weekly/5h windows after monthly membership is exhausted steipete/CodexBar#3536)."
• Audit entry kimi-blocking-monthly.

Ported / Deferred

• Ported, Rust core:
  • core::BlockedWindows::evaluate, which also returns the blocker's resets_at and has any().
  • The provider declares its blocker through ProviderId::blocking_quota_window_id. Only Kimi has one (kimi::MONTHLY_WINDOW_ID).
• Ported, bridge:
  • MonthlyLimitBlockSnapshot { resetsAt } on RateWindowSnapshot and PaceSnapshot (commands/bridge/quota_block.rs).
  • bridge.ts MonthlyLimitBlock.
• Ported, frontend:
  • lib/monthlyLimitBlock.ts and the useMonthlyLimitBlockNow hook.
  • The blocked MenuCard row.
  • Hiding the pace in describeCard.
  • Settings UsageSection and PaceSection.
  • .menu-metric__status and .provider-usage-bar__status styles.
• Ported, locale: PanelBlockedByMonthlyLimit in locale.rs, keys.ts and every .ftl. Upstream ships only English for this string, so the non-English texts are Windows translations.
• Ported, tests:
  • KimiMonthlyBlockingTests → rust/src/providers/kimi/monthly_blocking_tests.rs, run through the Kimi web parser.
  • BlockedWindows unit tests.
  • Bridge tests in quota_block.rs.
  • Vitest coverage for MenuCard, UsageSection, PaceSection, the lib and the hook.
• Deferred / not changed:
  • No projected reset is computed. The blocker's own reset owns the reset text, as upstream.
  • The status string is a locale key rather than a per-provider message. Kimi is the only blocker today.
  • commands/bridge.rs was already over 1000 lines at the base (1068). It grows by a net 18 lines, and the block logic lives in the new quota_block.rs.

Validation

Run on b97eb75. ee19721 only adds the CHANGELOG entry.

Check	Result
cargo +1.98.0 fmt --all --check	pass
cargo +1.98.0 clippy --workspace --all-targets -- -D warnings	pass
cargo +1.98.0 test -p codexbar	2262 passed, 0 failed, 1 ignored
cargo +1.98.0 test -p codexbar-desktop-tauri	481 passed, 1 failed: bootstrap_payload_exposes_every_provider_variant, see note below
pnpm --dir apps/desktop-tauri install --frozen-lockfile	ok
check-locale	876 keys OK
lint	0 errors
test	69 files, 415 tests passed
build	pass

The desktop failure is environment-dependent: the test reads the host's settings. It is the known #684 failure, fixed by #711, and fails the same way at the base.

Review and validation details: #697 (comment)

Affected areas

• Kimi provider windows
• Rust core blocking_quota
• Bridge DTOs (RateWindowSnapshot, PaceSnapshot)
• Tray panel card (MenuCard)
• Settings > Providers Usage and Pace sections
• Locale catalog
• CHANGELOG

UI proof

browser-use proof at ee19721, all checks pass: #697 (comment)

• Scenarios. It covers the blocked, unknown-reset, lift-at-reset and available (control) scenarios, in the tray panel and in Settings > Providers > Kimi.
• Checks. Every screenshot was preceded by a no-personal-data check. Dark theme under auto was checked through matchMedia and computed colors.
• Lift. The open card unblocked 4 ms after the seeded pool reset, with no interaction.
• Not covered. The native tray icon, float bar, notifications and menu-bar metric are covered by unit tests only (native, browser-use per maintainer). They keep raw percentages by design.

The earlier CUA proofs were taken at c220563 and show the old rendering, a 100% bar.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Finesssee]

Thermo-nuclear review

Reviewed against upstream v0.69.0 steipete#4091 (RateWindow.bindingQuotaProjection, MenuCardView.blockingQuotaMetrics, KimiProviderDescriptor.blockingQuota) and AGENTS.md. Diff reviewed relative to the stacked base (#691's head).

Verdict: no blockers. Behavior matches the spec.

Spec parity (checked line by line):

• Blocker must be a known-usage kimi-monthly window that is longer than the candidate, has remaining <= 0, and has a reset in the future or unknown. is_blocked_by matches isActivelyExhausted plus the minutes > primaryMinutes filter, including the 5h default for a window with no minutes.
• Blocked rows read 100% used, with reset, pace, reserve and forecast cleared. The pool row keeps its reset. Raw percentages stay untouched in the snapshot, so tray, notifications and explicit menu-bar selections keep the provider data (per spec).
• Provider-declared blocker (ProviderId::blocking_quota_window_id) is the Rust equivalent of the descriptor's blockingQuota. No cross-provider string branching in shared paths. Other providers derive nothing (tested).
• Size: no file crosses 1000 lines (bridge.rs and provider.rs were already over and grew by about 15 and 9 lines; MenuCardDetails.tsx is 836).

Findings (fixed in the follow-up commit):

1. MetricRow gained three separate blocked conditionals (blocked label, !blocked && on the exhausted label, forecast). The two label branches were the same slot with two guards. Collapsed into one statusLabel value so there is a single place that decides what the status line says.
2. BlockedWindows tests never asserted the tertiary and model_specific flags as true, so those two arms of evaluate were untested. Added assertions.

Left as is (non-blocking):

• The DTO field blockedByMonthlyLimit and the PanelBlockedByMonthlyLimit string are Kimi-shaped names on a generic mechanism (blocking_quota_window_id). Upstream carries the message per provider policy. With one provider that is fine; the message should move into provider metadata when a second blocker lands. Renaming now would churn about ten files for no behavior change.
• toBlockedSnapshot also clears reserve fields that are already gated by isExhausted in getMetricPaceView. It is redundant but explicit, and cheap.
• The flag is computed when the snapshot is converted, so a monthly reset passing between refreshes unblocks on the next refresh rather than instantly. The provider's own 100% would be equally stale until then.

Local checks after the fixes: cargo +1.98.0 fmt --all clean, clippy -p codexbar --all-targets -D warnings pass, test -p codexbar blocking_quota 5 passed, vitest MenuCard.test.tsx 33 passed.

[Finesssee]

Follow-up to the thermo-nuclear review: pushed c220563 ("Address thermo review").

Fixed:

• MetricRow now derives one statusLabel (blocked text, else the exhausted label in the full card) instead of two guarded branches. No behavior change.
• Added tertiary and model_specific assertions to the BlockedWindows tests.

Left, with reasons: Kimi-shaped DTO/locale names on the generic mechanism (one provider today, rename would touch about ten files), redundant reserve clearing in toBlockedSnapshot (explicit and harmless), and fetch-time flag evaluation (matches when the provider data itself refreshes).

Checks: fmt clean, clippy -D warnings pass on codexbar, blocking_quota tests 5 passed, MenuCard.test.tsx 33 passed.

[Finesssee]

CUA proof

Build commit: c220563 (PR head) plus one uncommitted proof-only patch, not part of the PR: rust/src/logging.rs config_root() also honors CODEXBAR_PROOF_CONFIG_ROOT (isolated config, user settings untouched).

Data path: seeded via the existing CODEXBAR_SEED_USAGE_JSON proof support (bridge-shaped Kimi snapshot carrying blockedByMonthlyLimit). This proves the React rendering; the Rust derivation is covered by the unit tests (blocking_quota tests + bridge test).

Commands: bash launch.sh popOut blocked and bash launch.sh popOut available (prebuilt debug exe, no rebuild, empty provider homes, only Kimi enabled, theme auto); driven with cua-driver serve / call list_windows|get_window_state|click (select Kimi tab, capture UIA tree + screenshot).

Note: the "All" overview is compact (first two rows only), so the four-row checks were made on the Kimi tab of the pop-out; the tray panel overview showed the same Weekly / Rate limit rows with "Blocked by monthly limit".

Scenario A: monthly pool exhausted

#	Assertion	Result
1	Four rows: Weekly, Rate limit, Total usage, Code 7-day	PASS
2	Weekly, Rate limit, Code 7-day read "100% used", full bar, "Blocked by monthly limit"	PASS
3	Those rows show no reset text, no reserve / pace / "On-pace budget" lines; Weekly not "0% used"	PASS
4	Total usage "100% used", own reset "Resets in 19d 23h", shows "Exhausted", no blocked line	PASS
5	Exactly one reset text; "Blocked by monthly limit" exactly 3 times	PASS
6	No other-provider identity; theme stays dark under auto	PASS

Scenario B: control (monthly 50%)

#	Assertion	Result
1	Weekly 0% used with "Resets in 3d 23h", Rate limit 0% used with reset, Code 7-day 25%, Total usage 50%	PASS
2	"Blocked by monthly limit" absent	PASS

Screenshots (local, not committed), under %LOCALAPPDATA%\Win-CodexBar\port-audit\proof\697\shots\:

• A-blocked-popout-kimi.png
• A-blocked-popout.png (overview)
• A-blocked-tray.png (tray panel)
• B-available-popout-kimi.png

No real personal data appears in any screenshot.

[Finesssee]

CUA proof (rerun)

Build commit: c220563 (PR head, "Address thermo review"). Rerun on a rebuilt debug exe with profile isolation: home, config, data and cache dirs all resolve under a proof-only directory, so no real account or settings from the machine are read.

Proof-only patch (uncommitted, reverted after the build, not part of the PR): root Cargo.toml [patch.crates-io] dirs = { path = ".../proof-shim/dirs" } redirecting dirs lookups to CODEXBAR_PROOF_HOME. No source file patched.

Data path: bridge-shaped Kimi snapshot via the existing CODEXBAR_SEED_USAGE_JSON proof support (Kimi monthly pool comes from a hardcoded https web host, so it is not mockable without weakening URL validation). This proves the React rendering of blockedByMonthlyLimit; the Rust derivation is covered by the PR's unit tests. No keyring or network access.

Commands: pnpm --dir apps/desktop-tauri run tauri:build:debug, then CODEXBAR_PROOF_MODE=popOut:provider:kimi launched with dummy keys and empty provider homes (scenario "blocked": Weekly 0%, Rate limit 0%, Code 7-day 25%, Total usage 100%; scenario "available": Total usage 50%). Window captured with cua-driver call get_window_state --screenshot-out-file (background only, window kept on a secondary monitor).

Scenario A: monthly pool exhausted

#	Assertion	Result
0	No real email/account from the machine visible	PASS
1	Four rows: Weekly, Rate limit, Total usage, Code 7-day	PASS
2	Weekly, Rate limit, Code 7-day read "100% used", full bar, "Blocked by monthly limit" (Weekly not "0% used")	PASS
3	Those rows show no reset text, no reserve / "On-pace budget" / forecast line	PASS
4	Total usage "100% used", own reset "Resets in 19d 23h", "Exhausted", no blocked line	PASS
5	Exactly one reset text; "Blocked by monthly limit" exactly 3 times	PASS
6	Dark theme under auto; no other-provider text	PASS

Scenario B: control (monthly 50%)

#	Assertion	Result
1	Weekly 0% used "Resets in 3d 23h", Rate limit 0% used "Resets in 59m", Code 7-day 25%, Total usage 50%	PASS
2	"Blocked by monthly limit" absent	PASS

Screenshots (local, not committed), in %LOCALAPPDATA%\Win-CodexBar\port-audit\proof\697\shots\:

• n-A-blocked-kimi.png
• n-B-available-kimi.png

No personal data appears in either screenshot.

[Finesssee]

Lane A review: fixes at ee19721

I reviewed the whole diff against the base, #691 at 73307e9, which is merged in as 33356bc. I compared it with upstream v0.69.0 steipete#4091:

• MenuCardView.blockingQuotaMetrics
• RateWindow.bindingQuotaProjection
• the MetricRow status layout
• the .status case of the settings ProviderMetricInlineRow
• KimiMonthlyBlockingTests

The fixes are in b97eb75. ee19721 only adds the CHANGELOG entry.

Defects found and fixed

1. The block stayed after the pool reset. blockedByMonthlyLimit was decided once, at fetch time. The provider cache keeps the last good snapshot through failed refreshes, so a row stayed "blocked" after the monthly pool reset until a fetch succeeded. Upstream re-evaluates isActivelyExhausted(now) every time it builds the card.

   • The bridge now carries monthlyLimitBlock: { resetsAt } (the pool's reset) instead of a bool. resetsAt: null means the reset is unknown, and the block holds.
   • The frontend re-checks the block at render time (lib/monthlyLimitBlock.ts).
   • useMonthlyLimitBlockNow schedules a re-render at the earliest reset, re-arming at most every 6 h so long timers are not clamped. An open card unblocks on time.

2. Blocked rows did not match upstream. They showed a full bar, "100% used" and the label. Upstream's MetricRow with statusText shows only the title and one secondary status line: no bar, percent, reset, pace, reserve or forecast. MenuCard now renders exactly that, and toBlockedSnapshot (the 100% rewrite) is gone.

3. Settings were not covered. Upstream's settings row uses .status for a blocked metric, but Settings > Providers > Usage still showed the raw bars and their resets.

   • Blocked rows there now show the label and status only.
   • The Settings Pace section is hidden while its window is blocked.

4. The provider-level pace was not hidden. Upstream drops the pace of a blocked metric. The provider pace (the tray card pace line and Usage details, plus the Settings Pace section) comes from the primary window, or from the weekly lane when the primary is informational. It now carries that window's block (PaceSnapshot.monthlyLimitBlock, built by MonthlyLimitBlockSnapshot::for_pace).

5. The locale string was English-only. PanelBlockedByMonthlyLimit was only in en-US. Upstream has no translations for it, so it falls back to English. I added it to es-MX, ja-JP, ko-KR, ru-RU, tr-TR, zh-CN and zh-TW. It was already in locale.rs and keys.ts.

6. The upstream tests were not translated. rust/src/providers/kimi/monthly_blocking_tests.rs ports KimiMonthlyBlockingTests and runs through the real Kimi web parser. It covers three cases:

   • An exhausted membership blocks the fresh Code windows without changing their raw usage.
   • Ratios 0.5 and 0.999 do not block.
   • The block ends exactly at the pool reset.

   BlockedWindows now also records the blocker's reset (resets_at, any()), and its tests cover both of those.

Kept as is

• core::BlockedWindows::evaluate and ProviderId::blocking_quota_window_id: Kimi only, and declared by the provider.
• Raw percentages stay in the snapshot. As in upstream, where the projection only affects the menu card, these keep the provider's numbers:
  • tray icon
  • float bar
  • notifications
  • menu-bar metric
  • CLI
  • provider switcher

Scope and size

• commands/bridge.rs is 1086 lines. It was already over 1000 at the base (1068). This PR adds a net 18 lines and moves the block logic into the new commands/bridge/quota_block.rs (155 lines, with 4 tests).
• All other touched files are under 1000 lines: MenuCardDetails.tsx is 836 and MenuCard.test.tsx is 973.
• No new dependencies and no new logging.
• Provider data stays siloed: other providers never derive a blocker from a window with the same name (tested).

Validation

Run on the tree committed as b97eb75:

Check	Result
cargo +1.98.0 fmt --all --check	pass
cargo +1.98.0 clippy --workspace --all-targets -- -D warnings	pass
cargo +1.98.0 test -p codexbar	2262 passed, 0 failed, 1 ignored (focused blocking_quota / monthly_blocking / kimi: 94 passed)
cargo +1.98.0 test -p codexbar-desktop-tauri	481 passed, 1 failed: bootstrap_payload_exposes_every_provider_variant, see note below. Focused quota_block: 4 passed.
pnpm --dir apps/desktop-tauri install --frozen-lockfile	ok
pnpm --dir apps/desktop-tauri run check-locale	876 locale keys OK
pnpm --dir apps/desktop-tauri run lint	0 errors. The warnings are all in lines this PR does not change.
pnpm --dir apps/desktop-tauri test	69 files, 415 tests passed
pnpm --dir apps/desktop-tauri run build	pass

The one desktop failure is environment-dependent and not caused by this PR. The test reads the host's settings through Settings::load(). It is the known #684 failure, fixed by #711, and fails the same way at the base.

New frontend tests:

• MenuCard.test.tsx: blocked rows show the title and status only; a block with an unknown reset holds; a cached block whose reset has passed is ignored; an open card unblocks at the reset (fake timers).
• UsageSection.test.tsx: blocked and expired-block cases.
• PaceSection.test.tsx (3 tests), lib/monthlyLimitBlock.test.ts (4) and hooks/useMonthlyLimitBlockNow.test.tsx (2).

Mutation check: removing the blocked-row early return, the hook's timer tick, or the PaceSection block check each makes the new tests fail.

The earlier CUA proofs were taken at c220563, which used the old rendering. A browser-use UI proof at this head follows.

[Finesssee]

UI proof (browser-use)

Result: all checks pass at ee19721, the current head. Six launches covered four data scenarios, in the tray panel and in Settings > Providers. I launched unknown and lift twice each, and the results below come from the second launch of each. For unknown, a repeated script run had overwritten its overview screenshot. For lift, see the lift note.

Setup

• Build. I built the debug exe from this commit in a lane worktree: pnpm --dir apps/desktop-tauri install --frozen-lockfile, then pnpm --dir apps/desktop-tauri run tauri:build:debug.
  • The only proof-only change was a throwaway [patch.crates-io] dirs shim in the root Cargo.toml, plus the Cargo.lock line it causes. Both were restored right after the build and are not in this PR.
• Driver. The browser-use CLI ran over the proof exe's own WebView2 CDP port (9351).
  • Before every run, json/version answered Edg/154, and the 9351 listener was a child of the proof exe.
  • There was no desktop input and no focus change. A window guard moved the proof windows to the second display without activating them.
  • The only page interactions were DOM-driven: selecting the Kimi provider tab in the tray panel, and opening "Usage details" in the control scenario.
• Isolation.
  • Kit profile: USERPROFILE, APPDATA, LOCALAPPDATA and TEMP all point inside the proof kit.
  • Settings: only Kimi is enabled, theme is auto, there is no global shortcut, and Kimi cookie import is off.
  • API-key and proxy variables are unset.
• Data.

  • The data comes from CODEXBAR_SEED_USAGE_JSON with one Kimi snapshot in this head's bridge shape (monthlyLimitBlock: { resetsAt }). The seed is regenerated at every launch, so resets are relative to the launch time.

  • The monthly pool normally comes from Kimi's hardcoded https web host. No URL override was added, and TLS and URL validation are unchanged.

  • The raw data is the same in every scenario:

    Window	Raw usage	Resets in	Other
    Weekly	0%	4 d	reserve
    Rate Limit	0%	1 h
    Code 7-day	25%	4 d

  • Only the pool ("Total usage") differs:

    Scenario	Pool
    blocked	100%, resets in 20 d
    unknown	100%, reset null
    lift	100%, resets 100 s after launch
    available (control)	50%

Results

#	Check	Result
A0	Before every screenshot, the DOM has no email-like text and no .menu-card__email node. The seed carries no account.	PASS (11 of 11)
A1	Theme auto in every launch: matchMedia('(prefers-color-scheme: dark)') true, data-theme="dark", body background rgb(28, 28, 30), text rgb(245, 245, 247).	PASS
A2	blocked and unknown, tray overview: Weekly and Rate Limit render as .menu-metric--blocked rows with only the title and "Blocked by monthly limit". There is no bar, percent or reset.	PASS (both)
A3	blocked, Kimi card: Weekly, Rate Limit and Code 7-day are status rows. "Total usage" keeps its bar, "100% used", its reset and "Exhausted". There is no pace section, and the raw "25% used" and "in reserve" texts are absent.	PASS
A4	blocked, Settings > Providers > Kimi: the first two Usage rows and "Code 7-day" show their label and "Blocked by monthly limit", with no track or reset. "Total usage" keeps its bar ("Exhausted", "Resets in 19d 23h"). There is no Pace section.	PASS
A5	unknown (pool reset null): the same status rows as A3. The pool row has a bar, "100% used" and "Exhausted", and no reset text.	PASS
A6	lift: see the timeline below this table.	PASS
A7	available (control): the tray overview and card show raw bars (0 / 0 / 50 / 25 % used) and no status rows. The reserve and pace are present ("Slightly ahead (-12.0%)" under Usage details). Settings shows four bars and the Pace section.	PASS

A6 timeline:

1. Before the reset, Weekly, Rate Limit and Code 7-day were blocked and there was no pace.

2. The seeded reset was at 04:31:25.076Z. The open card unblocked by itself 4 ms later, with no click, reload or refresh.

3. A MutationObserver snapshot at that moment shows the rows with bars and the pace back ("Slightly ahead (-12.0%)"):

   Row	Shown
   Weekly	0% used
   Rate Limit	0% used
   Total usage	100% used, "Resets in 0m"
   Code 7-day	25% used

4. The screenshot was taken 34 to 82 ms after the reset.

Lift note. The app's existing reset-time refresh fired 1047 ms after the reset. useProviders schedules refresh() 1 s after the next reset; this PR does not change that.

• The proof kit has no Kimi credentials and cookie import is off. That refresh therefore replaced the seed with the existing source error "Source mode 'Cli' not supported for this provider".
• My first lift run read the card after that refresh and failed for that reason.
• The script now snapshots the card synchronously at the lift and takes the screenshot inside that 1 s window.
• With real credentials, that refresh just re-fetches the pool.

Screenshots

They are in port-audit\proof\697\shots-bu\. I inspected every one by eye: all are dark, and none shows personal data.

File	Shows
01-blocked-tray-overview.png	blocked, tray overview
02-blocked-tray-kimi.png	blocked, Kimi card
04-blocked-settings-kimi.png	blocked, Settings > Providers > Kimi
01-unknown-tray-overview.png	unknown, tray overview
02-unknown-tray-kimi.png	unknown, Kimi card
05-lift-before-reset.png	lift, before the reset
06-lift-after-reset.png	lift, after the reset
01-available-tray-overview.png	available, tray overview
02-available-tray-kimi.png	available, Kimi card
03-available-tray-kimi-details.png	available, Kimi card with Usage details open
04-available-settings-kimi.png	available, Settings > Providers > Kimi

Not covered (native, browser-use per maintainer)

The tray icon pixels, float bar, notifications and menu-bar metric are not covered by this proof.

• By design they keep raw percentages, as upstream does. Only the bridge (commands/bridge.rs, commands/bridge/quota_block.rs) consumes BlockedWindows.
• The tray, float-bar, usage-metric and PowerToys code only gains monthly_limit_block: None in struct literals.
• Unit tests that cover this:
  • core::blocking_quota (5 tests)
  • commands::bridge::quota_block (4 tests, including exhausted_kimi_monthly_pool_marks_shorter_windows_without_changing_raw_usage)
  • providers::kimi::monthly_blocking_tests (3 tests)
  • the existing tray_presentation_tests
  • Vitest useMonthlyLimitBlockNow, monthlyLimitBlock, MenuCard, UsageSection and PaceSection

Seen outside this PR (not changed here)

• Settings > Providers > Kimi > Usage labels the first two windows with the generic "Session" and "Weekly". The tray calls them "Weekly" and "Rate Limit". This predates this PR: UsageSection.tsx uses ProviderSessionLabel and ProviderWeeklyLabel for every provider.
• The card subtitle reads "1 minutes ago". UpdatedMinutesAgo in en-US.ftl has no singular form.

[Finesssee]

Shipped in v0.70.0: this PR's head is included in main via #735 (merge commit 9d0a37a). Closing as integrated.