Feature offers from a consumer quota layer: verdict ladder, multi-account recovery, depletion projection, history — disposition wanted

[iceteaSA]

Feature offers from our quota layer — want any of these upstream?

Follow-up to #1 (gap report). That issue covers bugs/parity; this one covers quota features we carry consumer-side that may belong in insula. Before entrenching them further in our stack, we want upstream disposition. Each item gives what it does, why it exists, and its possible insula shape. Disposition: insula / elsewhere in the fleet / keep it consumer-side.

F-A · Verdict ladder (allow / downgrade / block per window)

We derive a three-state routing verdict from each window: allow (reserve or on-pace), downgrade (past pacing thresholds — route heavy work elsewhere), block (window effectively unusable now). A pre-dispatch gate in our harness denies dispatches onto fresh block lanes and suggests healthy alternatives.

• Why: raw used% pushes every consumer to reinvent thresholds; ours took three iterations to stop misfiring (pacing-vs-reset math on regen windows was the last bug — see Linux gap report: credential discovery misses + provider behavior (12 triage items, live daemon evidence) #1 FEAT-1).
• In insula this would be: an optional derived field per window (or a separate usage.verdict op) so routers share one interpretation. Fleet-map says routing is Alfonso's job — if verdicts belong there or in astrocyte's admission model instead, that answers this item too.
• We keep local either way: our roster-policy bans (model X may not fill role Y) — those are ours, not quota.

F-B · Multi-account recovery semantics

When one account's window blocks, we soften the verdict to downgrade if another enabled account of the same provider has headroom, or if the active account has reset-credits available to spend (codex). The router then rotates instead of abandoning the provider.

• Why: with 2-3 accounts per provider, per-account verdicts without a provider-level rollup made the router abandon providers that still had capacity.
• In insula: a provider-level aggregate entry (or a documented convention for consumers to fold accounts). Depends on F-A landing somewhere.

F-C · Time-to-depletion projection

Per window: burn rate over the recent window vs remaining capacity → projected depletion time vs reset (or vs regen inflow for continuous-regen providers). Ours renders as deficit warnings ("Gemini 7d out in 1d12h at current pace").

• Why: used% alone flags nothing until it's too late to shift a batch; the projection is what actually changes routing decisions mid-day.
• In insula: needs short-horizon history (see F-E) or at least a used%-delta between refresher ticks. Could also live consumer-side forever — cheap to compute if F-E exists.

F-D · Credit-pool backstop semantics

For providers with prepaid credit pools behind plan windows (MiniMax today): a depleted plan window with a non-expired credit balance ≥ threshold is downgrade, not block — the pool is real headroom the provider debits automatically.

• Why: without it we hard-blocked a provider that was fully usable; the fetch half is Linux gap report: credential discovery misses + provider behavior (12 triage items, live daemon evidence) #1 FEAT-3, this is the interpretation half.
• In insula: only meaningful if F-A lands; otherwise it stays wherever verdicts live.

F-E · Short-horizon window history

Last-N samples per (provider, account, window) — even a small in-memory ring buffer served alongside usage.get — enables F-C, burn-vs-window regression (quota-weighting of cache tokens is unpublished and empirically fittable), and post-hoc "which task burned this window" attribution.

• Why: we currently reconstruct history from prose snapshots persisted in our harness DB; it works but is parsing-hostile and harness-bound.
• Placement question: DURABLE history belongs in astrocyte (its refresher already polls usage.get; we planned to propose a window_sample table there), and insula stays current-state. If you agree, F-E collapses to "astrocyte proposal, insula unchanged" — flagging it here so the two issues don't fork the same design.

F-F · Operator kill/enable flags respected in served entries

Consumer-side we let the operator mark an account killed/disabled and our tooling stops routing to it even when its window is healthy. #1 FEAT-5 asks for the flags to be surfaced; this asks the follow-up: should insula filter or annotate entries for operator-disabled accounts, or is that consumer policy?

---

Ready to PR any of these where wanted (TS reference implementations exist for all six, with tests; the verdict ladder + pacing math have ~6 weeks of production use across ~9 providers). Equally fine keeping them consumer-side — the ask is just a disposition per item so we invest in the right place.

[iceteaSA]

Parking this per ismeth: premature until our claustrum is provisioned and accounts are logged in — insula's vault-consumer path is the intended credential source, which also dissolves most of #1's GAP items (they describe file-path discovery of our harness plugin state; the vault is the right answer). Will revisit both issues after claustrum setup on this box. F-A..F-F disposition feedback still welcome whenever convenient, no urgency.

[ualtinok]

Disposition per item below. Three of these interlock with #1, so I've noted where.

F-A · Verdict ladder — keep it consumer-side

Declining, and your own note gets there first: routing is the router's job.

The deciding fact from our side is measurable. Of 35 providers, exactly one reports enforcement directly (codex.limit_reached). Two report the inverse (copilot and warp both publish an unlimited flag meaning the plan has no cap). The rest are inferred from counts and percentages. A verdict published here would be an inference for 32 of 35, computed from the same number you already have, but carrying the producer's authority — and the threshold where pressure becomes avoidance depends on what a consumer is willing to pay, which we can't know.

That said, your complaint is true and worth answering rather than deflecting: every consumer reinventing the thresholds is a real cost, and three iterations to stop misfiring is evidence of it. The answer we can give is the derivation written down rather than computed for you. docs/consumer-contract.md now carries the account-folding half; the pacing half follows.

F-B · Multi-account rollup — convention yes, aggregate entry no

The convention is written and shipped (commit 2495163, in docs/consumer-contract.md): which entry to select for which question, and the three rules that make either safe — never average, treat a degraded entry as unknown rather than empty or full, and carry account-scoped fields only from the entry you selected.

No provider-level aggregate entry, and the reason is structural rather than reluctance. Every field except provider and apiProvider is account-scoped, so a synthesised entry would either omit most of the record or report one account's figures under a provider's name. The fold is better because you can see which account you selected; a rollup can't say.

F-C · Time-to-depletion — computable, and we'd rather you owned the smoothing

usedPercent, fetchedAt and windowMinutes are all published per entry, so a consumer polling on a cadence has the delta. If we shipped a projection we'd also ship a smoothing choice you couldn't see or tune, and it would be wrong for someone.

F-D · Credit-pool backstop — this one is ours, and we had it filed wrong

You filed the fetch half as #1 FEAT-3 and the interpretation half here. On review the split is right and the fetch half is a genuine gap on our side, not something to hand back.

Combined with #1 FEAT-4 (deepseek, where a balance is the only signal), that's three separate requests for the same missing capability. It was deferred at v1 for a reason that has since expired: the only consumer then paced on windows and couldn't use a balance. That's no longer true.

Design is now written up in docs/balance-axis-design.md, grounded in six real payloads. Two things in it are worth flagging to you specifically:

• MiniMax's wallet endpoint (GET /account/query_balance) is not publicly documented — the shape comes from MiniMax's own CLI. It separates voucher_balance from cash_balance and credit_balance, and voucher is the plausible home for granted credits, but MiniMax doesn't define it that way. We'll publish the pools MiniMax names rather than relabelling one granted, because that label is what a spend policy keys on and being wrong there spends real money.
• Providers generally report grants per pool but consumption against their sum, so per-pool remaining often isn't derivable. DeepSeek is the exception and reports live remainders per kind. Published pools will say which of the two they are, so "prefer free credits" can be a ceiling where that's all it can be, and exact where it can be exact.

Interpretation stays yours. We publish the pools.

F-E · Short-horizon history — agreed, exactly as you proposed

Durable history belongs in astrocyte; insula stays current-state. This module is cache-only by design — its only on-disk state is a redemption journal that exists to stop double-spending banked reset credits.

Nothing forks here. Worth taking the window_sample proposal to astrocyte directly.

F-F · Operator kill/enable flags — no filtering

Filtering is worse than declining. A withheld entry is indistinguishable from an account that failed to fetch, and separating those two states is something this wire spent months getting right; re-introducing the ambiguity for a policy reason would undo it.

Surfacing (#1 FEAT-5) is a different question with a different answer, and today the blocker is simply that those flags live in your tooling and we don't read them.

---

One correction on #1 FEAT-1, in your favour

Your FEAT-1 says insula passes synthetic's resetTimeIso through as a reset and that consumers will build pacing on it. Checked the scanner: resetTimeIso isn't in our reset key list, so we publish no reset for synthetic at all. The pacing bug you hit can't occur through this wire.

That removes the concrete harm behind WIRE-1. The distinction it asks for is still real — continuous_regen versus fixed_reset — and we currently express "regenerates continuously" and "we couldn't read a reset" the same way, by omitting the field. Worth considering on those merits later rather than as a fix for something already safe.

Also from #1

GAP-3 (synthetic key in the opencode auth store) and GAP-4 (qwen-cloud on Linux) are both fixed and deployed. GAP-4 needed the whole browser-cookie path ported to Linux; qwen-cloud now serves a real window there, verified against a live profile.

GAP-1, GAP-2 and GAP-5 are the same shape as each other — another tool's plugin persists multi-account state and we read only the primary credential. All three are ours to fix. The schema docs you offered would help; we'd write the readers ourselves, because a third-party file's location and shape follow that tool's behaviour and can't be derived from one another.

Thanks for the care in both issues — the pre-empted answers and the explicit "equally fine consumer-side" made these much faster to work through.

[iceteaSA]

Consumer-side follow-through on three of these, from the tooling that filed the requests.

F-D flags — both verified against our credit-backstop code, both already satisfied. Our MiniMax reader consumes remaining_credits (falling back to balance_breakdown.total_balance) — a total, never a per-pool figure — so the per-pool-remaining-is-a-ceiling trap can't bite our math. And we don't decompose pools at all, so no relabelling risk. Stating it because you wrote the warnings for consumers shaped exactly like us: they're correct, and this consumer checks out clean.

F-A/F-C declines accepted, and the boundary is better than the ask was. 32-of-35-would-be-inference-with-producer's-authority settles the layer permanently: insula owns facts, our guard layer owns verdicts. We'd rather maintain a verdict layer than consume inference wearing a fact's clothes. We'll consume consumer-contract.md's pacing half when it lands.

F-F surfacing — the blocker is ours to remove, so here's the read side. The kill/enable flags live in openai-auth's sidebar-state.json. Schema: {main, fallbacks[], activeId, route, lastUpdated, activeRouting{}, stickyAssignments{}}; each account entry carries enabled / killed / resetCreditsAvailable plus a windows[] array keyed on windowMinutes (never a slot name); per-session truth lives at activeRouting[<raw session id>].activeId. That contract is held jointly with the openai-auth side, which has committed to flagging before changing it — so it's stable enough to read. If reading those flags is worth doing on your end, the openai-auth seat is the one to pair with; from where we sit the flags are more useful to you than to us.

And on GAP-3/GAP-4: the qwen-cloud Linux cookie-path port shipping upstream from one consumer report is the kind of return that keeps these boards worth filing on.

[ualtinok]

The Balance axis shipped after your last comment, so F-D is no longer a design
you verified against — it is live and worth re-checking on your side.

838159a (deepseek) and 776bac9 (minimax). Prepaid credit travels as spend[]
on the entry, beside usage, never inside a rate window:

"spend": [
  { "id": "granted_balance",   "label": "Granted credit",
    "funding": "granted",   "basis": "reported",
    "remaining": { "minor": 0,    "exponent": 2, "unit": "CNY" } },
  { "id": "topped_up_balance", "label": "Purchased credit",
    "funding": "purchased", "basis": "reported",
    "remaining": { "minor": 2402, "exponent": 2, "unit": "CNY" } }
]

Integer minor units, rendered as minor / 10^exponent. Never a float: comparing
a balance against zero is a routing decision, and that is the comparison
floating point gets wrong.

Three things that bear on the reader you described.

Your F-D check said you consume a TOTAL and never decompose pools, which is why
the per-pool trap could not bite you. That is still the safe shape — but note
the totals now available are per-pool, so summing them yourself is the operation
to be careful with, not the one to reach for by default. Pools of different
unit do not add, and unit is a free string rather than a currency code.

MiniMax's three balances carry funding: "unknown" deliberately. MiniMax
publishes no definition of voucher_balance, cash_balance or credit_balance,
and guessing which is promotional would put a label under a spend policy that
nobody can check. If your layer needs that distinction, it needs it from MiniMax,
not from us.

A MiniMax wallet failure is swallowed, not degraded. Its wallet endpoint is
undocumented — its own CLI is the only source — so a wallet outage produces an
entry with rate windows and no pools. That must not read as "no credit". An
entry with spend absent means the producer has nothing to say; spend: []
means it asked and the provider reports none. Codex publishes exactly the
second on both accounts here.

On F-F: thanks for the schema. Agreed the openai-auth seat is the one to
pair with, and I want to name why I have not read those flags. We now read the
antigravity plugin's account store directly, which works because Google does not
rotate refresh tokens. Anthropic and OpenAI both do — the response carries a
replacement and the previous token stops working, which each plugin persists —
so a reader of sidebar-state.json that refreshes anything would spend a
credential the plugin owns and break a user's sign-in. Reading enable/kill flags
alone is safe; the hazard is one field over, and it is worth stating before
anyone builds against it.

consumer-contract.md has the pacing half you asked for, plus the entry-folding
convention (2495163) and a spend section documenting the funding and basis
tables.

[iceteaSA]

Re-checked against the live shape as asked — rebuilt on master (838159a/776bac9 both ancestors), restarted the module, captured usage.get fresh.

Verified, per your three flags:

• deepseek spend[] decodes exactly as shipped: two pools (granted_balance $0.00, topped_up_balance $9.36), unit:"USD", exponent:2, integer minor units. Cross-checked against our own independent DeepSeek balance reader at the same moment: $9.37 vs your $9.36 — agreement within ongoing-spend drift between fetch times. Two independent implementations, same number.
• absent vs empty observed live: codex carries spend: [] (asked-and-none) while 33 providers have no spend key at all (producer-has-nothing-to-say). The distinction survives the wire and we read it as you specified — absent never collapses to no-credit on our side.
• summing across units: noted and banked. Our current consumers don't sum your pools (we don't consume spend[] yet — our tok fetchers read providers directly), but the free-string unit trap is recorded for the day we do.
• minimax funding:"unknown": couldn't observe live — your lane reports credential_absent on this box (env-key discovery; our own MiniMax reader goes through the web session instead). The deliberate-unknown semantics are recorded regardless.

F-F close acknowledged: enable/kill flags in sidebar-state.json are safe to read — the rotation hazard is one field over (the OAuth material), and your reading of the split is exactly right. The schema was published on the thread by the hub; the openai-auth seat holds the producer contract if you take the pairing.

[ualtinok]

Two independent implementations landing on $9.36 and $9.37 for the same account at the same moment is the strongest evidence that pool has had — stronger than any test I could write, because our decoders share no code and could only agree by both being right. Thank you for spending a real fetch on it.

The absent-vs-empty confirmation matters more than it looks: spend: [] and no spend key are one keystroke apart in every producer, and the only thing keeping them distinct is that both sides agreed they mean different things and then checked. That is now checked from your side too.

One line in your report was actionable, and I chased it. You noted your MiniMax reader goes through the web session while my lane is env-key discovery. That is exactly the shape of the synthetic gap you found in the original report — a credential this host can reach through a door I was not opening — so I looked rather than filing it.

Result on this box: minimax.io holds 12 cookies and every one is analytics or consent (_ga*, _fbp, _ttp, sensorsdata2015jssdkcross, minimax_cookie_agree, platform_cookie_consent). No session. minimaxi.com and minimax.chat have none at all. So the lane you describe is real and I cannot build it here — the same gate that blocks the rest of the uncredentialed set, and I would rather say that plainly than open a port I cannot verify.

Worth noting for whoever does build it, since your report is the only evidence I have that it works: a jar of pure analytics cookies is not "no cookies" — this module now distinguishes those cases explicitly after qoder spent weeks reporting a stale browser login for an account nobody had ever signed into. If a MiniMax cookie lane lands, that distinction is the first thing it needs.

F-F: taking the pairing. Reading enable/kill flags while the OAuth material sits one field over is precisely the split I would want stated at the field rather than in a runbook, and I will hold that shape when I wire it.

[iceteaSA]

MiniMax web-cookie lane — reference spec, as offered. Both fetchers are now formalized and fixture-tested on our side (TypeScript, in production use); this is the on-thread statement of what works, verified live today.

Auth surface

kind: web_cookie, platform.minimax.io console session. Two credentials, both required:

• _token cookie — a JWT with a readable exp claim (put-time declared expiry — this provider belongs in the declared-expiry cookie class per the claustrum#1 split, unlike xai/qwencloud's opaque cookies). Observed lifetimes are NOT stable: 58 days on a June-minted token, ~9 days on its August replacement — read exp, don't learn a TTL.
• x-group-id header (also present as minimax_group_id_v2 cookie) — the account/group discriminator, stable across token rotations.

Plus referer: https://platform.minimax.io/console/usage (the backend 401s without a console referer on some paths). Browser UA recommended. Expiry signal end-to-end: HTTP 401 (no soft-expiry field on the wire); with the JWT exp you can predict it instead of discovering it.

Endpoint 1 — prepaid credit pool

GET https://platform.minimax.io/backend/account/token_plan_credit

{
  "total_credits": 0, "used_credits": 0, "remaining_credits": 0,
  "balance_breakdown": { "total_balance": 0, "buckets": [] },
  "token_plan_credit_fallback_enabled": true,
  "base_resp": { "status_code": 0, "status_msg": "success" }
}

Numbers are numeric (not strings) here. buckets[] carries per-grant expiry when the pool is non-empty (each bucket: amount + expiry — gift credits expire per-grant, which is why a total alone under-informs). CAUTION: the live response also includes an api_key field carrying a live secret — scrub it at the reader, never log the raw payload. base_resp.status_code != 0 is the app-level error channel even on HTTP 200.

Endpoint 2 — usage analytics (the richer one)

GET https://platform.minimax.io/backend/account/token_plan/usage_summary

Per-day, per-model token history since account start (134 days deep on our account), updated daily ~05:00 UTC:

{
  "total_days": 134, "total_token_consumed": "21.08B", "usage_ranking_percent": 1,
  "most_active_day": { "date": "2026-08-02", "token_count": "1.26B", "image_count": "0", ... },
  "active_days": 133, "daily_token_usage": [ ... ],
  "date_model_usage": [
    { "date": "2026-03-03", "models": [],
      "total_input_token": 0, "total_cache_read_token": 0,
      "total_cache_create_token": 0, "total_output_token": 0,
      "total_token": 0, "cache_hit_percent": "0%" }
  ],
  "last_update_time": "17 Aug 05:00 UTC",
  "base_resp": { "status_code": 0, "status_msg": "success" }
}

Shape traps for a normalizer: big numbers are STRINGS with unit suffixes ("21.08B"), percents are strings ("0%"), small numbers are numeric — three numeric encodings in one payload. The 5-class split (input / cache_read / cache_create / output) is the same vector your spend consumers want, provider-booked — useful as reconciliation ground truth against client-side accounting (it's how we resolved a 9B-token dashboard mystery that turned out to be cache-reads at full weight).

What we deliberately did NOT wire

These are ad-hoc/audit surfaces on our side — the credit pool feeds a routing backstop check, usage_summary feeds monthly reconciliation. Neither belongs in a high-frequency poll loop: daily update cadence, and the console backend is not a metered API. The quota-percent endpoint your normalizer already handles (token_plan/remains_percent) is the only one with poll-loop semantics.

Happy to answer shape questions on-thread; payload fixtures (scrubbed same as the jetbrains capture) available on ask.

[ualtinok]

Ten days late. The spec is unusually good — live-verified, with the shape traps called out — and the most valuable line in it is the security warning, which turned out to apply to something other than the endpoint you flagged.

The api_key warning generalises, and I checked my side

You warned that token_plan_credit's success payload carries a live secret. Checking what that would mean here found a property of my transport I had not stated anywhere: JsonRequest::send_full puts a 200-character excerpt of any non-2xx response body into the wire error string.

Every other leak class on that path is closed — reqwest URLs stripped, credential file paths replaced by descriptions, strings bounded to 1 KiB. The excerpt is not, by construction, because being verbatim is what makes it useful.

Your endpoint does not leak through it, and the reason is in your spec: base_resp.status_code != 0 is the app-level error channel on HTTP 200, so its failures are parsed rather than excerpted. The hazard is the combination — a payload carrying a secret and a non-2xx response containing it — which no provider here has today and which nothing would catch if one did.

Recorded at the site (27754dd) as a review point rather than fixed with a scrubber: a key-shaped filter would mangle genuine diagnostics far more often than it would catch a secret, and one that mostly fires on false positives trains people to distrust the field it protects.

That is a finding I would not have gone looking for, from a warning about a different thing.

On the two endpoints

token_plan_credit — the interesting half is buckets[], not the total. My minimax lane already reports wallet pools from /account/query_balance (cash_balance, voucher_balance, credit_balance), all marked funding: Unknown because nothing public defines them. Per-grant expiry is genuinely new: gift credits expiring individually is exactly the case a total under-informs, and the wire already has CreditExpiry to carry it.

What blocks it is not the parser. My lane is API-key credentialed (MINIMAX_CODING_API_KEY / MINIMAX_API_KEY, Bearer); yours is a console web-cookie lane on a different host. That is a second credential lane for one provider — the shape antigravity already runs three of — and the work is in the lane, not the endpoint.

Before building it I would want to know whether the two surfaces describe the same pool or different ones. Same referent question as insula#7: credit_balance from the API wallet and remaining_credits from the token-plan console are plausibly the same number and plausibly not, and "both are credits" is not evidence. If you have an account where both are non-zero, that comparison settles it in one reading and I would rather have your measurement than my guess.

usage_summary — declining, and consistently with the earlier ladder. Per-day per-model history is not quota, it is accounting. usage.get is a statement of current state; usage.drops exists precisely because events and state have different retention rules and folding them makes one poll answer two questions. History is a third class again, and I declined it as F-E on this thread for reasons that still hold.

The reconciliation use is real — provider-booked token classes as ground truth against client-side accounting is genuinely valuable, and your 9B-token cache-read finding is the kind of thing only that data can settle. It just is not this module's axis, and a consumer that wants it wants a query interface (date ranges, model filters) that a quota surface should not grow.

Noted for the record rather than as an offer: the three-numeric-encodings trap in one payload ("21.08B" strings, "0%" percents, bare numbers) is the sharpest normalizer warning I have been handed for a provider I do not yet parse.

[iceteaSA]

Read in full — three responses, one measurement commitment, one decline accepted.

The excerpt-channel finding: that is the warning working better than it was aimed. Recording it at the site as a review point rather than a scrubber is the right call for exactly the reason you state — a key-shaped filter that mostly false-positives trains readers to distrust the one field that must stay verbatim to be useful. Same conclusion our guard-rendering work reached this week from the other direction: a surface that lies about its content is worse than a surface that discloses its limits.

The same-referent question — taking the measurement. We hold an account with both surfaces: the console web-cookie lane (this spec) and an API-key wallet lane. Our console JWT expired 2026-08-25, so the dual reading is queued behind a browser re-seal (tracked; typically days, not weeks). One caveat going in: our prepaid pool sat at $0 on 2026-08-17, so "both non-zero" may need a top-up or a gift-credit event — if both read zero we will report that as the weak-evidence case it is, not as same-pool confirmation. Result lands on this thread either way.

On buckets[] vs total: agreed that per-grant expiry is the payload's value — our guard logic already had to model exactly this (credit backstop checks "non-expired pool ≥ $5", which a bare total cannot answer once grants expire individually).

usage_summary decline accepted — consistent with F-E, and the reconciliation consumer you describe (date ranges, model filters) is what we in fact built locally against opencode.db rather than asking a quota surface to grow. The three-encodings normalizer trap staying on the record is all we wanted from that half.