99.62% of the account's AI value is "Payer not established" — one stored claude-code token would resolve it, and nothing on any surface says so

[serge-ivo]

Two credentials, two independent limits, one bucket labelled "unknown"

This account is hitting two different ceilings on two different Anthropic credentials:

• The Claude Code subscription's session limit — the "hit the session limit again" reports, and the 250M-token circuit breaker kills documented in [decision] Demote AI budget circuit breakers to observe-only (BUDGET_ENFORCE, default off) — keep structural caps + meter; re-enable at paid launch #485.
• The Anthropic API key's credit balance — verified in the error log, 2026-08-12 06:59:49 and 07:07:09, repeat_count: 2, instance f8ddc272 (Heartfull):

  Anthropic (400): Your credit balance is too low to access the Anthropic API.
at runAnthropic … chatComplete … runAgentThink … AgentDO.runTurn

The Usage page cannot separate them, because 99.62% of the account's notional value sits in the unknown payer bucket — and it does not have to. The platform already has the mechanism to resolve it, it is one stored token, and no surface says so.

Measured — the whole causal chain, end to end

1. No Claude Code sign-in token is stored. GET /v1/keys/status, production, 2026-08-13:

   { "id": "claude-code", "name": "Claude Code (Coder engine sign-in)", "hasKey": false, "createdAt": null }

2. Every Repo Coder preset runs auto. lib/coding-engines.ts:50-56, resolveEngineEnv:

   // "subscription" | "auto" — the stored `claude setup-token`.
   const token = await getUserProviderKey(env, uid, "claude-code");
   // No stored setup-token → fall through to the machine's OWN login …
   if (!token) return stripProviderKey;                       // → { ANTHROPIC_API_KEY: "" }

3. The runner deletes on empty, so the merged env has neither var. packages/browser-runner/src/coding/headless.ts:15-25:

   if (v === "") delete out[k];

4. The runner therefore reports machine-login. packages/browser-runner/src/coding/engine-auth.ts:63-67 — neither ANTHROPIC_API_KEY nor CLAUDE_CODE_OAUTH_TOKEN present → return "machine-login".
5. machine-login maps to NULL, deliberately. lib/usage-payer.ts:78-82:

   if (resolved === "api-key") return "byok-api";
   if (resolved === "subscription") return "subscription";
   return null;

6. NULL is excluded from every money figure. lib/usage.ts:369 (isCharged(null) === false) and CHARGED_SQL (usage-payer.ts:62).

What that costs, in numbers

usage_summary, range: "all", 2026-08-13:

byPayer  unknown        $9,584.87   3,462 calls   99.62% of notional value
         byok-api          $36.34   1,866 calls
         platform           $0.02     393 calls
         subscription   (no bucket — ZERO rows have ever resolved to it)
byKind   engine        $9,541.31     449 calls   ← 99.5% of the unknown bucket

Cross-check that the engine rows really are the unknown bucket: unknown.outputTokens (3,603,049) − engine.outputTokens (3,283,599) = 319,450, and 319,450 + byok-api (232,914) + platform (16,202) = 568,566 = exactly totals.outputTokens − engine.outputTokens. The identity closes to the token, on both the output and the cache-read column. All 449 engine rows are payer-unknown.

Why this is a bug and not just an honest NULL

The NULL itself is correct and #92's refusal to guess is right. What is missing is that the platform knows how to make it knowable and never tells the owner. Every one of these is already true today:

• resolveEngineEnv will inject CLAUDE_CODE_OAUTH_TOKEN the moment a claude-code key exists (coding-engines.ts:58-61) — for both auto and subscription modes.
• That flips step 4 to "subscription", step 5 to payer: "subscription", and the Usage page's largest row from "Payer not established" to "Drawn from a subscription" with the existing note (usage-payer.ts:PAYER_NOTE): "No per-token charge; it draws your plan's allowance, which is measured in tokens over a rolling window."
• That is exactly the sentence this owner needs, because it is the sentence that separates his $36 API bill from his subscription's session limit.
• Choosing api-key mode instead resolves to byok-api and folds the engine into the charged total — the other correct answer, for someone who genuinely is paying per token.

