/usage and startup panel show "Plan usage: 0% used" on 0.43.1 while the web console shows real usage

What version of Kimi Code is running?

0.43.1 (regression; 0.43.0 was correct)

Which open platform/subscription were you using?

kimi.ai Vivace

Which model were you using?

No response

What platform is your computer?

Linux 6.17.0, x86_64

What issue are you seeing?

What I see

The "Plan usage" section reports zero for both windows, before and after a turn:

  5h limit      ░░░░░░░░░░░░░░░░░░░░  0% used  resets in 32m
  Weekly limit  ░░░░░░░░░░░░░░░░░░░░  0% used  resets in 5d 22h 32m

The membership console (kimi.ai/membership) for the same account at the same moment:

  5-hour usage  8.78%   resets in 09-15 14:51
  7-day usage  25.88%   resets in 09-21 12:51

Why this is not a rounding or parsing artifact

The reset times agree to the minute between the CLI panel and the console (5h: 14:51,
weekly: 09-21 12:51), so both surfaces read the same meter — the percentages, not the
window, are what disagree. The rows are rendered with bars and reset hints, so
used_ratio was present in the payload; it is the value that is zero.

What steps can reproduce the bug?

Steps to reproduce

1. Start kimi, send any message so a session exists.
2. Run /usage (the startup panel shows the same).
3. Compare with the 5-hour and 7-day usage on kimi.ai/membership.

What is the expected behavior?

Expected

The panel matches the console (as it did on 0.43.0).

Additional information

Additional

Rolling back to 0.43.0 via the installer restores correct values, so this is a
regression introduced between 0.43.0 and 0.43.1.

Related: #2751 is still present on 0.43.1 — before the first message, the session-scoped
section still prints "No active session. Send /login to login." even though the plan
usage loads. (After one message it resolves.)

Separate observation, possibly worth its own issue: on startup, 0.43.0 shows a
foreground update prompt offering the newest release with "Install update now" selected
by default, and it appears even when the staged rollout holds that release for this
device (rollout.log: "reason":"held", eligibleAt several hours later). The prompt
also blocks non-interactive TUI automation that waits for the startup banner. Is the
prompt intended to bypass the rollout gate?

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

Start at the /usage command and the startup panel, then trace how the payload's used_ratio is read and rendered for the 5-hour and weekly windows. Compare behavior between 0.43.0 and 0.43.1, using the reset times and the kimi.ai membership console as reference. Done means both panels show the console's actual percentages while preserving the matching reset times.