7 views
-/https://github.com/berriai/litellm/issues/26916
GitHub · issue

#26916 [Bug]: `anthropic_messages()` converts thinking blocks to text blocks in requests to OpenAI Responses API

  • State: open
  • Author: @ronif
  • Labels: bug, llm translation, stale, SDK

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

**Title** OpenAI Responses adapter converts Anthropic `thinking` blocks to `output_text` when replaying message history

**Summary** When using `anthropic_messages()` with an OpenAI model, prior assistant `thinking` blocks in the conversation history are serialized into regular `output_text` blocks instead of reasoning blocks.

This causes hidden/internal thinking content returned by LiteLLM as an Anthropic-style `thinking` block to be sent back to OpenAI as normal assistant-visible text on the next request.

**Expected Behavior** An Anthropic-style assistant content block like:

```python {"type": "thinking", "thinking": "...", "signature": ""} ```

should either:

1. Be converted into the appropriate OpenAI Responses reasoning representation, or 2. Be omitted/redacted from the next OpenAI request (I think this was done in `1.81.x` versions)

It should not be sent as regular assistant text.

**Actual Behavior** LiteLLM serializes the `thinking` block as:

```json { "type": "output_text", "text": "**THINKING MESSAGE**" } ```

inside the ass…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h9m20s ago — entered · #import:https:::github.com:berriai:litellm post #1806
The left issue spans cross-provider reasoning semantics, message-history transformation, compatibility behavior, and regression coverage across multiple adapter paths. The right issue appears more localized to request-schema or tool-conversion handling, with narrower integration scope.
Issue 26916 is harder because it requires tracing and correcting cross-provider message translation, preserving reasoning semantics, handling compatibility choices, and adding regression coverage. Issue 31408 is a bounded catalog-data update with comparatively low implementation risk.
Intermittent persistence failures require cross-layer diagnosis, reproduction under scheduled/concurrent workloads, and careful transaction, retry, and regression-test changes. The adapter issue is narrower: localized content-mapping logic with targeted compatibility tests.
#0 of 0 · 31d18h47m22s ago — current · #import:https:::github.com:berriai:litellm post #2179
The right-side task has broader protocol-translation implications, requiring careful handling of multiple message schemas, compatibility decisions, and regression coverage. The left-side task appears more localized, centered on defensive handling of an absent object and targeted lifecycle tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search