Skip to content

fix(vision): providers that reject images in tool results no longer get the multimodal envelope — meta-ai/Muse Spark 400 (#101668, salvages #89987) - #101947

Merged
teknium1 merged 2 commits into
mainfrom
fix/vision-tool-message-veto
Sep 3, 2026
Merged

teknium1 merged 2 commits into
mainfrom
fix/vision-tool-message-veto

Conversation

@teknium1

@teknium1 teknium1 commented Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Providers whose profile declares supports_vision_tool_messages=False no longer receive the vision_analyze multimodal envelope inside a role:tool message — and the bundled meta-ai profile now declares it, fixing the Muse Spark HTTP 400 messages[N].content did not match any supported type (#101668).

Changes

  • tools/vision_tools.py — new _profile_rejects_tool_media(provider) predicate (profile exists and supports_vision_tool_messages is False). Both fast-path gates route through it: _supports_media_in_tool_results() returns False up front (so supports_vision=True can no longer override the veto), and _should_use_native_vision_fast_path() checks it ahead of the _lookup_supports_vision(...) arm (so a models.dev / custom_providers capability hit can't re-open the path either). Cherry-picked from fix(vision): honor supports_vision_tool_messages=False in tool-result media gates #89987 by @liuhao1024; the two inline try/except blocks in the original were collapsed into the single shared predicate.
  • plugins/model-providers/meta-ai/__init__.py — supports_vision_tool_messages=False with a one-line comment citing the 400. supports_vision=True is unchanged, so user-turn image input stays native; only the tool-result envelope falls back to the aux-LLM text path (same mechanism xiaomi already uses).
  • Tests — contributor's two tests kept, trimmed: profile veto beats supports_vision=True; veto still holds when the capability lookup says vision-capable. One assertion added to the existing test_profile_registered in tests/providers/test_meta_ai_profile.py.

On current main nothing in tools/ read supports_vision_tool_messages — only run_agent.py's post-hoc summary path did, and the vision fast path built the envelope before that ever ran.

Validation

Check Result
pytest tests/tools/test_vision_native_fast_path.py tests/providers/test_meta_ai_profile.py 29 passed
Same + tests/run_agent/test_vision_tool_messages.py + tests/hermes_cli/test_cli_custom_provider_vision.py 38 passed
New veto tests with tools/vision_tools.py reverted to main both FAIL (pin the bug)
Real-import probe, fresh temp HERMES_HOME: _supports_media_in_tool_results("meta-ai","muse-spark-1.2") main True → branch False
Same probe, ("xiaomi","mimo-v2.5") main True → branch False
Same probe, ("anthropic","claude-opus-4-6") (control) True → True
ruff check on touched files clean
scripts/audit_pr_attribution.py --fix all emails mapped

Live repro: the Meta wire-level 400 was not reproduced live (no META_API_KEY available here); the reporter's trace in #101668 is relied on for the API behavior. The gate flip above was verified with real imports against the registered provider profiles.

Fixes #101668
Refs #47742 #89981

Credits: @liuhao1024 — cherry-picked from #89987 with authorship preserved.

Infographic

vision-tool-message-veto

liuhao1024 and others added 2 commits September 3, 2026 00:12
… media gates

A ProviderProfile that declares supports_vision_tool_messages=False accepts
images in user messages but rejects list-type tool-result content with 400
(xiaomi/MiMo "text is not set"). supports_vision=True alone used to flip
_supports_media_in_tool_results to True, and a vision-capable capability
lookup could re-open _should_use_native_vision_fast_path — so the native
multimodal envelope landed in a role:tool message and 400'd every turn.

Both gates now go through one _profile_rejects_tool_media() veto.

Refs #89981

(cherry picked from commit daed88f, trimmed)
…k 400s on image tool results

Muse Spark accepts images on user turns but returns HTTP 400
invalid_request_error 'messages[N].content did not match any supported
type' when the vision_analyze multimodal envelope lands in a role:tool
message. With the profile veto now honored by the vision fast-path gates,
declaring the limitation routes tool-result images through the aux-LLM
text path while user-message vision stays enabled.

Fixes #101668
Refs #47742
@github-actions

github-actions Bot commented Sep 3, 2026 •

Copy link
Copy Markdown

૮ >ﻌ< ა ci review

ran on bdcc96a — fix(meta-ai): declare supports_vision_tool_messages=False —

⚠️ Warnings

CI timings · View report · View job

Wall time 6m23s vs 4m23s (+45.6%). 8 job(s) slower, 4 faster, 2 unchanged.

  • OS-specific tests / Windows-only tests: +45.0s
  • OSV scan / Emit review status: +43.0s
  • OS-specific tests / macOS-only tests: -5.0s
  • Python tests / Run tests: -4.0s
  • Profile artifact check / Reject profile archives: -4.0s

OSV vulnerability scan · View job

28 known vulnerabilities found in pinned dependencies.

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

@alt-glitch alt-glitch added type/bug Something isn't working comp/plugins Plugin system and bundled plugins tool/vision Vision analysis and image generation P3 Low — cosmetic, nice to have labels Sep 3, 2026
@teknium1
teknium1 merged commit d6bb94a into main Sep 3, 2026
41 checks passed
@teknium1
teknium1 deleted the fix/vision-tool-message-veto branch September 3, 2026 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/plugins Plugin system and bundled plugins P3 Low — cosmetic, nice to have tool/vision Vision analysis and image generation type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

meta-ai/muse-spark: HTTP 400 "did not match any supported type" — native vision fast path puts images in tool-result messages

3 participants