Map pi-ai's reasoning usage into reasoningTokens

[Pummelchen]

What happens now. pi-ai parses the provider's split (@earendil-works/pi-ai/dist/api/openai-completions.js:1201):

reasoning: rawUsage.completion_tokens_details?.reasoning_tokens || 0,

@deepseek-ai/dsh-llm-pi-ai's mapUsage (lib/index.js:1403-1410) then maps input, output, totalTokens, cacheRead and cacheWrite — and drops reasoning:

function mapUsage(usage) {
	return {
		inputTokens: usage.input,
		outputTokens: usage.output,
		totalTokens: usage.totalTokens,
		...usage.cacheRead > 0 ? { cacheReadTokens: usage.cacheRead } : {},
		...usage.cacheWrite > 0 ? { cacheWriteTokens: usage.cacheWrite } : {}
	};
}

Consequence. The harness's TokenUsage.reasoningTokens is populated on the DeepSeek route (visible in a session transcript as {"inputTokens": 9707, "outputTokens": 153, "totalTokens": 11140, "cacheReadTokens": 1280, "reasoningTokens": 132}) and never on a pi-ai route, so the context meter and any per-turn accounting cannot separate thinking from answer there — exactly where local models spend most of their output tokens. The server does report the field; the adapter discards it. The doc comment ("reasoning folded into output by pi-ai") describes pi-ai's output bucket, not the separate count pi-ai also returns.

Suggested patch (one line, mirroring the cache fields' "only when non-zero" rule):

...usage.reasoning > 0 ? { reasoningTokens: usage.reasoning } : {},

Acceptance. On a pi-ai route, a thinking turn's assistant/message record carries reasoningTokens matching the provider's completion_tokens_details.reasoning_tokens; a non-thinking turn omits it, as the cache fields do.

(Re-verified against @deepseek-ai/dsh 0.1.6-alpha.2 and @earendil-works/pi-ai 0.85.1; the line numbers above are those versions'.)

[argszero]

Verified against 0.1.6-alpha.2 sources plus pi-ai 0.85.1's published declarations: the defect is real, and the fix is one field — with two adjustments to the snippet, one of which is that it does not compile as written.

Confirmed. mapUsage (packages/llm/llm-pi-ai/src/stream.ts:24-33) maps five fields and drops reasoning, and pi-ai really does carry the count separately: Usage.reasoning?: number is documented as "a subset of output: output already includes these tokens … left undefined by providers that don't" (@earendil-works/pi-ai/dist/types.d.ts:272-277). So the doc comment you quote ("reasoning folded into output by pi-ai") describes the output bucket, not the separate count — your reading of it is right, and the fix is one mapped field rather than a comment change.

Adjustment 1 — the snippet needs an undefined guard. cacheRead and cacheWrite are non-optional number in pi-ai's Usage, which is why the sibling lines compare a bare value; reasoning is optional, so usage.reasoning > 0 is a strict-null error. It has to be:

...usage.reasoning !== undefined && usage.reasoning > 0 ? { reasoningTokens: usage.reasoning } : {},

Adjustment 2 — keep > 0, but not as a copy of the cache fields' rule. @deepseek-ai/dsh-llm-deepseek's mapUsage uses reasoning !== undefined (protocols/chat-completions/translate.ts:70) and so preserves a reported 0; transposing that predicate here would emit reasoningTokens: 0 on every pi-ai turn. pi-ai's own mappers collapse absence into zero before the harness ever sees it — reasoning: rawUsage.completion_tokens_details?.reasoning_tokens || 0 in openai-completions.js:1201, and the same shape in openai-responses-shared.js:449, google-generative-ai.js:171, google-vertex.js:180 — which is precisely the "pi-ai reports zeros, not absence" property mapUsage's own comment already states for the cache fields. > 0 is therefore what makes your acceptance criterion ("a non-thinking turn omits it") hold, while the !== undefined half is still required: pi-messages builds usage through createEmptyUsage(), which has no reasoning key at all, so the field is genuinely optional at runtime too.

One boundary worth putting in the record. On the completions / responses / google paths, "the provider reports no breakdown" and "the provider reports zero" both surface as 0, so the mapped field cannot separate them: it reports thinking tokens where thinking was counted and stays absent otherwise. That is the most the harness vocabulary can express without growing a second tri-state field.

Mountability: none, and I checked before assuming. The value is discarded inside the adapter, before any chunk exists. The only two surfaces a plugin can see are the mapped TokenUsage on the usage chunk and the terminal finish chunk's ReplayEnvelope — and toPiReplayState (llm-pi-ai/src/replay.ts:77-111) enumerates its response fields (kind, version, api, provider, model, responseModel, responseId, providerThinkingLevel, stopReason) plus per-block signatures, carrying no usage and no cost. A plugin could only invent a count, which per-turn accounting should not accept as provider-reported. So this belongs in the adapter: the one-field mapping above, a non-thinking case and a reporting-provider case in llm-pi-ai's own tests.

[Pummelchen]

Confirmed against 0.1.6-alpha.2 — mapUsage drops reasoning, and pi-ai carries the count separately (Usage.reasoning?: number). Our record is corrected.

The snippet now reads:

...usage.reasoning !== undefined && usage.reasoning > 0
  ? { reasoningTokens: usage.reasoning } : {},

The strict-null half is a compile error we would have hit immediately. The half I had wrong is the predicate: copying dsh-llm-deepseek's reasoning !== undefined would emit reasoningTokens: 0 on every pi-ai turn, because pi-ai's own mappers collapse absence into 0 on all four paths. !== undefined && > 0 is what makes a non-thinking turn omit the field while a reported 0 also omits it.

Recorded with the ask: the boundary that a no-breakdown provider and a zero-reporting one are indistinguishable on completions/responses/google without a tri-state field, and the mountability finding — the value is gone before any chunk exists and toPiReplayState carries no usage or cost, so this is adapter-only. Acceptance now names your two cases: a non-thinking turn, and a provider that reports a count.

Thank you for checking mountability rather than assuming it; that is the part that decides where the fix has to land.