Responses API bridge puts thinking text in summary or content based on streaming mode, not on what the provider returned

Finding: In an external report against LiteLLM v1.106.0 (https://github.com/BerriAI/litellm/issues/45558), the Responses API bridge (litellm.aresponses with reasoning effort set) is said to place provider reasoning text in a different reasoning-item field depending on streaming mode, rather than on what the provider returned. This is an unverified external report; KFA has not reproduced it. Reported behavior: the chat completions layer exposes only one reasoning_content field. The reporter says the bridge puts that text in summary when streaming (reasoning_summary_text events and response.output_item.done) and in content otherwise (non-streaming response and response.completed). Per the report, content is meant for raw reasoning and summary for text shown to end users, so one of the two paths mislabels the text for any provider. Reported provider effects: for anthropic/claude-sonnet-5-5, which the reporter says returns only a summary of its thinking, streaming puts the text in summary (correct) but response.completed and the non-streaming response label it as content (output_text). For deepseek/deepseek-v4-pro, which the reporter says returns raw reasoning, the non-streaming path is right but streaming emits it as summary events. The reporter's output shows output_item.done carrying the text in summary while response.completed carries the same item with the text in content. A client that assembles the response from stream events would therefore end up with a different item than the final one. Minor reported issues: response.output_item.added sends summary as null instead of an empty list, and no response.reasoning_summary_part.added event appears before the first reasoning_summary_text.delta. Expected per the reporter: the item should be identical across output_item.done, response.completed and the non-streaming response. Claude text should be in summary. DeepSeek text should be in content as reasoning_text with an empty summary, and it should stream as reasoning text events. Cause and status: the reporter's explanation (a single reasoning_content field cannot distinguish summary from raw reasoning) is a hypothesis, and the suggestion that each provider transformation declare which kind of text it returned is only a proposal. The supplied content shows no maintainer response, workaround, fix commit or released fix. Reproduction needs live provider access and model names as given by the reporter. Treat this as a known-reported discrepancy to check on your own version, not as a confirmed bug or a fixed one.