mapUsage(): use === undefined, not > 0, for reasoningTokens (follow-up to #7110)

[shenbo7]

Follow-up to #3825 and #7110 — same defect, one new detail.

I filed this before searching, so it duplicates the two existing reports. Reporting it again would only add noise, so here is the only part that is not already on record.

The snippet in #7110 is unsafe

#7110 suggests:

diff

-		...usage.cacheWrite > 0 ? { cacheWriteTokens: usage.cacheWrite } : {}
+		...usage.cacheWrite > 0 ? { cacheWriteTokens: usage.cacheWrite } : {},
+		...usage.reasoning > 0 ? { reasoningTokens: usage.reasoning } : {}
 	};

@earendil-works/pi-ai 1.3.0, dist/types.d.ts:279-292, documents the field's presence as the signal:

Reasoning/thinking tokens, when the provider reports them. This is a subset of output … Set to a number (possibly 0) by providers that expose a reasoning breakdown; left undefined by providers that don't.

So 0 and undefined mean different things — "provider reported zero reasoning tokens" vs "provider does not report a breakdown at all" — and usage.reasoning > 0 collapses them, discarding the legitimate 0 case. The cache fields above use > 0 only because they are number (never undefined); reasoning is reasoning?: number, so the guard has to be an existence test:

diff

-		...usage.cacheWrite > 0 ? { cacheWriteTokens: usage.cacheWrite } : {}
+		...usage.cacheWrite > 0 ? { cacheWriteTokens: usage.cacheWrite } : {},
+		...usage.reasoning === undefined ? {} : { reasoningTokens: usage.reasoning }
 	};

outputTokens must stay usage.output: pi-ai's own openai-completions.js already carries completion_tokens into output inclusive of reasoning tokens, so adding reasoning there would double-count it. The nested conditional is intentional — spreading {} keeps the field absent rather than emitting reasoningTokens: undefined.

One data point on the effect

Privately patched into the packaged app.asar (DSH Desktop 0.2.1-rc.2, Windows, alibaba-cn / deepseek-v4.1-flash-1017), same session rebuilt after a restart:

  | usage records | records carrying reasoningTokens -- | -- | -- before | 219 | 0 after | 171 | 41 (values 1516, 1516, 224, 224, 385, 385 …)

That is enough for me to confirm the one-line fix resolves it end to end, from the adapter through Ledger.account() into days[].reasoning.

Please treat this as a duplicate

Closing it in favour of #7110 (with the >= 0 / === undefined correction above folded in) is the right outcome. I am not asking for a second fix — #3825 already has the diagnosis and #7110 already has a proposed patch; the only actionable delta is the guard.