openclaw - ✅(Solved) Fix [Bug] image tool 不支持 minimax provider 作为图片理解后端 [3 pull requests, 5 comments, 2 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
openclaw/openclaw#54400Fetched 2026-04-08 01:28:06
View on GitHub
Comments
5
Participants
2
Timeline
7
Reactions
0
Timeline (top)
commented ×5mentioned ×1subscribed ×1

PR fix notes

PR #67105: fix: extend isMinimaxVlmModel to support M2.5/M2.7/M2.7-highspeed

Description (problem / solution / changelog)

When MiniMax M2.7 is used as the primary model, the image tool would incorrectly send image requests directly to M2.7's chat endpoint, causing 400 errors. The image understanding for M2.7 models should be routed through the MiniMax-VL-01 plugin's /v1/coding_plan/vlm API.

This fix extends isMinimaxVlmModel to recognize MiniMax-M2.5, MiniMax-M2.7, and MiniMax-M2.7-highspeed, allowing them to trigger the VL fallback path correctly.

Fixes: #64244 Related: #54400, #53575

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem:
  • Why it matters:
  • What changed:
  • What did NOT change (scope boundary):

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause:
  • Missing detection / guardrail:
  • Contributing context (if known):

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
  • Scenario the test should lock in:
  • Why this is the smallest reliable guardrail:
  • Existing test that already covers this (if any):
  • If no new test is added, why not:

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[user action] -> [old state]

After:
[user action] -> [new state] -> [result]

Security Impact (required)

  • New permissions/capabilities? (Yes/No)
  • Secrets/tokens handling changed? (Yes/No)
  • New/changed network calls? (Yes/No)
  • Command/tool execution surface changed? (Yes/No)
  • Data access scope changed? (Yes/No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS:
  • Runtime/container:
  • Model/provider:
  • Integration/channel (if any):
  • Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
  • Edge cases checked:
  • What you did not verify:

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No)
  • Config/env changes? (Yes/No)
  • Migration needed? (Yes/No)
  • If yes, exact upgrade steps:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk:
    • Mitigation:

Changed files

  • src/agents/minimax-vlm.ts (modified, +8/-1)
  • ui/src/ui/app-gateway.ts (modified, +13/-2)

PR #67112: fix: extend isMinimaxVlmModel to support M2.5/M2.7/M2.7-highspeed

Description (problem / solution / changelog)

When MiniMax M2.7 is used as the primary model, the image tool would incorrectly send image requests directly to M2.7's chat endpoint, causing 400 errors. The image understanding for M2.7 models should be routed through the MiniMax-VL-01 plugin's /v1/coding_plan/vlm API.

This fix extends isMinimaxVlmModel to recognize MiniMax-M2.5, MiniMax-M2.7, and MiniMax-M2.7-highspeed, allowing them to trigger the VL fallback path correctly.

Fixes: #64244 Related: #54400, #53575


fix: debounce session.message reload to prevent webchat flicker

When lossless-claw or other plugins fire session.message events rapidly, the webchat UI flickers because loadChatHistory sets chatLoading=true on every event, causing messages to disappear and reappear.

This fix adds a 500ms debounce: instead of reloading immediately on each event, we wait 500ms after the last event before reloading. Multiple events within 500ms only trigger one reload.

Fixes: #66274

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem:
  • Why it matters:
  • What changed:
  • What did NOT change (scope boundary):

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause:
  • Missing detection / guardrail:
  • Contributing context (if known):

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
  • Scenario the test should lock in:
  • Why this is the smallest reliable guardrail:
  • Existing test that already covers this (if any):
  • If no new test is added, why not:

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[user action] -> [old state]

After:
[user action] -> [new state] -> [result]

Security Impact (required)

  • New permissions/capabilities? (Yes/No)
  • Secrets/tokens handling changed? (Yes/No)
  • New/changed network calls? (Yes/No)
  • Command/tool execution surface changed? (Yes/No)
  • Data access scope changed? (Yes/No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS:
  • Runtime/container:
  • Model/provider:
  • Integration/channel (if any):
  • Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
  • Edge cases checked:
  • What you did not verify:

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No)
  • Config/env changes? (Yes/No)
  • Migration needed? (Yes/No)
  • If yes, exact upgrade steps:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk:
    • Mitigation:

Changed files

  • src/agents/minimax-vlm.ts (modified, +8/-1)
  • ui/src/ui/app-gateway.ts (modified, +13/-2)

PR #67234: fix: extend isMinimaxVlmModel to support M2.5/M2.7/M2.7-highspeed

Description (problem / solution / changelog)

When MiniMax M2.7 is used as the primary model, the image tool would incorrectly send image requests directly to M2.7's chat endpoint, causing 400 errors. The image understanding for M2.7 models should be routed through the MiniMax-VL-01 plugin's /v1/coding_plan/vlm API.

This fix extends isMinimaxVlmModel to recognize MiniMax-M2.5, MiniMax-M2.7, and MiniMax-M2.7-highspeed, allowing them to trigger the VL fallback path correctly.

Fixes: #64244 Related: #54400, #53575


Summary

  • Problem: M2.7 models not recognized as VL models, causing 400 errors on image requests
  • Why it matters: Image understanding broken for M2.7 primary model users
  • What changed: isMinimaxVlmModel now accepts M2.5, M2.7, M2.7-highspeed
  • What did NOT change: No other models or behavior affected

Change Type

  • Bug fix

Scope

  • Agents / tool execution

Linked Issue

  • Closes #64244

Changed files

  • src/agents/minimax-vlm.normalizes-api-key.test.ts (modified, +4/-1)
  • src/agents/minimax-vlm.ts (modified, +8/-1)
RAW_BUFFERClick to expand / collapse

Bug 描述

复现步骤:

  1. 在 openclaw.json 中配置 minimax provider,model 包含 image 输入类型(input: ["text", "image"])
  2. 配置 imageModel: "minimax/MiniMax-M2.5"
  3. 发送图片给 bot

预期行为: image tool 应调用 minimax 的视觉接口进行图片理解

实际行为: 返回错误:"Model does not support images: minimax-portal/MiniMax-M2.7"

环境信息

  • OpenClaw 版本:2026.3.23-2
  • 模型:minimax/MiniMax-M2.5(配置了 input: ["text", "image"])
  • minimax API 认证方式:api_key(Token Plan Key,sk-cp- 开头)

日志

调用日志显示 minimax API 直接返回了不支持图片的错误,说明 OpenClaw 尝试调用的 API 端点与 minimax 实际的图片理解接口不匹配。

分析

  1. minimax M2.5/M2.7 文档明确说明"默认集成识图能力"
  2. 但 OpenClaw 的 image tool 走的是 media-understanding provider 机制
  3. minimax provider 没有注册 media-understanding provider,导致图片理解请求无法路由

建议

请在 minimax provider 中实现 media-understanding provider 接口,或者提供替代方案让 MiniMax 的视觉能力可以通过 image tool 调用。

extent analysis

Fix Plan

To resolve the issue, we need to implement the media-understanding provider interface in the minimax provider. Here are the concrete steps:

  • Update the minimax provider to implement the media-understanding provider interface:
class MiniMaxProvider:
    # ... existing code ...

    def supports_media_understanding(self):
        return True

    def media_understanding(self, image):
        # Call the minimax API for image understanding
        api_url = "https://api.minimax.com/v1/media-understanding"
        headers = {"Authorization": f"Bearer {self.api_key}"}
        response = requests.post(api_url, headers=headers, json={"image": image})
        return response.json()
  • Register the minimax provider as a media-understanding provider in the OpenClaw configuration:
{
    "providers": {
        "minimax": {
            "type": "media-understanding",
            "api_key": "sk-cp-..."
        }
    }
}
  • Update the image tool to use the minimax provider for image understanding:
class ImageTool:
    # ... existing code ...

    def understand_image(self, image):
        provider = self.get_provider("minimax")
        if provider.supports_media_understanding():
            return provider.media_understanding(image)
        else:
            raise ValueError("Provider does not support media understanding")

Verification

To verify that the fix worked, send an image to the bot and check that the minimax API is called correctly and returns the expected response.

Extra Tips

Make sure to update the minimax provider documentation to reflect the new media-understanding capability. Additionally, consider adding error handling and logging to the media_understanding method to handle any potential issues with the minimax API.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING