Surface Responses output_text logprobs on the text content

[PratikDhanave (PratikDhanave)]

The Responses path built a TextContent from an output_text part (non-streaming responsesProcessResponse, and the streaming output_item.done handler) but never read output_text.logprobs. So a caller that requested logprobs via raw params (Include: ["message.output_text.logprobs"], TopLogprobs) never received them.

The Python client preserves them on the text content's additional_properties["logprobs"] on both parse paths.

Change

• Non-streaming: populate the TextContent AdditionalProperties with the output_text logprobs when present.
• Streaming: the output_item.done handler previously emitted a text content only when annotations were present (the text itself already arrived via deltas); it now also emits when logprobs are present and carries them, mirroring the annotations handling. Key uses the PascalCase convention already used elsewhere in the provider.

Test

• TestResponsesOutputTextLogprobsSurfaced_NonStreaming: a canned response whose output_text carries a logprobs array now surfaces Logprobs on the TextContent AdditionalProperties. Fails before the change (nil), passes after.

[Copilot]

🟡 Changes recommended

Streaming logprobs can be lost during response collection, and the new streaming path lacks regression coverage.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates Responses API handling to expose output_text logprobs for non-streaming and streaming responses.

Changes:

• Propagates logprobs to TextContent.AdditionalProperties.
• Emits streaming metadata for logprobs.
• Adds non-streaming regression coverage.

File summaries

File	Summary
provider/openaiprovider/responses.go	Propagates output text logprobs.
provider/openaiprovider/responses_test.go	Tests non-streaming logprobs exposure.

Review details

Suppressed comments (1)

provider/openaiprovider/responses.go:1602

• When logprobs are present without annotations, this creates an empty TextContent immediately after the delta text. ResponseStream.Collect() then coalesces adjacent text contents and copies AdditionalProperties only from the first item (message/content.go:1175-1179), so the returned collected response loses these logprobs. Preserve the metadata through coalescing (for example, merge the content metadata) or otherwise make the logprobs update survive Collect(); add a streaming regression test for the logprobs-only case.

						populateAnnotations(outputText.Annotations, annotatedContent)
						if len(outputText.Logprobs) > 0 {
							annotatedContent.AdditionalProperties = map[string]any{"Logprobs": outputText.Logprobs}

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Scope: user-visible behavior (bug fix), internal-only implementation
Changed Go contract: No new exported types/functions/fields. responsesProcessResponse and the streaming output_item.done handler in provider/openaiprovider/responses.go now populate the existing message.TextContent.AdditionalProperties["Logprobs"] map entry when the Responses API output_text.logprobs field is present. Previously this data was silently dropped on both the non-streaming and streaming parse paths.
Upstream evidence reviewed:

• python/packages/openai/agent_framework_openai/_chat_client.py — _get_metadata_from_response (~L3933) sets additional_properties={"logprobs": ...} for non-streaming output, and output_text_properties() (~L3311) plus its callers in _parse_chunk_from_openai (response.content_part.added / response.output_text.delta, ~L3376/~L3400) do the same for streaming — confirming the Python client preserves output_text.logprobs on the text content's additional_properties, matching the intent of this Go fix.
• No equivalent Logprobs-specific handling found in dotnet/src/Microsoft.Agents.AI.OpenAI (the .NET OpenAI provider); the only .NET Logprobs references are in Microsoft.Agents.AI.Hosting.OpenAI (server-side hosting/serialization, not the client parse path), so no direct .NET parity signal either way.
  Result: aligned. This restores parity with the Python client's existing additional_properties["logprobs"] behavior; it is a bug fix (previously-silent data loss) rather than a new capability, so no Go-only feature is being introduced ahead of upstream. The key casing ("Logprobs" PascalCase) follows the existing convention in this file (e.g. "EndUserId", "SafetyIdentifier", "ContainerId"), consistent with how other provider-specific extras are surfaced. No exported Go API surface changed (only internal population of an existing map[string]any field), and the two added tests pass. No public-api-change label needed.

Generated by Go API Consistency Review Agent · copilot · auto · 67.4 AIC · ⌖ 7 AIC · ⊞ 9.2K · ◷