Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug]: LiteLLM adapter flattens single-image tool_result to string instead of image_url object when using Bedrock Converse [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#24968•Fetched 2026-04-08 02:25:19
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
SriramB2002SriramB2002
Participants
SriramB2002SriramB2002
Timeline (top)
labeled ×3cross-referenced ×1referenced ×1

Root Cause

Root cause: The single-item and multi-item code paths in transformation.py:470-529 handle images differently. The multi-item path correctly wraps images in ChatCompletionImageObject inside a list, but the single-item path assigns the data URI string directly to content.

PR fix notes

PR #24978: fix: wrap single-image tool_result in image_url object for Bedrock Converse

Description (problem / solution / changelog)

Fixes #24968

Problem

When a tool result contains a single image, the Bedrock Converse adapter assigns the raw data URI string directly to content instead of wrapping it in a ChatCompletionImageObject. The multi-image code path correctly wraps images. This causes downstream failures when the content field is expected to be a structured object.

Solution

Align the single-item image path with the multi-item path by wrapping the image URL in ChatCompletionImageObject(type="image_url", image_url=ChatCompletionImageUrlObject(url=...)) instead of assigning the raw string.

Testing

Verified the fix matches the existing multi-item pattern at lines 521-529 of the same file.

Changed files

  • litellm/llms/anthropic/experimental_pass_through/adapters/transformation.py (modified, +19/-12)
  • tests/test_litellm/llms/anthropic/experimental_pass_through/adapters/test_anthropic_experimental_pass_through_adapters_transformation.py (modified, +13/-7)
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

In translate_anthropic_messages_to_openai (which bedrock converse models use), when a tool_result content list contains a single type: "image" block, the adapter converts it to a plain data URI string (content="data:image/jpeg;base64,...") instead of a list containing a ChatCompletionImageObject. This causes downstream providers that inspect content type (e.g. Bedrock Converse) to treat the image as text.

Impact: Any agentic flow using /v1/messages → bedrock/converse/* where a tool returns a single image will silently lose the image data. The model hallucinates a response based on context/filename instead of seeing the image.

Root cause: The single-item and multi-item code paths in transformation.py:470-529 handle images differently. The multi-item path correctly wraps images in ChatCompletionImageObject inside a list, but the single-item path assigns the data URI string directly to content.

As a temporary fix, we're adding a sentinel empty text block along with the image so that the multi-item code path is executed, but this is ideally fixed within the code within LiteLLM.

Steps to Reproduce

  1. Send a /v1/messages request with a tool_result containing a single type: "image" content block
  2. Route to a bedrock/converse/* model
  3. Observe that the model receives a text block with the base64 data URI instead of an image

Relevant log output

What part of LiteLLM is this about?

SDK (litellm Python package)

What LiteLLM version are you on ?

v1.82.3-stable

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Modify the translate_anthropic_messages_to_openai function in transformation.py to consistently handle single and multi-item image content lists.

Guidance

  • Review the code paths in transformation.py:470-529 to identify the discrepancy in handling single-item and multi-item image content lists.
  • Update the single-item code path to wrap images in ChatCompletionImageObject inside a list, similar to the multi-item code path.
  • Test the updated function with a tool_result containing a single type: "image" content block to verify that the image is correctly passed to downstream providers.
  • Consider removing the temporary fix that adds a sentinel empty text block, once the updated function is in place.

Example

No code example is provided, as the issue does not include the relevant code snippet from transformation.py.

Notes

The provided information suggests that the issue is specific to the LiteLLM Python package (SDK) version v1.82.3-stable. The fix may not apply to other versions or components of LiteLLM.

Recommendation

Apply workaround: Update the translate_anthropic_messages_to_openai function to consistently handle single and multi-item image content lists, as this is a more targeted solution than upgrading to a potentially unavailable fixed version.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING