Repository navigation
fix: Xiaomi MiMo vision_analyze uses wrong path — images degraded to text #49388
Description
Bug Description
vision_analyze on Xiaomi MiMo (mimo-v2.5) returns incorrect/meaningless analysis results because images are silently degraded to text summaries instead of being sent to the auxiliary vision model.
Root Cause
The bug involves two related issues in tools/vision_tools.py:
1. _should_use_native_vision_fast_path() conflated two independent capabilities
The function returned True for Xiaomi because _lookup_supports_vision() was True (Xiaomi profile has supports_vision=True). But supports_vision means the model accepts images in user messages, not in tool-result messages.
The condition was:
return (
_supports_media_in_tool_results(provider, model)
or _lookup_supports_vision(provider, model, cfg) is True
)The or _lookup_supports_vision(...) clause bypassed the supports_media_in_tool_results check, enabling the native fast path for providers that support vision in user messages but reject list-type tool content.
2. _supports_media_in_tool_results() profile fallback ignored supports_vision_tool_messages
The profile fallback only checked profile.supports_vision:
if profile is not None and profile.supports_vision:
return TrueFor Xiaomi, supports_vision=True but supports_vision_tool_messages=False. The fallback returned True despite the profile explicitly declaring tool-message incompatibility.
What Happens at Runtime
_should_use_native_vision_fast_path()returnsTruefor Xiaomi_vision_analyze_native()returns a_multimodalenvelope (image in tool result)- Agent loop
_tool_result_content_for_active_model()detects Xiaomi cannot handle list-type tool content, then downgrades to text summary - Model only sees text description, not pixels -> wrong analysis results
Fix
_supports_media_in_tool_results(): In the profile fallback, also checksupports_vision_tool_messages-- ifFalse, returnFalse_should_use_native_vision_fast_path(): Removeor _lookup_supports_vision(...)-- only enable fast path when_supports_media_in_tool_results()isTrue- For Xiaomi,
vision_analyzenow correctly falls through to the aux-LLM path (images sent in user messages, where Xiaomi supports them)
Provider Profile
The Xiaomi profile is correctly configured:
supports_vision=True, # accepts images in user messages
supports_vision_tool_messages=False, # rejects list-type tool content (400 "text is not set")The issue was that the code did not respect supports_vision_tool_messages in the relevant decision points.
Testing
All existing tests pass:
tests/tools/test_vision_native_fast_path.py: 22 passedtests/run_agent/test_vision_tool_messages.py: 17 passed
Added new test test_xiaomi_falls_through_to_aux to verify Xiaomi routes to aux-LLM path.
Impact
- Affects: Xiaomi MiMo provider (
mimo-v2.5) - Other providers (Anthropic, OpenAI, OpenRouter, Gemini 3) are unaffected
- The fix ensures Xiaomi vision analysis works via the aux-LLM path (images in user messages) instead of the broken native fast path
Activity
alt-glitch commentedon Jun 20, 2026
Duplicate of #39685 — same root cause and code path. The native vision fast path in
tools/vision_tools.pyroutes images through tool-result messages for Xiaomi MiMo despite the profile declaringsupports_vision_tool_messages=False, so the image is degraded to a text summary (or rejected with a 400 "text is not set"). The fix you describe (gate_supports_media_in_tool_results()onsupports_vision_tool_messagesand change the_should_use_native_vision_fast_path()orclause toand) is exactly the one tracked by the open fix PRs #39692, #45571, and #47747. Confirmed still live onmain(theor _lookup_supports_vision(...)clause is present attools/vision_tools.py:626). Consolidating under #39685.Nandoca95 commentedon Jul 26, 2026
Current reproduction:
opencode-go/mimo-v2.5afterbrowser_visionI am adding current evidence to this existing issue rather than opening a duplicate.
Environment
maincommit:fe3dd9106a1c9d2327fb3795e55b09742c43bafdopencode-gomimo-v2.5https://opencode.ai/zen/go/v1--provider opencode-go -m mimo-v2.5Reproduction sequence
In a fresh temporary Hermes home, with no permanent configuration changes:
browser_navigatecompleted successfully.browser_visioncompleted successfully.opencode-go/mimo-v2.5, failed with:Hermes did not silently fall back to another provider. The logs show that the fallback entry matched the current
opencode-go/mimo-v2.5route, and the error was classified as non-retryable.This behavior is also consistent with earlier Hermes sessions using the same effective route, both directly and after a real fallback to
opencode-go/mimo-v2.5.What this establishes
The current
mainbranch still reproduces the failure whenbrowser_visionis followed by another request throughopencode-go/mimo-v2.5.The evidence is consistent with a compatibility problem in the request generated after
browser_visionand the OpenCode Go/MiMo request path. At this point I cannot determine whether the invalid or incompletetextfield is introduced by Hermes, transformed by OpenCode Go, or produced at the downstream adapter boundary.Limitations
opencode-go.Could you confirm whether Hermes is expected to normalize this request state before sending it through
opencode-go/mimo-v2.5, and whether the request should be normalized in Hermes or in the provider/relay layer?Related OpenCode Go report: anomalyco/opencode#32613