Feature: non-interactive way to read plan quota (5-hour / weekly / monthly)

Start by tracing the CLI's existing projectUsageView and the documented-in-the-issue endpoints: /alpha/whoami?limits=1, /alpha/billing/credits, /alpha/billing/subscriptions, and /alpha/usage/summary?since=. Define the supported command output around the five-hour, weekly, and monthly fields, then verify that the text and --json forms exit non-interactively and expose the requested values.

Feature Description

Make the plan's quota readable from the CLI in a non-interactive way — one command that prints the 5-hour, weekly and monthly windows and exits, with a --json form for scripts.

Concretely, something like:

$ command-code usage
GOAT / alex
  5h    ▌░░░░░░░░░   5%  $13.32 left of $14.00   resets 04:16 (in 3h35m)
  week  ███▊░░░░░░  37%  $22.00 left of $35.00   resets 09-27 23:29 (in 5d22h)
  month █▉░░░░░░░░  19%  $57.00 left of $70.00   resets 10-20 23:25 (in 28d22h)

and command-code usage --json printing the same fields (used, cap, percent, remaining, resetAt, resetsInMs) for tooling.

Right now the numbers exist — the dashboard shows them, and the web app reads them from /alpha/billing/credits (credits + windowLimits.fiveHour/weekly) and /alpha/billing/subscriptions — but as far as I can tell there is no supported way to ask for them without a browser. If a non-interactive path already exists, a pointer to it in the docs would be just as good as a new subcommand.

Optional, if it fits your roadmap: the same numbers in the terminal title or prompt, so they are ambient rather than something you remember to ask for. That is what most people build on top of this themselves.

Use Case

The quota is what decides whether work can continue, and it is checked at exactly the moments the user is inside a terminal:

• Sizing a task before starting it. "Can I finish this refactor on the current 5-hour window, or do I spread it over two?" needs the window's remaining amount and its reset countdown, not a percentage on a page in another tab.
• Explaining a failure. When a request is refused mid-run, the first question is whether the window is spent and when it comes back. Today that answer means leaving the editor for a dashboard.
• Scripts and status lines. CI jobs, hooks and status-line integrations can only consume the quota if there is a documented, non-interactive output contract. Today they have to depend on /alpha/* — the web app's own endpoints — which are undocumented and can change without notice. A supported --json output would turn that from a hack into an interface.
• Team plans. The same read with an orgId answers "how much does the team have left", which is currently only visible per-account in the app.

Reading the quota should also cost nothing: it is four GETs, no model call.

Additional Context

I hit this while building a usage line for the agents I work in (Claude Code, Codex, ZCode, opencode, pi, DeepSeek Harness, and Grok) and ended up implementing it as an external plugin because there was no first-party surface to read:

• https://github.com/Jovan1666/commandcode-usage — MIT, ~300 lines of Node with no dependencies, and it is exactly the read described above: resolve the credential (COMMAND_CODE_API_KEY or ~/.commandcode/auth.json), call /alpha/whoami?limits=1, /alpha/billing/credits, /alpha/billing/subscriptions, /alpha/usage/summary?since=, normalize, print.
• The normalization is written to match the CLI's own projectUsageView: the plan's face value is the denominator while the subscription is active, otherwise it falls back to spent + remaining; windowLimits.limited: false means the account has no rolling windows and the plain monthly pool is the whole story.
• A few details I had to guess at, which a first-party implementation could settle: whether windowLimits.*.cap is ever absent for a plan (I keep a plan table as a fallback), what exceeded implies for subsequent requests, and whether averageCost is the right basis for a request count estimate (it moves with the model mix, so any count is an estimate).

Happy to hand over the code, or to open a PR against this repo if you want it there rather than in a plugin.

How important is this to you?

Important for my workflow