[FEATURE] Expose plan usage with decimals (status line rate_limits, /usage, usage endpoint), not whole percentages

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Every place Claude Code exposes plan usage gives whole percentages only:

• the status line JSON: rate_limits.five_hour.used_percentage and rate_limits.seven_day.used_percentage;
• /usage in the TUI;
• the OAuth usage endpoint Claude Code reads (five_hour.utilization, seven_day.utilization): today it returned 6.0 and 10.0.

Evidence: our status-line sampler has logged these fields since 2026-09-27, 28,821 window readings across Claude Code 2.1.2xx releases up to 2.1.296. Every value is an integer; none has a fractional part.

On a Max 20x plan, 1% of the weekly limit is a lot of work: hours of several parallel agents. With integer steps, a tool that paces automated sessions against the weekly limit (how many agents to run, when to slow down) sees nothing move for long stretches, and then a jump. It cannot tell a slow burn from a fast one until a whole point has gone. Today we estimate the position inside a weekly point by calibrating the 5-hour percentage against the weekly one (about 0.22 weekly points per 5-hour point on our account). That is a workaround with a measurable error, and it breaks at every reset.

Third-party tools report that the claude.ai web app's own usage data (message_limit.windows[...].utilization) carries unrounded fractions. So the precision seems to exist server-side, but it doesn't reach Claude Code users.

Proposed Solution

Expose the usage with at least one decimal (ideally two) wherever Claude Code shows it:

1. the status line JSON: rate_limits.*.used_percentage as a float with its real precision (a status line command rounds it if it wants);
2. /usage: one decimal next to the bars;
3. the same value in the usage endpoint and in the SDK / headless usage data, so scripts and the Agent SDK can pace without scraping.

Keeping the field name and type (a number) makes this backward compatible: existing status lines that print the value keep working.

Alternative Solutions

• Calibrating the 5-hour window against the weekly one (what we do now): approximate, and lost after each reset.
• Counting tokens from transcripts or OpenTelemetry: it doesn't map to the plan's limit, and it misses usage from other devices and claude.ai.
• Reading claude.ai's web usage data: undocumented, and not available to a headless Claude Code setup.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

A single user runs five long-lived Claude Code sessions with subagents. A pacing script reads rate_limits.seven_day.used_percentage from the status line every minute to decide how many agents may run at once. With one decimal, it would see the week move from 41.3 to 41.8% in an hour and adjust within minutes. Today it sees 41% for an hour or two, then 42%.

Additional Context

Related, not duplicates: #73770, #89769 and #99223 ask for per-model weekly windows in the status line; #75408 reports used_percentage drifting across terminals. This request is about the precision of the existing values.

---
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🤖 Generated with Claude Code