openclaw - 💡(How to fix) Fix [Feature]: Add manual provider remaining-capacity fuel gauge to Control UI [2 comments, 2 participants]

Summary

Add a manual provider remaining-capacity “fuel gauge” to the Control UI before starting expensive agent work.

Problem to solve

When starting a potentially expensive agent run, the operator often needs to know whether the selected provider is comfortably available, close to a short-window cap, close to a weekly cap, or about to reset. Today that capacity information is not surfaced in the Control UI at the moment of decision, so users may start large work without knowing that a provider window is nearly exhausted.

Proposed solution

Expose a small manual “fuel gauge” affordance in the Control UI that fetches and displays provider-reported remaining capacity and reset windows.

Suggested constraints:

• Manual refresh by default; no background polling.
• No LLM/token spend just to check capacity.
• Show source and confidence for every displayed provider value.
• Prefer provider-reported usage/remaining-limit data.
• Represent unavailable/stale data explicitly instead of hiding it.
• Keep provider-specific details behind a normalized JSON shape.

Reference PoC:

https://github.com/lencon14/openclaw-fuel-gauge-poc

Current PoC sources:

• OpenClaw provider usage via openclaw status --usage --json
• Claude Code via Claude Code's OAuth usage endpoint

Current PoC UI surfaces:

• Gateway-authenticated JSON route
• Standalone mini panel
• Control UI userscript/bookmarklet overlay with a manual ⛽ Limits button

Alternatives considered

• Standalone plugin only: useful for experimentation, but easy to miss and not integrated at the decision point.
• Persistent always-on usage display: useful for some users, but can create noise and may encourage polling. A manual refresh seems safer as the default.
• Provider-specific one-off UI: works initially, but does not establish a common shape for future providers.

Impact

Affected users/systems/channels:

• Operators using OpenClaw with provider plans that have short-window or weekly limits.
• Users launching expensive coding/agent tasks from the Control UI.
• Multi-provider setups where the best model choice depends on current remaining capacity.

Severity:

• Medium. It does not block existing work, but it can prevent avoidable failed/degraded runs and manual provider checking.

Frequency:

• Recurs whenever an operator is about to launch a large agent run near usage limits.

Consequence:

• Less guesswork before expensive runs.
• Fewer starts during near-exhausted windows.
• Better model/provider selection based on current capacity.

Evidence/examples

Reference screenshot and implementation:

https://github.com/lencon14/openclaw-fuel-gauge-poc

Related issues I found while checking for overlap:

• #46398 — persistent token usage indicator in Control UI / WebChat
• #56047 — expose Anthropic unified rate-limit headers in session status / API
• #67593 — provider usage and balance display for Kimi/Moonshot

This request is narrower/different: a manual, decision-point remaining-capacity gauge for provider windows, with explicit source/confidence labeling.

Additional information

The PoC intentionally avoids modifying OpenClaw core files or dist/control-ui. It is meant as a reference implementation for the UX/API shape rather than a finished product.

Open questions:

• Should this live in Control UI core, a first-class plugin surface, or both?
• What should the canonical JSON shape be?
• How should unavailable/stale provider data be represented?
• Which providers can expose reliable provider-reported remaining-limit data?