Subscription throughput: a governor that keeps every model subscription's window full, with usage as the forge's efficiency metric #341

Owner's direction (2026-10-02): maximize the throughput of the subscription usage. Units are how the forge does economics; usage is how it tracks work efficiency. This is the twin of the profit slider: the slider decides where work runs and what it costs; the governor decides how much work runs now so no subscription window is left unused and no run is lost to a provider wall.

Intent: the forge knows each subscription's windows (the 5-hour and weekly caps, their reset times) and current standing, paces the crew so the windows are consumed evenly and fully, rotates across several subscriptions when more than one is held, and shows usage per run, app, agent and subscription on the board as signal.

Acceptance (planner: split into runs; builders: one run each):

• [ ] a usage ledger: tokens in/out, cost in units, wall time and outcome per run, attributed to subscription, app, agent and issue
• [ ] subscription standing read from the provider where it exposes it, inferred from the ledger where it does not; reset times kept per subscription
• [ ] a pacing policy: concurrency and dispatch rate rise toward the remaining window capacity and fall as a wall approaches; a paused run resumes at reset automatically (the forge already labels these successors — make the label say the real reason)
• [ ] round-robin across subscriptions with a stickiness rule per run (a run does not change subscription mid-flight)
• [ ] the board shows, per subscription: window used / remaining / resets at, and per app the units spent per shipped change (efficiency), in the studio's words
• [ ] an MCP read (usage) and an API route for the same data

Files: src/crew/runner.ts (credentialEnv, concurrency), src/crew/autonomy.ts (slots), src/core/subscriptions.ts, a new src/core/usage.ts, src/web/studio/board. Risks: provider limits are not fully observable — degrade to inference and say so on the board; never spend a subscription down to zero without leaving headroom for a person's interactive use (an operator setting).

Parked by the crew: the check stayed red through 2 automatic tries (pull #375 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Owner's addition (2026-10-02 12:5xZ): the operator cannot see the usage windows today, and neither can the agents. Two requirements join this issue:

1. Windows visible in Subscriptions. For each subscription: the 5-hour window and the weekly window — used, remaining, resets at — read from the provider where it exposes it, inferred from the usage ledger where it does not, with the source stated. The same numbers on the board and through the MCP usage read.
2. Agents aware of the windows in plain terms. Every run's brief carries one line it can act on without context, e.g. 'this subscription has 38% of its 5-hour window left (resets 14:00); the weekly window is at 61%'. The runner refuses to start a run that cannot finish before a wall and says so in the run record, instead of pausing mid-run.

First slice (one run): the ledger and the Subscriptions page showing window standing per subscription; the brief line follows.

Acceptance example from the owner, 2026-10-02 15:3xZ, read off the provider by hand because the forge cannot show it: "23% of the session (5-hour) window used, resets soon; 57% of the week used, the week ends tomorrow at 21:00." This is the sentence the Subscriptions page, the board and every run brief must be able to say on their own. Second point from the owner: with those numbers the crew should have been running MORE in parallel — the dollar ceiling paused work the window could have absorbed. The governor sets slots from the windows, not from a dollar figure; the dollar ceiling stays as a safety cap only.

Owner, 2026-10-02 16:4xZ: the board says the trevato-espo subscription is using nothing, because the crew runs on the platform-provided credential (CLAUDE_CODE_OAUTH_TOKEN in the forge env), which the board does not count. Requirements added to this issue:

1. Every credential is a subscription row, including the platform-provided env credential (shown as platform (env)), with the same window and usage stats as a sealed subscription.
2. Spend breakdown for the current window, today and the week: by credential, by repo/app, by agent, by issue, by run kind (build, plan, review, check), with tokens in/out and units, and the top 10 runs by cost.
3. Near realtime: each run streams its token and cost deltas into the usage ledger as the session reports them (not only at the end), and the board and Subscriptions page update over /events within seconds.

First slice for the current run: count the env credential as a subscription and attribute live runs to it; the breakdown and streaming follow.