Phase 1: Stop Mislabeling Signals — Separate API Rate Limits from Subscription Usage #36

Closed
opened 2026-05-21 00:49:28 -05:00 by null · 0 comments
Owner

References: remaining-usage-accuracy-review-plan.md — Phase 1

Summary

API rate-limit headers (x-ratelimit-*, anthropic-ratelimit-*) are currently presented as Current session and All models remaining usage bars. These headers measure request/token throttling windows for an API key, not Claude Code subscription or account-level remaining usage.

This makes precise-looking progress bars that measure the wrong thing.

Acceptance Criteria

  • No API rate-limit header value appears as Current session or All models
  • Every usage payload carries source and confidence fields: provider_native, provider_api_rate_limit, local_jsonl_estimate, configured_limit
  • Users can see when a number is exact/provider-native versus a local estimate
  • API rate-limit data remains visible as diagnostics (not hidden entirely)

Work

  1. Rename API header-derived bars to API rate limit wherever they remain visible
  2. Remove Current session and All models labels from API-header data
  3. Add source and confidence fields to usage response payloads
  4. UI rule: only provider-native windows render as remaining subscription usage without an "estimate" label

Do Not

  • Do not hide API rate-limit data entirely if useful for debugging
  • Do not call API rate-limit reset times "session reset" or "all models reset"
  • Do not infer subscription usage percent from rate-limit headers
  • Do not add another estimated percent just to keep the progress bar populated

Priority: High
Phase: 1

References: [`remaining-usage-accuracy-review-plan.md`](docs/remaining-usage-accuracy-review-plan.md) — Phase 1 ## Summary API rate-limit headers (`x-ratelimit-*`, `anthropic-ratelimit-*`) are currently presented as **Current session** and **All models** remaining usage bars. These headers measure request/token throttling windows for an API key, **not** Claude Code subscription or account-level remaining usage. This makes precise-looking progress bars that measure the wrong thing. ## Acceptance Criteria - No API rate-limit header value appears as `Current session` or `All models` - Every usage payload carries `source` and `confidence` fields: `provider_native`, `provider_api_rate_limit`, `local_jsonl_estimate`, `configured_limit` - Users can see when a number is exact/provider-native versus a local estimate - API rate-limit data remains visible as diagnostics (not hidden entirely) ## Work 1. Rename API header-derived bars to `API rate limit` wherever they remain visible 2. Remove `Current session` and `All models` labels from API-header data 3. Add `source` and `confidence` fields to usage response payloads 4. UI rule: only provider-native windows render as remaining subscription usage without an "estimate" label ## Do Not - Do not hide API rate-limit data entirely if useful for debugging - Do not call API rate-limit reset times "session reset" or "all models reset" - Do not infer subscription usage percent from rate-limit headers - Do not add another estimated percent just to keep the progress bar populated **Priority:** High **Phase:** 1
null added the
backend
phase:1
priority:high
service
usage-accuracy
labels 2026-05-21 00:53:40 -05:00
null closed this issue 2026-05-21 01:01:19 -05:00
Sign in to join this conversation.
No description provided.