llm-pi-ai drops completion_tokens_details.reasoning_tokens, so TokenUsage.reasoningTokens is never filled

[xvcezrqpbxtpzblrt]

What happens

When the provider reports how much of a reply was thinking, the Harness's assistant-stream usage frame does not carry it. TokenUsage has a reasoningTokens? field, but it is never filled, so a client can only estimate the thinking tokens instead of showing the engine's count.

Environment

• @deepseek-ai/dsh 0.2.1-alpha.3 (the copy bundled by Strata 0.2.7)
• Windows 11 x64, Node 24
• Provider: a local OpenAI-compatible server (Strata engine), openai-chat protocol, streaming with stream_options.include_usage

Evidence

The provider's final usage chunk (streamed; the non-streamed reply has the same field):

{"prompt_tokens":54,"completion_tokens":24,"total_tokens":78,
 "completion_tokens_details":{"reasoning_tokens":19}}

@deepseek-ai/dsh-llm-pi-ai/lib/index.js, mapUsage():

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 } : {}
  };
}

The pi-ai OpenAI-completions parser sets usage.reasoning from rawUsage.completion_tokens_details?.reasoning_tokens; mapUsage drops it.

What I tried

I added ...(usage.reasoning > 0 ? { reasoningTokens: usage.reasoning } : {}) to that function in the bundled copy, reinstalled, and the usage frame the client receives still had no reasoningTokens. So either that function is not the one that produces the frame for this route, or a later projection drops it. TokenUsageProjection in the published types has only uncachedInputTokens, outputTokens, cacheReadTokens, cacheWriteTokens; if the assistant stream uses that projection, the field is lost there. Please check both layers.

Expected

When the provider reports completion_tokens_details.reasoning_tokens, the assistant-stream usage frame carries the number (for example reasoningTokens), so clients can show the model's own count. When it is absent, the field stays absent.

Impact

A client cannot show the exact thinking token count; it can only estimate from the reasoning text and mark the number as approximate.

Reproduction

Any OpenAI-compatible server that returns the field; a local one works. Open a session, send one prompt, and read the usage chunk the assistant stream delivers: the provider sent completion_tokens_details.reasoning_tokens, the chunk has no reasoning count.

Limits

• I did not run this against a hosted OpenAI or Anthropic provider, only the local OpenAI-compatible one.
• No credentials, logs or personal data are included.

[zhangdw156]

Confirmed on the current upstream master, ce7073d51254c26cd63b22a60835b8f948deb447 (0.2.2-alpha.2, pi-ai 1.3.0). The source mapUsage() still drops usage.reasoning.

I prepared a tested fix in my fork: zhangdw156#1. Upstream Issues and pull requests are disabled, so I am sharing it here following CONTRIBUTING.md.

The fix also incorporates the zero-value distinction discussed in #10840:

...usage.reasoning === undefined ? {} : { reasoningTokens: usage.reasoning },

This preserves both positive counts and an explicit 0, leaves the field absent when pi-ai supplies no count, and does not add reasoning to outputTokens or totalTokens again. It applies to both done and error events.

I reproduced the loss through the actual Loader-mounted adapter, pi-ai Anthropic SSE parser, ctx.llm.stream() and BlockAssembler, with only the HTTP provider replaced by a local test server. An SSE message_delta with output_tokens: 10 and output_tokens_details.thinking_tokens: 6 produced { inputTokens: 3, outputTokens: 10, totalTokens: 13 } before the fix and additionally reasoningTokens: 6 afterward. Separate cases cover zero and an omitted breakdown.

Local validation: 452 adapter-package tests passed, with 100% statement/branch/function/line coverage of stream.ts; artifact builds, final Host/Client aggregate type checks, lint and documentation checks completed. Six regression cases failed before the fix. No hosted model calls were used.

This establishes the adapter-to-stream fix; it does not claim to resolve or verify the separate ACP/statistics projections mentioned above. It also preserves pi-ai's existing protocol-specific normalization: for example, its Chat Completions parser currently supplies reasoning: 0 when the raw breakdown is absent.