LiteLLM chat->Responses->chat bridge turns string user content into text blocks, breaking Databricks json_object

Finding: In a reporter's LiteLLM v1.100.0 setup, Databricks models served through the chat -> Responses -> chat bridge (model_info.mode set to responses, or a Databricks model name without gpt, per the reporter) reportedly get plain-string user content rewritten as a list of text blocks. With response_format json_object, Databricks then returns a 400 saying the messages must contain the word json, even when the prompt contains JSON. Source: https://github.com/BerriAI/litellm/issues/45618. This is an external report; KFA did not reproduce it. Reported evidence: the reporter says direct calls to the Databricks AI Gateway for system.ai.deepseek-v4-1-flash succeed (200) with string content but fail (400) with a single text-block list, and also fail when the system message is a string and the user content is blocks. They also supply a stock-litellm pytest using a local HTTP server that records the outgoing body: the direct path keeps the string, while the responses-mode path emits a list of text blocks. This is reporter-supplied synthetic evidence, not independent confirmation. Source: https://github.com/BerriAI/litellm/issues/45618. Reported cause (not maintainer-confirmed): the chat->responses leg converts string content to input_text, and the responses->chat leg always emits a list of text blocks without collapsing a single block back to a string. The response_format value is reportedly forwarded unchanged, so only the content shape differs. Source: https://github.com/BerriAI/litellm/issues/45618. Diagnostic cue: if the error appears for a Databricks model on the bridged path while the prompt clearly contains JSON, inspect the outgoing message content shape; list-form content where a string was sent would match this report. Whether other Databricks models or versions are affected is unknown. Mitigation and fix status: the reporter suggests either collapsing a lone text block to a string (when no non-text parts or cache_control exist) or using the native Databricks /responses endpoint for all Databricks models. A commenter (association NONE) said they would take the work and then stated a fix is up as PR #45713. Review, merge and release status are not shown, and the PR was not inspected, so no fix is confirmed or shipped. Sources: https://github.com/BerriAI/litellm/issues/45618#issuecomment-6091679672 and https://github.com/BerriAI/litellm/issues/45618#issuecomment-6092192417. Limitations: mock-server repro, partial comment coverage, single reported version.