[Pillumz]

Summary

• collect only Kimi plan-quota windows, with stable IDs and explicit 5-hour duration
• fall back to Pi's refreshed kimi-coding OAuth bearer when Kimi CLI has no sign-in
• allow an explicit plan label such as Ultra in ~/.config/omarchy/agents/kimi.json
• display small nonzero usage as <1% in agent limit tooltips
• document the collector behavior and configuration

The separate request-rate allowance is intentionally excluded.

Verification

• Focused Kimi collector and regression tests passed
• Agent panel and limit-helper tests passed
• Live Pi OAuth collection produced fresh 5h/monthly quota with the Ultra label
• Real panel inspected in a disposable Omarchy VM: Kimi Ultra, Session and Monthly rows rendered without clipping
• Broader shell suite: 476 files ran; 16 failed. Seven reproduce identically on the untouched baseline, and nine pass when isolated from the owner's untrusted mise configuration. No unrelated repair was attempted.

AI provenance

Implemented and reviewed by Kimi K3.1 Pro. Review covered plan-quota versus request-rate semantics, OAuth/credential boundaries, snapshot compatibility, and visual behavior. Remaining verification limitation: the seven pre-existing baseline shell failures listed in the run log.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The PR changes the bounded Kimi quota workflow and shared agent-panel tooltips.

The PR appears safe to merge, with a non-blocking concern that background refreshes can install Pi without the user choosing it.

Findings

1.  Background refresh installs Pi ▶

Summary

Adds Pi OAuth fallback, configurable Kimi plan labels, and stable quota-window metadata.

• Kimi quota records identify each plan window.
• Kimi quota checks can use Pi's Kimi sign-in.
• Kimi records can show a chosen plan name.
• Agent limit tooltips keep tiny usage visible.

Pillumz explicitly states that the separate request-rate allowance is intentionally excluded.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Kimi usage refresh] --> B{KIMI_API_KEY set?}
  B -->|Yes| F[Fetch quota]
  B -->|No| C{Kimi access token exists?}
  C -->|Yes| D[Use or refresh Kimi token]
  D --> F
  C -->|No| E{Explicit KIMI_CODE_HOME?}
  E -->|Yes| H[Report unavailable]
  E -->|No| P[Launch Pi bearer command]
  P --> I[Lazy launcher may install Pi]
  I --> J{Bearer returned?}
  J -->|Yes| F
  J -->|No| H

Loading

_{Reviews (1) · Last reviewed commit: "Improve Kimi plan quota reporting" · Reviewed by Greptile}

[greptile-apps]

Background refresh installs Pi

pi_bearer_token() launches pi whenever Kimi has no sign-in, even if the user has never used Pi. Normal background refreshes include Kimi, and Omarchy supplies pi through a lazy launcher that installs the CLI on first use. Starting the agents service can therefore download and install Pi without the user choosing it.

Check for an existing Pi sign-in before invoking the launcher, and add coverage for an unsigned user.

[Pillumz]

Closing in favor of the narrower #16431. The actual missing behavior is reusing an existing Pi Kimi sign-in; plan-quota parsing already exists. The configurable plan label, window metadata and tooltip-formatting additions are not required to show the quotas and are withdrawn from this proposal. #16431 now guards unsigned background refreshes before invoking the lazy Pi launcher, preserves explicit account selection, and documents verification and the adaptations needed for #14040 and #15646. No deployment or persistent Omarchy fork is introduced.