[bot] OpenAI-compatible chat completions streaming drops `reasoning_content` (affects DeepSeek and other providers using the plain OpenAI SDK)

[braintrust-bot]

Summary

The shared streaming aggregation function used by the plain OpenAI plugin (aggregateChatCompletionChunks in js/src/instrumentation/plugins/openai-plugin.ts) does not capture reasoning/reasoning_content/reasoning_details fields from chat-completions streaming deltas. This function is the base implementation used directly by the OpenAI chat.completions.create channel — the exact code path exercised whenever a user points the vanilla openai npm package at a custom baseURL, which is DeepSeek's own documented integration method (and a common pattern for other OpenAI-compatible inference providers/self-hosted reasoning models). Reasoning content emitted during streaming by these providers is silently dropped from spans.

This is the same class of bug already found and fixed three times in sibling/downstream plugins — Mistral (#1857, fixed), OpenRouter (#1883, fixed), and Groq (#1911, fixed) — but in each of those fixes, the shared base function itself was left untouched, so the gap persists for any consumer that reaches it directly (i.e. the plain OpenAI SDK against a third-party OpenAI-compatible endpoint).

What instrumentation is missing

Streaming aggregation never reads reasoning fields

In js/src/instrumentation/plugins/openai-plugin.ts:

• AggregatedChatChoice (lines 408–420) has fields for role, content, refusal, audio, toolCallsByIndex, logprobs, and finish_reason — no field for reasoning content.
• aggregateChatCompletionChunks (lines 459 onward) reads delta.finish_reason, delta.role, delta.content, delta.refusal, and delta.audio (lines 505–534+) — there is no branch reading delta.reasoning or delta.reasoning_content.
• toChatChoice (lines 435–452) builds the final aggregated message from role, content, refusal, audio, tool_calls only.

A repo-wide check confirms this: js/src/instrumentation/plugins/openai-plugin.ts has zero occurrences of "reasoning" (case-insensitive). By contrast, js/src/instrumentation/plugins/groq-plugin.ts (lines 680–720) wraps this exact shared function with an additional aggregateGroqReasoning post-processing step specifically because the shared function doesn't handle it — direct proof the underlying gap was deliberately routed around for Groq's fix rather than fixed at the source, leaving it open for every other consumer of the shared function.

Vendor types have no typed reasoning field either

js/src/vendor-sdk-types/openai-common.ts, OpenAIChatDelta (lines 135–143):

interface OpenAIChatDelta {
  role?: string;
  content?: string;
  refusal?: string;
  audio?: OpenAIChatAudio | null;
  tool_calls?: OpenAIChatToolCallDelta[];
  finish_reason?: string | null;
  [key: string]: unknown;
}

The [key: string]: unknown index signature means the runtime value is present on delta when a provider sends it, but the aggregation code never reads it.

Non-streaming path is unaffected

The non-streaming chatCompletionsCreate handler (openai-plugin.ts lines 89–109) uses extractOutput: (result) => result?.choices, a full passthrough — so message.reasoning_content survives for non-streaming calls. The gap is specific to streaming aggregation.

Upstream API format

DeepSeek's chat completions API (OpenAI-compatible, accessed via the plain openai SDK with a custom baseURL per DeepSeek's own quickstart) returns chain-of-thought content in thinking-enabled models via a reasoning_content field at the same level as content. In streaming responses this is delta.reasoning_content, a nullable string emitted incrementally in chat.completion.chunk objects, analogous to how delta.content streams the final answer.

• DeepSeek API reference: https://api-docs.deepseek.com/api/create-chat-completion
• DeepSeek Thinking Mode guide: https://api-docs.deepseek.com/guides/thinking_mode/

This same non-standard reasoning/reasoning_content/reasoning_details extension pattern is also what OpenRouter (#1883) and Groq (#1911) needed dedicated fixes for — it is a broadly used convention among OpenAI-compatible providers, not unique to one vendor.

Comparison with other providers in this repo

Provider	Reasoning content captured in streaming
Anthropic	thinking_delta aggregated
Google GenAI	thought parts handled
AI SDK	reasoning-delta chunks aggregated
Cohere	thinking content blocks aggregated
Mistral	thinking chunks aggregated — fixed in #1857
OpenRouter	reasoning/reasoning_content/reasoning_details aggregated — fixed in #1883
Groq	reasoning aggregated via dedicated wrapper — fixed in #1911
OpenAI base plugin (chat.completions.create)	Silently dropped — this issue

Braintrust docs status

not_found — checked https://www.braintrust.dev/docs/integrations/ai-providers/openai. The page documents metrics like completion_reasoning_tokens (a token count) and covers pointing the OpenAI client at a custom API base URL/endpoint path, but does not mention reasoning_content capture or DeepSeek/OpenAI-compatible reasoning-content streaming at all.

Local files inspected

• js/src/instrumentation/plugins/openai-plugin.ts (lines 89–109: non-streaming passthrough is fine; lines 408–452: AggregatedChatChoice/toChatChoice have no reasoning field; lines 459–534+: aggregateChatCompletionChunks never reads delta.reasoning/delta.reasoning_content)
• js/src/instrumentation/plugins/openai-channels.ts (chatCompletionsCreate channel definition)
• js/src/vendor-sdk-types/openai-common.ts (lines 135–143: OpenAIChatDelta has no typed reasoning field)
• js/src/instrumentation/plugins/groq-plugin.ts (lines 680–720: proof pattern — Groq wraps the shared function with its own aggregateGroqReasoning rather than the shared function being fixed)
• js/src/instrumentation/plugins/openrouter-plugin.ts (confirmed sibling plugin's own separate aggregateOpenRouterChatChunks has equivalent handling, unrelated to the shared OpenAI function)

[mstevens843]

I reproduced the streamed reasoning_content loss and have a local, unpublished patch that preserves fragments independently per choice. All 87 focused tests pass; the same tests on the unmodified base fail 10 reasoning assertions.

The patch covers reasoning_content only, leaving reasoning and reasoning_details unchanged. The new tests use constructed responses, so genuine-provider E2E coverage remains outstanding.

Before I prepare a PR, is anyone already working on this internally, and is there an existing genuine provider recording containing reasoning_content that I could use for the required coverage?