fix: strip image parts for non-vision models with provider profiles#26498
Closed
hueilau wants to merge 1 commit into
Closed
fix: strip image parts for non-vision models with provider profiles#26498hueilau wants to merge 1 commit into
hueilau wants to merge 1 commit into
Conversation
_propare_messages_for_non_vision_model() was only called in the legacy flag path (no provider profile). Providers with registered profiles (e.g. DeepSeek, Kimi) bypassed the strip, causing HTTP 400 errors when image_url content blocks reached their non-vision APIs. This mirrors the existing behavior in the legacy path, ensuring all non-vision models get image stripping regardless of profile status. Vision-capable models are unaffected (the function is a no-op for them).
Collaborator
374b5c3 to
855aee1
Compare
teknium1
added a commit
that referenced
this pull request
May 17, 2026
…tors Adds release-note attribution mappings for 9 contributors from group 3: - @darvsum (PR #26766) - @hueilau (PR #26498) - @Timur00Kh (PR #27114) - @Grogger (PR #27061) - @lemassykoi (PR #27042) - @draplater (PR #26707) - @pr7426 (PR #27048) - @therahul-yo (PR #26215) - @flamiinngo (PR #27205) #27154 dropped from this batch — already landed on main as 4e9cedc.
Contributor
|
Merged via PR #27302 — your commit was cherry-picked onto current |
gweeteve
pushed a commit
to gweeteve/hermes-agent
that referenced
this pull request
Jun 2, 2026
…tors Adds release-note attribution mappings for 9 contributors from group 3: - @darvsum (PR NousResearch#26766) - @hueilau (PR NousResearch#26498) - @Timur00Kh (PR NousResearch#27114) - @Grogger (PR NousResearch#27061) - @lemassykoi (PR NousResearch#27042) - @draplater (PR NousResearch#26707) - @pr7426 (PR NousResearch#27048) - @therahul-yo (PR NousResearch#26215) - @flamiinngo (PR NousResearch#27205) NousResearch#27154 dropped from this batch — already landed on main as 4e9cedc.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When using non-vision models like DeepSeek v4-pro with the native provider,
image_urlcontent blocks from tools likebrowser_vision,computer_usescreenshots, or/pastecause HTTP 400 errors:The image blocks persist in conversation history, making the session unusable.
Root Cause
In
run_agent.py's_build_api_kwargs(),_prepare_messages_for_non_vision_model()is only called in the legacy flag path (line 9715), which is reached whenget_provider_profile()returnsNone— i.e., unknown/unregistered providers.Registered providers with profiles (DeepSeek, Kimi, MiniMax, etc.) take the provider profile path (line 9680-9705), which passes
api_messagesdirectly to_ct.build_kwargs()without stripping images.Fix
Add the same
_prepare_messages_for_non_vision_model()call to the provider profile path, mirroring the legacy path behavior. Vision-capable models are unaffected (the function is a no-op for them).Verification
Related
_prepare_messages_for_non_vision_model