[FEATURE]: In-app subscriptions & usage ledger — active plans, quota left, reset times, spend #62124

Feature hasn't been suggested before.

• I have searched existing requests. This is adjacent to Unified Real-Time Usage Dashboard for All AI Models #57975 (unified model usage meter), [FEATURE]: A permanent Information screen showing how much usage is left and when the usage is resetted #57072 (usage-left / reset screen), [FEATURE]: /usage — dedicated session token & cost report (alias /cost) #41915 (/usage session report) and [FEATURE]: Color context usage and cost by thresholds (sidebar and prompt footer) #53263 (cost/context threshold coloring), but the ask here is different in scope: a subscription inventory — not just a per-model meter.

Describe the enhancement you want to request

Problem

OpenCode now aggregates a lot of billing surfaces behind one UI: opencode zen, flat-rate Go plans, provider subscriptions (Anthropic Pro/Max, ChatGPT plans, Copilot), credit/PAYG providers like OpenRouter, BYOK API keys, and local models that are free. In the app, the only signals are a session cost number and a context-usage meter in the footer.

That means I can't answer, from inside OpenCode:

• Which subscriptions/plans am I actually on right now, and what does each one cover?
• How much is left on each, and when does it reset?
• How much have I burned this session / today / this week, split per plan?
• Am I about to hit a limit mid-task, and which model or agent is going to block?

Today this is done by opening several provider dashboards, or by running a separate script that reads the local session DB. Both work, but neither is discoverable, and the script route breaks on schema changes.

Proposal: a "Subscriptions & Usage" surface inside the app (TUI + web/desktop)

1. Subscription inventory. A list of every billing surface the user has configured — zen, Go, each BYOK provider, Copilot, local — with its billing model (metered vs flat-rate quota vs free/local), the models it covers, and whether it is active. Plans should be declarable in config where they cannot be auto-detected.
2. Quota state per plan. Used / total, percentage, reset time in the user's local timezone, and — explicitly — the unit the quota is measured in (requests, tokens, dollars, or wall-clock). Where a provider exposes no quota API, show unknown (provider does not expose it) rather than estimating silently.
3. Usage ledger. Tokens, request counts and cost (actual, plus catalog-price estimate where the provider reports $0) rolled up per plan / model / provider, for the session, today, this week, and all time. Derived from the local session store, so it also works for past sessions and while offline.
4. Thresholds and fallback. Warn visibly before a plan is exhausted, and make switching to another plan/model a one-key action — the common failure mode in [FEATURE]: A permanent Information screen showing how much usage is left and when the usage is resetted #57072 is getting blocked mid-task with nowhere to go.
5. Honest provenance labels. Every number tagged as provider-reported, measured locally, or estimated from catalog prices. No guessing presented as fact.
6. Machine-readable output. Expose the same data as opencode usage --json and a /usage command, so status lines, scripts and dashboards can consume it without screen-scraping.

Constraints I'd ask for

• Offline-first: compute from the local session store; only call a provider quota endpoint when that provider genuinely exposes one.
• No new telemetry or telemetry-adjacent reporting.
• Flat-rate plans must not be shown as $0 spent (see web/tui: restore session cost for flat-rate (Go) subscriptions #61712) — for Go-style plans, show quota consumption, not just cost.
• BYOK providers with no quota API should show locally measured consumption only, clearly labelled.

Why it's worth it

Unexpected limit exhaustion interrupts work and forces a detour into multiple dashboards. A subscription inventory also answers the question that decides renewals: is this plan actually being used, and for what? Right now that number is unavailable inside the product that spends the money.

Environment

• opencode version: 2.2.5
• OS: Linux 6.8.0 (x64)
• Terminal: xterm-256color, bash
• Channels used: TUI, web UI; local + BYOK + flat-rate plans

Alternatives considered

• Rely on each provider's own dashboard: fragmented, no per-session attribution, no idea which agent/model spent what.
• Third-party script over the SQLite session DB: works today, but it is undiscoverable for most users and is coupled to internal schema.