Skip to content

docs: billing & usage UX — visibility + one-off top-up + auto-top-up (monthly cap) - #475

Open
ZIJ wants to merge 3 commits into
mainfrom
docs/billing-usage-topup-design
Open

docs: billing & usage UX — visibility + one-off top-up + auto-top-up (monthly cap)#475
ZIJ wants to merge 3 commits into
mainfrom
docs/billing-usage-topup-design

Conversation

@ZIJ

@ZIJ ZIJ commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Working design doc (.agents/work/billing-usage-and-topup.md) from today's "users running out of tokens" investigation. Docs only — for review/discussion, not a build.

What it found

  • Mechanism: managed model spend meters per-org to Autumn credits; the edge model_meter halts at ≤0 → OpenRouter 402 → the runtime posts "run out of model credits, top up" and stops. (Not limits.tokens — that cap is a no-op.)
  • Incidence: low + internal so far (utpal@/igor@/mo+9000@, 3 orgs/3wk) — structural, not an outage, but scales to real users.
  • Dominant burn factor: the managed default model is opus — ~88% of 14d sessions run opus-4-8, mostly because no model was specified. A modest grant evaporates in a few opus turns.

Key reframe

Most of the target already exists in web/src/pages/Billing.tsx (one-off autumnTopup, setAutumnAutoTopup, compute usage, invoices) + edge model_meter. So this is consolidate + gap-fill, not greenfield. Gaps: surface the (hidden) model/token pool + remaining, a unified breakdown (compute vs model, by model, by agent), an auto-top-up monthly cap, and discoverability for sessions users.

Proposes

  • S0 quick wins (cheap, high-leverage): flip the default off opus (opt-in per agent), a sane grant, make the exhaustion message link to top-up.
  • S1–S4: surface model usage + balance + low-balance banner → usage breakdown → auto-top-up monthly cap → in-context usage/top-up widget.

Decisions to weigh in on

  1. Default model — opus (flagship/cost) vs cheaper (reach)? (biggest lever)
  2. One balance + breakdown vs two visible pools?
  3. Hidden → visible usage (recommend) vs invisible-until-low?
  4. Monthly cap — hard stop vs notify-and-continue?

🤖 Generated with Claude Code

ZIJ and others added 3 commits July 2, 2026 17:34
…op-up w/ monthly cap

Working doc from the 2026-07-02 "running out of tokens" investigation. Captures the mechanism
(managed model spend → Autumn credits → 402 halt; not limits.tokens), the evidence (low/internal
incidence; ~88% of sessions on the opus default which burns the grant fast), and — key reframe —
that top-up/auto-top-up/compute-usage/invoices ALREADY exist in Billing.tsx, so this is
consolidate + gap-fill (surface model/token usage + remaining, unified breakdown by compute vs
model / by model / by agent, monthly auto-top-up cap, discoverability) rather than greenfield.
Includes cheap quick wins (flip default off opus, sane grant, actionable exhaustion message),
data sources, open decisions, and S0–S4 slices.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ady built

Two corrections after re-checking the code:
- Billing is wired end-to-end: edge model_meter debits OpenRouter spend (with markup) to the
  org's Autumn credits pool and halts at ≤0. NOT a leak. Called this out explicitly and
  distinguished it from "usage-not-wired" (a per-session attribution/visibility gap in
  sessions-api — session.usage/limits.tokens — not a billing hole; it's the prerequisite for the
  per-agent "for what" breakdown).
- The top-up UI is already built: one-off autumnTopup + a full AutoTopupCard (enable + threshold +
  recharge amount). Narrowed the auto-top-up gap to the monthly cap only, and flagged that linking
  the runtime "out of credits" message → the existing top-up flow is the highest-value, no-new-UI fix.
…its run out

First build slice, spec'd end-to-end across repos: 1a actionable exhaustion CTA (client keys off
the existing error.runtime{code:insufficient_credits}, deep-links to the built top-up), 1b
low-balance banner (autumn orgs, Autumn credits.remaining < threshold), 1c fast un-halt on top-up
(re-project OR caps on the Autumn top-up webhook, not next meter-cron — the real UX risk). Touch
points, acceptance criteria (incl. exhaust→top-up→re-message within seconds), and explicit
out-of-scope (attribution/monthly-cap/breakdown = S2–S4) included.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant