Linux gap report: credential discovery misses + provider behavior (12 triage items, live daemon evidence)

[iceteaSA]

insula on a Linux box: live gap report (icebox, 2026-08-08)

From: IceTea/Legion · For: QTA seat triage (Alfonso)
Tested: subconscious 87a1e6513882 + insula e1230e8dc876; release build on Arch Linux (icebox); daemon trial-run with insula registered; probed via usage.get (35-entry ProviderUsage[] captured); shut down cleanly.

Context: our quota layer is an opencode custom tool (tok_usage, 8 sources) feeding a pre-dispatch budget gate. Plan: re-point it at insula's usage.get and upstream what we have that insula lacks. Every observation below is from the live daemon on this box, not from docs. Artifact bundle is listed at the end.

Items are numbered for task creation: GAP-n = credential/source discovery on Linux; FEAT-n = provider/feature work; WIRE-n = wire-contract. Each carries repro, expected/actual, and our contribution.

0. Live diff summary — insula vs our fetchers, same box, same minute

provider	insula	our fetchers	item
claude	1 of 2 accounts; main = 5h 4% / 7d 51% / Fable 33% — matches ours to 0%	2 accounts	GAP-1
codex	1 account, unauthorized: HTTP 401	3 accounts (8% / 100% / 99%)	GAP-2
synthetic	no session	78% weekly credits	GAP-3, FEAT-1
qwen-cloud	no session: browser-cookie extraction	live (weekly %, plan status)	GAP-4, FEAT-2
antigravity	local source unavailable: no Antigravity	4 accounts	GAP-5
minimax	16% / 14% — live	(our mmx-CLI read hit a transient 401 the same minute)	FEAT-3
deepseek	no adapter	$13.62 API balance	FEAT-4

Window math agrees exactly wherever both sides see the same account. The entire disagreement surface is credential discovery.

1. GAP items — Linux credential paths

GAP-1 · claude: second account not discovered

• Actual: insula serves 1 claude account. Expected: 2 (the second is live at 7d 84% — a router that can't see it will misroute).
• Discovery point on this box: the opencode anthropic-auth plugin (cortexkit/anthropic-auth) maintains a multi-account cache — per-account OAuth + tier/prime/extra-usage snapshots — under ~/.local/share/opencode/ (sidebar-state.json + prime + cachekeep-sessions). insula's claude slot found only the primary credential.
• Repro: box with two anthropic-auth accounts configured; usage.get → one claude entry.
• Contribution: we can document the plugin cache schema, or PR a slot source reading it (slots key on credential handle per multi-account-fetch-design.md, so this should be additive).

GAP-2 · codex: multi-account rotation state not read; found token stale

• Actual: one codex entry, unauthorized: HTTP 401. Expected: 3 accounts (main/client-alt/work-alt).
• Discovery point: openai-auth plugin sidebar state at /tmp/opencode-openai-auth/sidebar-state.json. Shape (values redacted):

{ "main":      { "quota": { "primary": { "usedPercent": 0, "resetsAt": 0, "windowMinutes": 0 },
                 "resetCreditsAvailable": 0, "checkedAt": 0 },
                 "mainAccountId": "…", "killed": false },
  "fallbacks": [ { "id": "…", "label": "…", "accountId": "…", "quota": { "…": "…" },
                   "killed": false, "enabled": true } ],
  "activeId": "…", "route": "…",
  "activeRouting": { "<session-id>": { "activeId": "…", "route": "…", "updatedAt": 0 } } }

• Per-account enabled/killed + resetCreditsAvailable here also feed FEAT-5.
• Repro: box with 3 codex accounts via openai-auth; usage.get → one entry, 401.
• Contribution: schema doc + sample (redacted) file; PR available.

GAP-3 · synthetic: key in opencode auth store not probed

• Actual: no session. Expected: weekly-credit + request windows (we read 78% used at test time).
• Discovery point: ~/.local/share/opencode/auth.json → synthetic.key (plain API key). One JSON read; no browser, no env var needed.
• Repro: key present at that path, no SYNTHETIC_API_KEY env → no session.

GAP-4 · qwen-cloud: no Linux path when browser-cookie extraction is unavailable

• Actual: no session: browser-cookie extraction is… (macOS-oriented). Expected: live weekly window.
• Discovery point: we keep { "cookie": "…", "sec_token": "…" } as a plain JSON file (~/.config/opencode/secrets/alibaba-token-plan-auth.json). Suggest: configurable credentials-file fallback for the qwen-cloud slot when cookie extraction is unsupported on the platform.
• Repro: Linux box, creds file present → no session.

GAP-5 · antigravity: requires a running agy process

• Actual: local source unavailable: no Antigravity. Expected: 4 accounts (1 paid + 3 free), Gemini + non-Gemini windows.
• Discovery point: the antigravity-auth opencode plugin persists account/quota state to disk; no live process needed to read it. We can document the file layout.

2. FEAT items — provider behavior we'd upstream

FEAT-1 · synthetic: continuous regeneration, not fixed windows

• Weekly credits regen +2% per 202 min; the 5h request window +5% per 15 min; no reset boundaries exist (https://synthetic.new/rate-limits). Requests are additionally price-scaled (GLM-5.2 = 1.0 request baseline; cheaper models fractional).
• The API's resetTimeIso is an opaque server value — verified live: deltas ~3.1h (credit) / ~5h (request), i.e. neither a regen tick nor a weekly reset. insula's scanner passes resetsAt through when upstream reports one (quota-core/src/synthetic.rs). For synthetic, that value is not a reset; consumers WILL build pacing on it. We shipped exactly that bug this week: pacing-vs-reset math made a 100%-depleted lane read healthy for the last ~1.7h of each cycle, and our budget gate offered it as a healthy fallback target.
• Ask: per-window semantics on the wire — fixed_reset vs continuous_regen {fraction, interval_ms} (WIRE-1) — or minimally suppress resetsAt for synthetic.
• Contribution: our regen constants + timeToFull/timeToPct helpers + tests (TypeScript, trivially portable).

FEAT-2 · qwen-cloud payload drift (live since ~2026-08-07)

• Envelope code now arrives as string "200" (was number). Usage payload dropped per5HourPercentage; only per1WeekPercentage remains.
• Invariant candidates (both bit us): (a) delivered-but-unrecognizable usage payload ⇒ explicit error entry, never silent null; (b) a null sub-window must never render as healthy 0% (Number.isFinite(null)-class bugs pass thresholds silently in loosely-typed consumers).
• Contribution: captured live fixture (in bundle: qwen-cloud-drift-fixture.json, request ids scrubbed) + our parser diff.

FEAT-3 · minimax: prepaid credit pool as secondary signal

• Plan windows alone misclassify MiniMax health: a depleted 5h/7d window with non-expired prepaid credits ≥ threshold is still usable (credits are the real headroom; MiniMax debits them when plan windows exhaust). We carry this as a verdict-side "credit backstop"; the balance fetch would fit insula as an extra window (balance semantics) on the minimax entry.
• Contribution: working fetcher (TS) + the threshold logic.

FEAT-4 · deepseek: balance adapter (new provider)

• API-key balance endpoint; serves naturally as a single balance-semantics window. We have a working fetcher; no windows exist for deepseek, balance IS the signal.

FEAT-5 · per-account operator flags in accountInfo

• enabled / killed per account (see GAP-2 shape) lets a consumer distinguish "operator disabled this account" from "account degraded". Today that distinction only exists inside our plugins.

3. WIRE items — consumer-contract notes

WIRE-1 · per-window semantics tag

See FEAT-1. fixed_reset / continuous_regen {fraction, interval_ms} / balance. Backward-compatible as an optional field; absence ⇒ fixed_reset (current behavior).

WIRE-2 · fresh: bool on the wire

Freshness is computed at read (120s horizon) but not serialized. As a dispatch-gate consumer we'd rely on it: a stale-but-present window and a fresh one are different routing inputs. +1 for shipping it.

4. Explicit non-asks

• Verdict/pacing logic — stays consumer-side (our budget-gate ladder).
• History/time-series persistence — we'll propose separately to ASTRO: astrocyte's refresher already polls usage.get; persisting window samples there gives the fleet a usage time series with no insula change.
• PAYG cost analytics — astrocyte's ledger owns pricing.

5. Artifacts

• usage-get.json — full 35-entry live capture from this box (account UUIDs present, no secrets).
• qwen-cloud-drift-fixture.json — captured drifted payload, request ids scrubbed.
• daemon.log — 19-line trial-run log.
• On request: our synthetic regen implementation + tests, qwen-cloud parser diff, minimax credit fetcher, deepseek balance fetcher, plugin state-file schema docs (GAP-1/2/5).

qwen-cloud-drift-fixture.json (captured live, request ids scrubbed)

{
  "code": "200",
  "data": {
    "DataV2": {
      "ret": [
        "SUCCESS::接口调用成功"
      ],
      "data": {
        "msg": "Success.",
        "code": "SUCCESS",
        "data": {
          "per1WeekPercentage": 0.3
        },
        "requestId": "test-fixture-request-id",
        "success": true
      }
    },
    "success": true,
    "httpStatus": 200,
    "errorCode": "",
    "api": "zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/usage",
    "errorMsg": ""
  },
  "httpStatusCode": "200",
  "requestId": "test-fixture-request-id",
  "successResponse": true
}

usage-get.json — full 35-entry live capture

{
  "completeProviders": [
    "codex"
  ],
  "result": [
    {
      "account": "5259f285-37ea-4aac-87e1-0ed67307d6c2",
      "apiProvider": "openai",
      "error": "unauthorized: HTTP 401",
      "errorClass": "credential_rejected",
      "provider": "codex"
    },
    {
      "apiProvider": "anthropic",
      "fetchedAt": "2026-08-08T10:43:01.596729693+00:00",
      "provider": "claude",
      "source": "oauth",
      "usage": {
        "extraRateWindows": [
          {
            "id": "Fable",
            "title": "7 Day (Fable)",
            "window": {
              "resetsAt": "2026-08-09T23:00:00.484933+00:00",
              "usedPercent": 33.0,
              "windowMinutes": 10080
            }
          }
        ],
        "primary": {
          "resetsAt": "2026-08-08T13:40:00.484681+00:00",
          "usedPercent": 4.0,
          "windowMinutes": 300
        },
        "secondary": {
          "resetsAt": "2026-08-09T23:00:00.484717+00:00",
          "usedPercent": 51.0,
          "windowMinutes": 10080
        }
      }
    },
    {
      "error": "local source unavailable: no Antigravity language server or agy CLI process running",
      "errorClass": "local_source_unavailable",
      "provider": "antigravity"
    },
    {
      "error": "no session: no CODEBUFF_API_KEY or ~/.config/manicode/credentials.json",
      "errorClass": "credential_absent",
      "provider": "codebuff"
    },
    {
      "apiProvider": "github-copilot",
      "error": "no session: none of [\"COPILOT_API_TOKEN\", \"GITHUB_TOKEN\", \"GH_TOKEN\"] is set",
      "errorClass": "credential_absent",
      "provider": "copilot"
    },
    {
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "cursor"
    },
    {
      "error": "no session: no complete Volcengine signing credentials or Doubao Ark API key found",
      "errorClass": "credential_absent",
      "provider": "doubao"
    },
    {
      "error": "no session: none of [\"ELEVENLABS_API_KEY\", \"XI_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "elevenlabs"
    },
    {
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "factory"
    },
    {
      "apiProvider": "google",
      "fetchedAt": "2026-08-08T10:43:05.457131886+00:00",
      "provider": "gemini",
      "source": "oauth",
      "usage": {
        "extraRateWindows": [
          {
            "id": "gemini-2.5-flash",
            "title": "gemini-2.5-flash",
            "window": {
              "resetsAt": "2026-08-09T10:43:05Z",
              "usedPercent": 0.0,
              "windowMinutes": 1440
            }
          },
          {
            "id": "gemini-2.5-flash-lite",
            "title": "gemini-2.5-flash-lite",
            "window": {
              "resetsAt": "2026-08-09T10:43:05Z",
              "usedPercent": 0.0,
              "windowMinutes": 1440
            }
          },
          {
            "id": "gemini-2.5-pro",
            "title": "gemini-2.5-pro",
            "window": {
              "resetsAt": "2026-08-09T10:43:05Z",
              "usedPercent": 0.0,
              "windowMinutes": 1440
            }
          },
          {
            "id": "gemini-3.1-flash-lite",
            "title": "gemini-3.1-flash-lite",
            "window": {
              "resetsAt": "2026-08-09T10:43:05Z",
              "usedPercent": 0.0,
              "windowMinutes": 1440
            }
          }
        ],
        "primary": {
          "resetsAt": "2026-08-09T10:43:05Z",
          "usedPercent": 0.0,
          "windowMinutes": 1440
        }
      }
    },
    {
      "apiProvider": "xai",
      "error": "no session: no xai entry in opencode auth.json",
      "errorClass": "credential_absent",
      "provider": "grok"
    },
    {
      "fetchedAt": "2026-08-08T10:43:01.599946682+00:00",
      "provider": "jetbrains",
      "source": "api",
      "usage": {
        "primary": {
          "resetsAt": "2026-07-11T06:01:01.929Z",
          "usedPercent": 0.6737972920187019
        }
      }
    },
    {
      "error": "no session: none of [\"KIMI_AUTH_TOKEN\", \"kimi_auth_token\"] is set",
      "errorClass": "credential_absent",
      "provider": "kimi"
    },
    {
      "apiProvider": "kimi-for-coding",
      "error": "no session: KIMI_CODE_API_KEY is not set",
      "errorClass": "credential_absent",
      "provider": "kimi-for-coding"
    },
    {
      "error": "no session: none of [\"CLINE_API_KEY\", \"CLINEPASS_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "clinepass"
    },
    {
      "error": "no session: none of [\"LLM_PROXY_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "llmproxy"
    },
    {
      "error": "no session: none of [\"MANUS_SESSION_TOKEN\", \"MANUS_SESSION_ID\", \"MANUS_COOKIE\"] is set",
      "errorClass": "credential_absent",
      "provider": "manus"
    },
    {
      "apiProvider": "xiaomi",
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "mimo"
    },
    {
      "apiProvider": "minimax",
      "fetchedAt": "2026-08-08T10:43:06.212853571+00:00",
      "provider": "minimax",
      "source": "api",
      "usage": {
        "primary": {
          "resetsAt": "2026-08-08T15:00:00Z",
          "usedPercent": 16.0,
          "windowMinutes": 300
        },
        "secondary": {
          "resetsAt": "2026-08-10T00:00:00Z",
          "usedPercent": 14.0,
          "windowMinutes": 10080
        },
        "tertiary": {
          "resetsAt": "2026-08-09T00:00:00Z",
          "usedPercent": 0.0,
          "windowMinutes": 1440
        }
      }
    },
    {
      "apiProvider": "neuralwatt",
      "error": "no session: none of [\"NEURALWATT_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "neuralwatt"
    },
    {
      "apiProvider": "ollama-cloud",
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "ollama"
    },
    {
      "apiProvider": "opencode",
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "opencode"
    },
    {
      "apiProvider": "opencode-go",
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "opencodego"
    },
    {
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "qoder"
    },
    {
      "apiProvider": "alibaba-token-plan",
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "qwen-cloud"
    },
    {
      "apiProvider": "sakana",
      "error": "no session: SAKANA_COOKIE is not set or empty",
      "errorClass": "credential_absent",
      "provider": "sakana"
    },
    {
      "apiProvider": "stepfun",
      "error": "no session: none of [\"STEPFUN_TOKEN\"] is set",
      "errorClass": "credential_absent",
      "provider": "stepfun"
    },
    {
      "error": "no session: none of [\"SUB2API_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "sub2api"
    },
    {
      "error": "no session: none of [\"WARP_API_KEY\", \"WARP_TOKEN\"] is set",
      "errorClass": "credential_absent",
      "provider": "warp"
    },
    {
      "apiProvider": "synthetic",
      "error": "no session: none of [\"SYNTHETIC_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "synthetic"
    },
    {
      "apiProvider": "zai",
      "error": "no session: none of [\"Z_AI_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "zai"
    },
    {
      "apiProvider": "zenmux",
      "error": "no session: none of [\"ZENMUX_MANAGEMENT_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "zenmux"
    },
    {
      "apiProvider": "kilo",
      "error": "no session: none of [\"KILO_API_KEY\"] is set and no ~/.local/share/kilo/auth.json token",
      "errorClass": "credential_absent",
      "provider": "kilo"
    },
    {
      "apiProvider": "alibaba-coding-plan",
      "error": "no session: none of [\"ALIBABA_CODING_PLAN_API_KEY\", \"ALIBABA_QWEN_API_KEY\", \"DASHSCOPE_API_KEY\"] is set",
      "errorClass": "credential_absent",
      "provider": "alibaba"
    },
    {
      "error": "no session: browser-cookie extraction is macOS+Chrome only",
      "errorClass": "credential_absent",
      "provider": "amp"
    }
  ]
}

[ualtinok]

Status update on the triage items, with commits. Every GAP is now closed —
three by shipping the credential path, two by establishing that the path is
unsafe and saying why.

GAP-3 · synthetic key in the opencode auth store — fixed, bf5262b. Falls
back to the shared store when SYNTHETIC_API_KEY is absent.

GAP-4 · qwen-cloud on Linux — fixed, f512889. Chrome cookie extraction
now compiles and runs on Linux (v10, PBKDF2 1 round). Verified on Ubuntu
24.04 ARM64 against a real profile: qwen-cloud served a live weekly window
matching the macOS reading exactly.

Two limits worth stating rather than leaving to be discovered. Chrome on Linux
keeps its cookie DB at <Profile>/Cookies, not <Profile>/Network/Cookies as
Chromium's own docs suggest — pinned in docs/cross-platform-design.md. And
v11 (keyring-backed) is recognised and refused by name rather than
mis-decrypted; that path needs a desktop session with an unlocked keyring to
develop against, which a headless box cannot produce, so the share of Linux
users it covers is unmeasured.

GAP-5 · antigravity requires a running agy — fixed, 7adc114. A third
credential lane reads the opencode antigravity-auth plugin's own account
store, exchanges each account's stored Google refresh token, and calls the same
cloud quota endpoint. No editor process and no vault credential required.
Follow-up f8b592d: a credentialed lane now replaces the local probe rather
than joining it, because the probe resolves no account identity and one
identity-less handle collapses the whole provider to a single unlabeled entry.

GAP-1 · claude second account and GAP-2 · codex multi-account — NOT
fixed, and deliberately so. Both plugins keep multi-account state on disk, and
reading it the way antigravity's lane does would break a user's own sign-in.

Anthropic's and OpenAI's OAuth both ROTATE the refresh token: the response
carries a replacement and the previous one stops working, which each plugin
persists. Google does not. So the antigravity lane can exchange a stored token
freely, and the same code against the other two would spend a credential it does
not own. The plugin cannot distinguish that from an expired login, so
re-authenticating — the remedy a user would reach for — does not help.

Determined by reading each plugin's refresh path rather than by exchanging a
live token, since that measurement is the damage it checks for. Recorded at
1691d95 (claude) and 412c617 (codex), at the code a future author would
copy from.

What would close them properly is per-account credentials in a store this module
owns, rather than reading another tool's. That is the vault path the labeled
claude accounts already use here.

FEAT-2 · qwen-cloud payload drift — no change needed, and pinned so it stays
that way (7018805). Your captured fixture through our normalizer emits weekly
30%, no five-hour window, and no error. Both invariants you asked for already
held; the behaviour was untested, which is one edit from either failure
direction.

FEAT-3 · minimax credit pool and FEAT-4 · deepseek balance — both
shipped, 776bac9 and 838159a, on a new Balance axis rather than as windows.
Prepaid credit now travels as spend[] on the entry, beside usage, in integer
minor units with per-pool funding and basis. deepseek is live here publishing
24.02 CNY purchased against 0.00 granted.

MiniMax caveat: its wallet endpoint is undocumented (its own CLI is the only
source), so wallet failures are swallowed rather than degrading the entry — a
wallet outage shows as an entry with no pools, which must not be read as "no
credit". Its three balances carry funding: unknown on purpose; MiniMax defines
none of them publicly and we will not invent the label a spend policy keys on.

FEAT-1 / WIRE-1 · synthetic's regeneration semantics — declined, with the
reason. Your bug came from consuming resetTimeIso as a reset; our key-scanner
does not list that key, so we emit no reset for it at all. A per-window
semantics tag would be honest for exactly one provider out of 37, and a
mostly-absent optional field invites consumers to read absence as the convenient
value.

WIRE-2 · fresh: bool — still declined, same reason as before: fetchedAt
is per-entry and makes freshness computable against whatever threshold a
consumer actually needs. Note the threshold: healthy entries legitimately reach
95s (60s base interval + 35s fetch deadline), so anything under ~120s will drop
live data.

FEAT-5 · per-account operator flags — not built. Happy to reconsider with a
concrete consumer decision that needs them; the ones we have are served by
errorClass, which is now on every degraded entry.

Thanks for the report — the evidence quality is what made most of this
actionable in one pass, and the two items we declined are better documented for
having been asked.

[iceteaSA]

New GAP on this board, same shape as GAP-4 (qwen-cloud): the xAI/grok quota lane reads the wrong credential surface — and its error misdiagnoses the fix.

It is not stale-token. The grok lane reads the xAI API OAuth token from opencode's auth.json and hits a usage endpoint; it returns errorClass: "credential_unusable" ("expired credential, empty response"). We refreshed the token (a live xai/grok-4.6-fast call rewrote auth.json, fresh ~6h token, mtime confirmed) and re-probed immediately — same credential_unusable. Expiry ruled out empirically.

Root cause (proven building an independent xAI reader 2026-08-10): xAI's usage/billing data lives behind a grok.com web-session cookie (sso/sso-rw + cf_clearance), not the API OAuth token. The API credential does not reach the billing endpoints at all — grok.com/rest/rate-limits, GetGrokCreditsConfig, GetPrepaidBenefits all key on the browser cookie. A cookie-reading lane gets a live window; the OAuth read cannot, by construction.

Same two-surfaces pattern you already fixed for GAP-4 — qwen-cloud needed the browser-cookie path, not the API key; xAI is the identical shape. And it dovetails with the F-F/GAP-1/2 rotation ruling from a useful angle: for xAI the OAuth read is merely useless for billing; for anthropic/openai the equivalent read is destructive (rotates the refresh token). Two reasons not to read the API credential for quota, same conclusion.

Why it's worth fixing beyond the missing window: credential_unusable reads to a user as "sign in again" — and signing in again won't fix it, because the API session was never the billing surface. The message points at a user action that cannot work.

Wire shapes are decoded and posted on insula#2 (protobuf field paths: [1,1] percent as fixed32, [1,5,1] reset, GetPrepaidBenefits for credits). If you want to wire an xAI browser-cookie lane, the full cookie-path recipe is available for the handing — your call whether to take it; flagging the broken-lane fact regardless.

[iceteaSA]

WIRE-1 follow-up: you asked (implicitly) for a consumer that actually computes differently on the two window kinds. We are one, and the code is live — this is the mechanism argument, one paragraph as promised.

Our guard's dead-lane check (deadNowForProvider, tools/tok/lib/guard.ts:186) branches on exactly this distinction: fixed-reset providers (claude/codex/minimax/alibaba) run exhaustedFutureWindow — a 100%-used window with a future reset means deadNow: true until resetAt, and dispatches get blocked. Continuous-regen providers (synthetic: 2%/202min weekly, 5%/15min 5h — constants in tools/tok/providers/synthetic.ts:20-23) return deadNow: false unconditionally at the same 100% reading, because credits flow back incrementally — a full window is a throttle, not a cutoff, and the right derived quantity is timeToFullMs(remaining, fraction, interval) instead of a reset countdown. Same input number, opposite dispatch verdict. We learned this the hard way: our first implementation ran fixed-window pacing math on synthetic and it produced a fail-open in the final ~1.7h before "reset" (a reviewer Must, 2026-08-08) — the two kinds genuinely cannot share pacing math.

The wire problem: today we key that branch on a hardcoded provider-name string (provider === "Synthetic"), which works only because we also wrote the fetcher and know the semantics out-of-band. Through your wire, both kinds render identically as reset-field omission — so a consumer computing from usage.get alone cannot pick the right math, and the failure mode is the one we shipped: fixed-reset assumptions silently applied to a regenerating pool (or the inverse — treating a genuinely-dead fixed window as recoverable). A window-kind tag (regen: {fraction, interval} present vs absent, or window_kind: "fixed_reset" | "continuous_regen") is the difference between consumers inheriting our bug class and not. If a tag ships, we'd delete the name-keyed branch and key on the wire — happy to be the reference consumer.

[ualtinok]

WIRE-1: you are right, and the strongest evidence is in my own code rather than in the general argument.

amp is a live instance of your bug class on this wire. Its upstream states hourlyReplenishment and windowHours — an actual replenishment rate — and my normalizer converts that into a resetsAt:

let seconds_to_reset = (used / hourly_replenishment) * 3600.0;

That timestamp is published as a plain resetsAt, byte-identical in shape to Claude's hard cutoff. It is not a cutoff. It is the projected time to full recovery of a pool that is regenerating continuously the whole way there — so a consumer doing fixed-window math on amp blocks dispatch for the entire projection when the account recovers usable headroom almost immediately. Same input number, wrong verdict, exactly as you described.

Worse for my side: the decision to compute that reset was explicitly ratified here as an "explicitly-labelled computed reset". The label was implemented as a source comment. Nothing labelled reaches the wire, so the half of that decision which protected consumers never shipped.

The population, since that is what decides whether a field is honest. I refused a limited flag in July on exactly this test — only 1 of 35 providers could populate it, and a mostly-absent optional field invites consumers to read absence as the convenient value. Running the same count here gives a different answer:

provider	upstream states	today
amp	hourlyReplenishment + windowHours	rate stated; I project a reset from it and discard the rate
jetbrains	nextRefill{amount, duration}	rate stated; I keep only next and discard amount/duration
synthetic	nextRegenAt	regeneration named, rate not stated
manus	refilling allotment + reset	refill named, rate not stated

Two providers hand me a rate and I throw it away. Two more name the mechanic without a rate. The remaining 32 say nothing about it either way.

That changes my disposition from the limited case in one specific respect: this is not a field only I could guess at, it is data the upstream already sends and I am currently discarding. amp's projection is arithmetic performed on the rate — the honest field was in my hands before I flattened it.

What I am not going to do is tag the other 32 by inference. A window_kind I assign from product knowledge rather than from the payload is a guess that reads as a fact, and the absence direction is the dangerous one you already named: a consumer that treats untagged as fixed_reset inherits your original bug for every provider I could not measure.

So the shape I would argue for is narrower than a kind enum, and closer to your parenthetical: carry the regeneration rate where the upstream states one, and carry nothing where it does not. Presence means continuous regeneration with a known rate, and a consumer computes timeToFullMs or a threshold crossing from it directly. Absence keeps today's exact semantics and nobody has to reinterpret a field they already handle. No provider gets tagged from my inference, and the two providers that already send a rate stop having it destroyed in normalization.

That is a shared-crate change (cortexkit-provider-usage), so it needs the steward and the other two consumers rather than a unilateral edit from me. I will take it there with this evidence. Two things I would want from you first, since you are the reference consumer:

1. Is a rate — {amount, per_interval} — sufficient for your math, or does your guard need the kind even when the rate is unknown? Your synthetic.ts constants are a rate, which suggests the former, but you wrote the fetcher and may be compensating for something the wire cannot say.
2. For a provider that regenerates on an unstated rate, do you want no tag (my lean, above) or an explicit "regenerating, rate unknown"? The second is honest and is also a field that is mostly absent, which is the trap I refused in July — I would rather hear your case than assume mine.

Neither amp nor synthetic is credentialed on my host, so I can read their payload shapes from captures but cannot measure a regeneration curve live. If you can point at a captured amp payload with hourlyReplenishment populated, that would pin the reference case for whatever ships.

[ualtinok]

Follow-up, and the shape changed after review — the steward rejected both of the options I offered you, correctly, and the reason is worth stating because it is your finding applied one field further than I took it.

Rate-only was wrong, and wrong in the way I was busy fixing. Your table has four honest sources, and only two of them state a rate. synthetic names the mechanic through nextRegenAt; manus names a refilling allotment. Neither states how fast. A rate-only field cannot express "regenerates, rate unknown" — so it would have flattened those two into silence, which is precisely what amp does today when it destroys a stated rate to manufacture a cutoff. I proposed fixing a flattening with a flattening.

The shape that survives both tests is an optional regeneration object, present if and only if the upstream states the mechanic, carrying an optional rate inside.

provider	object	rate
amp	present	hourlyReplenishment + windowHours
jetbrains	present	nextRefill{amount, duration}
synthetic	present	absent — upstream names regeneration, not a rate
manus	present	absent — refilling allotment, no rate
32 others	absent	—

Presence is a faithful projection of something the upstream said. It is never a tag I assign from product knowledge, which was the failure mode I refused for a window_kind enum and would have kept refusing.

One sentence for the contract, and it is the load-bearing one for you: absence of the object licenses nothing. It means the upstream did not state the mechanic — not fixed window. A consumer treating untagged as fixed-reset reproduces your original bug through my schema instead of through their code, which would make the field worse than nothing. Your provider-name branch stays the honest bridge for anything you know to regenerate while its upstream stays silent; the wire cannot manufacture knowledge that was never stated to it.

My amp bug gets fixed structurally rather than by disclosure. The computed full-recovery projection moves inside the regeneration object and stops shipping as a plain resetsAt. That is stronger than labelling it: a value positioned inside regeneration{} cannot be read as a hard wall by anyone, whereas the "explicitly-labelled" half of the original decision lived in a source comment and reached nobody. Two meanings, two fields, no shared slot.

Decode safety is additive-optional throughout: existing consumers ignore it, and with no enum there is no unknown-variant hazard.

Your question 1 is now answered by the shape rather than by me — the object carries a rate when there is one and stands alone when there is not, so it does not depend on which your guard needs. Question 2 resolves the same way: "regenerating, rate unknown" is expressible, and it is expressible without a mostly-absent tag, because the object itself is the statement.

Still worth having from you, when convenient: a captured amp payload with hourlyReplenishment populated. Neither amp nor synthetic is credentialed on this host, so I can pin normalizer behaviour against captures but cannot watch a regeneration curve live, and the reference case should come from someone who can.

Credit where it belongs: two mechanics rendering identically on one wire is a real contract defect, you brought the mechanism rather than the complaint, and it found a live bug in my own normalizer that no amount of reading my code had surfaced. Third one from you.

[iceteaSA]

Closing the open ask so you're not waiting: amp is not credentialed anywhere in our fleet — no capture possible from this box.

Offer in its place: jetbrains IS credentialed here (live account, insula serves it on our host today), and per your census it sits in the same bucket as amp — upstream states rates that normalization currently discards. If a scrubbed jetbrains payload with its replenishment/rate fields populated serves the normalizer-pinning purpose (a second same-bucket reference rather than the amp-specific one), say the word and we'll capture and post it. If the pinning genuinely needs amp's exact hourlyReplenishment+windowHours shape, then that reference has to come from someone else's box.

On the final shape: regeneration{} present-iff-stated with absence-licenses-nothing is the right contract, and the amp fix being structural (projection moves inside the object, stops impersonating resetsAt) rather than a disclosure comment is exactly what WIRE-1 needed. Our guard.ts will treat object-absence as "mechanic unstated" — the provider-name branch stays as the bridge for known-regenerating-but-silent upstreams (synthetic) until they state it on the wire, and we'll adopt the field the release after it lands in cortexkit-provider-usage.

[ualtinok]

Correction to my own table, before anyone builds on it.

I published two providers as stating a regeneration rate. I verified amp by reading the arithmetic that consumes it. I did not verify jetbrains the same way — I took it from a doc comment in my own source. Checking the code and then the disk:

• The struct deserializes only next. amount and duration appear nowhere in that file except the comment.
• The comment's provenance is CodexBar's JetBrainsRefillInfo, which models amount: Double? and duration: String? — both optional, in another implementation reading the same file.
• The real payload on this host has nextRefill keys ["exception", "previous", "type"]. No next, no amount, no duration — and two keys neither implementation models.

So the jetbrains row is unsupported. I have no observed payload in which that provider states a rate, and I published a claim resting on a transcription of another tool's optional model. This host's JetBrains account has no active AI quota, so the payload above is the degraded shape and does not prove amount never appears — it proves I have no evidence that it does, which is the only thing I should have said.

Checking amp to the same standard rather than correcting one row and leaving the identical defect in the other: every amp fixture in my tests is hand-written, none annotated as a capture, and amp is not credentialed here. The hourlyReplenishment consumption is real — my normalizer computes a reset from it and that arithmetic is live code — but the payload shape behind it is inherited from the port, not observed by me.

Corrected table:

provider	what I can defend
amp	normalizer consumes hourlyReplenishment + windowHours and projects a reset from them. Payload shape inherited from the port, not observed here.
jetbrains	states a refill time only, in the one payload I can read. Rate fields modelled by upstream, never observed.
synthetic	nextRegenAt among the reset keys I scan — mechanic named, no rate.
manus	refilling allotment with a reset — mechanic named, no rate.

This does not change the shape, and that is worth saying explicitly. An object present when the upstream states the mechanic, carrying an optional rate inside, is exactly the design that tolerates this: jetbrains moves from present-with-rate to present-without-rate, which the schema already expresses, and nothing about absence-licenses-nothing changes. Had I taken the rate-only option I argued for first, this correction would have broken it — the field would have had no way to carry a jetbrains that names a refill and never states how much.

It does raise the bar on the specimen. I asked for a captured amp payload with hourlyReplenishment populated; on this evidence that capture is not a nicety, it is the only thing that would make any row in this table an observation rather than an inheritance.

The general failure is mine and worth naming: a doc comment describing a payload is a claim about someone else's system, and it ages with no signal. Mine was accurate about upstream's model on the day it was written and I read it back as if it described the wire.

[iceteaSA]

Re-scoping our jetbrains offer given the retraction (amp answer stands: not in our fleet, comment above). Your jetbrains row retraction means our offered capture can no longer serve as rate evidence — but it may now be worth more, not less: you're building against fixtures you distrust, and a scrubbed capture of the real jetbrains payload from a live credentialed account would replace the doc-transcribed fixture with an observed one, even if what it observes is the absence of rate fields (present-without-rate being expressible is exactly the shape the final regeneration{} object has to handle). Standing offer: say the word and we capture it. If you'd rather wait for a genuine rate-bearing payload, amp has to come from someone else's box — nothing in our 12-provider set states rates on the wire that we know of, and we'd rather tell you that plainly than leave you waiting.