Today the console's ⚙ CLI engines panel offers all four modes with no indication that three of them leave the platform unable to attribute the resulting spend, and GET /v1/keys/status shows claude-code as just one more provider row among thirteen.

What to do, cheapest first

1. Say it where the ambiguity is created. The Usage page's unknown payer row already carries a good note. Add the action: "449 calls ($9,584.87 of value) ran on a login stored on your machine, so we cannot tell whether they were billed. Store a claude setup-token under Claude Code, or set the engine's sign-in to API key, and this becomes attributable." Link to the engines panel.
2. Say it where the mode is chosen. EnginesModal — annotate each sign-in mode with what it means for attribution: api-key → "charged spend, visible on Usage"; subscription → "no per-token charge, tokens only"; auto / machine → "attribution unknown unless a token is stored".
3. Make the resolved payer visible in aggregate, not only per session. Show which credential a coding session actually used (subscription vs per-token API key) and what the engine really is #248 shipped engineAuthReport (coding-engines.ts:213-224) so one session's credential is legible on the Coding tab. Nothing rolls that up. A count of sessions by resolved credential, on the Usage page beside the payer breakdown, is what makes "all of them are unattributed" noticeable rather than something you have to click nine sessions to discover.

Alternatives considered and rejected

• Map machine-login to subscription. Rejected, emphatically. usage-payer.ts:70-77 argues it out already: it is the most common resolution, and it may be a plan OR an API key configured inside the CLI. Guessing here is the exact error Triggers: let a cron/webhook trigger run a durable pipeline, not just the 4 canned actions #92 exists to remove, and it would silently zero the charged figure for someone genuinely paying per token.
• Ask Claude Code what it authenticated with. No such field on the stream-json result event. total_cost_usd is computed at list rates for subscribers too (Anthropic's own docs, cited at usage.ts:150-156), so its presence proves nothing.
• Read ~/.claude/.credentials.json on the runner to tell a stored OAuth login from a stored API key. Genuinely more informative than the env probe and would resolve the auto case without any user action — but it means the runner reading a credential file to classify it, which is a materially larger trust step than the presence-only env check engine-auth.ts is careful to stay inside. Open question for the owner; I would ship 1–3 first, since they cost nothing and may make it unnecessary.

Acceptance criteria

• Storing a claude-code key and starting a session produces ai_usage rows with payer = 'subscription'; the Usage page shows a "Drawn from a subscription" bucket.
• The unknown payer row states the cause and the remedy, with the call count and value.
• The engines panel states the attribution consequence of each sign-in mode.
• A test asserts the auto + no-stored-token path yields machine-login → NULL (locking in that this is a disclosed gap, not a silent one).

Regression risk

Storing a setup-token changes real behaviour, not just reporting: resolveEngineEnv will then inject CLAUDE_CODE_OAUTH_TOKEN and strip ANTHROPIC_API_KEY on every auto session. For a machine whose shell exports a working key and whose stored setup-token is stale, that turns a working engine into a failing one. Any prompt to store a token must be paired with the existing engineAuthWarning path, and the docs (platform-docs/coder-multi-machine.md and docs/coding-engines.md) should state the swap.

Verified: the key status, the six code hops, the payer arithmetic, and the credit-balance errors — all from production reads and source. Inferred: that his engine sessions are in fact running on a Claude subscription (from the "session limit" reports); the platform cannot confirm it, which is the whole point of this issue.

Related: #248 (per-session credential display), #346 / migration 0092 (the payer axis), #356 (a drop of this same observation), #485 (which ceiling to enforce), #543, #544.

[serge-ivo]

Line-number corrections to the body — the claims and the quoted code are unchanged, only the citations:

• Step 2, resolveEngineEnv: the block is coding-engines.ts:49 (const token = await getUserProviderKey(env, uid, "claude-code");) and :53 (if (!token) return stripProviderKey;), not :50-56.
• The injection referred to later as :58-61 is :60 — return { CLAUDE_CODE_OAUTH_TOKEN: token, ANTHROPIC_API_KEY: "" };.
• Step 5, payerForEngineAuth is usage-payer.ts:75-80, not :78-82.
• CHARGED_SQL is usage-payer.ts:58, not :62.

engine-auth.ts:63-67, headless.ts:15-25, usage.ts:369 and coding-engines.ts:213-224 are as cited.

[serge-ivo]

Items 1 and 2 shipped in c1cfa2b, deployed (CI + both Deploy workflows green). Leaving this open — item 3 is not done and the first acceptance criterion needs an action only you can take. Detail below.

What shipped

1. The Usage page says it where the ambiguity is created. The unknown payer row now carries the action beneath the existing notes: the call count, the value, what to store, and a link to Profile → API Keys. It renders only for an account that has the gap — a notice everyone sees is a notice everyone learns to skip. Live copy on your account today would read:

Make this attributable. 3,410 calls ($9,585 of value) ran on a login stored on your machine, so we cannot tell whether they were billed. Store a Claude Code sign-in token under Profile → API Keys, or set an engine's sign-in to your API key in the Coder's CLI engines panel, and this becomes attributable. [Go to Profile → API Keys]

2. The engines panel says it where the mode is chosen. Each preset now states what its sign-in mode means for attribution, beside #556's line on whether it is metered at all:

• api-key → Charged spend, visible on Usage — counts towards the charged total
• subscription → No per-token charge — tokens only — draws the plan's allowance, shown as value
• machine → Attribution unknown — plus what to store
• auto → depends, and the modal now reads /v1/keys/status to say which. With a token stored: "Drawn from a subscription". Without: "Attribution unknown — no token saved". A failed lookup leaves it null and the note states both outcomes — "no token saved" is a claim, and a network error is not evidence for it.

The note is null for a non-Claude engine, because no ledger row is written for a raw engine at all: engineMeteringNote already says so one line above, and two notes both saying "you will not see this" is one message too many.

The chain now has a test. workers/api/src/lib/engine-payer-chain.test.ts imports the runner's own mergeEnv and resolveEngineAuth rather than paraphrasing them, and asserts all three outcomes: auto without a token → machine-login → NULL (even on a machine whose shell exports ANTHROPIC_API_KEY, since the mode strips it), auto with a token → subscription, api-key → byok-api. It pins the gap as disclosed, and it is what should fail if anyone "fixes" the unknown bucket by mapping machine-login to subscription — the most common resolution, so the one that would be wrong most often, and the one that would zero the charged figure for someone genuinely paying per token. Your rejection of that alternative is the load-bearing part of this issue and it is now enforced.

What is left

• Acceptance 1 — "storing a claude-code key and starting a session produces payer='subscription'". Not verified end to end: it needs a token stored and a session run, and I do not drive your agents. The chain test covers the code path; the live half is yours. Note the regression risk you flagged is real and unchanged: storing a token makes auto inject CLAUDE_CODE_OAUTH_TOKEN and strip ANTHROPIC_API_KEY on every session, so a stale token turns a working engine into a failing one. engineAuthWarning still reports that per session.
• Item 3 — sessions by resolved credential, in aggregate. Not done, and here is what I found rather than a guess: authResolved is transient. It rides live runner snapshots (routes/coding.ts, workflows/coding-session.ts) and is persisted only as ai_usage.payer — coding_sessions has no column for it. So a session-level roll-up needs a column, not a query. Meanwhile the byPayer breakdown already answers the same question at call and value granularity, and since The Usage page prints $9,566.69 next to "Repo Coder" and $36.35 as "Est. billed" — every breakdown carries only the notional figure, so no agent has a charged cost #543 it carries the charged figure too: live, unknown = 3,410 calls / $9,584.69 of value / $0.00 charged, against byok-api 1,899 calls / $37.99 charged. If a session-count view is still wanted on top of that, it wants its own ticket with the column decision in it.
• No note added to Profile → API Keys. Both surfaces name it, but that list is three fixed controls per provider with no explanatory slot; the right shape is a note on the provider catalog served by /v1/keys/providers, which is a separate change.
• The ~/.claude/.credentials.json question is untouched, as you asked — it is your call, and items 1–3 may make it unnecessary.

Verified: 8,252 unit tests, typecheck, biome, all six scripts, docs:drift, full Playwright suite (384, chromium + webkit), the card read in WebKit at 320px, and the deployed console bundle greps clean for every new string (Make this attributable, Charged spend, visible on Usage, Attribution unknown, no token saved).