openclaw - ✅(Solved) Fix Qwen: qwen3.6-plus image understanding blocked on Coding Plan endpoint despite model supporting vision [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
openclaw/openclaw#63654Fetched 2026-04-10 03:42:24
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
referenced ×2cross-referenced ×1

qwen3.6-plus is a multimodal model that supports image understanding, but the bundled qwen provider explicitly suppresses it when the configured endpoint is the Qwen Coding Plan (coding.dashscope.aliyuncs.com). This prevents the image tool and media-understanding pipeline from using qwen3.6-plus for vision tasks, even though the model itself supports it.

Root Cause

qwen3.6-plus is a multimodal model that supports image understanding, but the bundled qwen provider explicitly suppresses it when the configured endpoint is the Qwen Coding Plan (coding.dashscope.aliyuncs.com). This prevents the image tool and media-understanding pipeline from using qwen3.6-plus for vision tasks, even though the model itself supports it.

Fix Action

Fixed

PR fix notes

PR #63987: fix(qwen): allow qwen3.6-plus opt-in on Coding Plan #63654

Description (problem / solution / changelog)

Summary

  • Problem: The bundled qwen provider drops qwen3.6-plus from user config when baseUrl points at the Qwen Coding Plan endpoint, which makes vision/image flows fail with Unknown model.
  • Why it matters: Coding Plan users cannot opt-in to try qwen3.6-plus for image understanding even when they explicitly configure it.
  • What changed: Removed the qwen provider normalizeConfig filter that stripped qwen3.6-plus on Coding Plan endpoints. Built-in catalog suppression behavior remains unchanged.
  • What did NOT change (scope boundary): The bundled catalog still does not advertise qwen3.6-plus for Coding Plan endpoints by default, and the existing suppression hint remains.

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

  • Fixes #63654

User-visible / Behavior Changes

Users can now explicitly configure models.providers.qwen.models: [{ id: "qwen3.6-plus", input: ["text","image"], ... }] on Coding Plan endpoints without OpenClaw removing it during provider config normalization.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)

Repro + Verification

Environment

  • OS: Linux
  • Model/provider: Qwen (qwen)
  • Endpoint: https://coding.dashscope.aliyuncs.com/v1

Steps

  1. Configure models.providers.qwen.baseUrl to a Coding Plan endpoint and explicitly include qwen3.6-plus in models.providers.qwen.models.
  2. Run a vision flow (e.g. image tool / media-understanding pipeline) using qwen/qwen3.6-plus.

Expected

  • The explicitly configured model remains available for runtime lookup.

Actual (before)

  • Provider config normalization removed qwen3.6-plus, leading to Unknown model at runtime.

Evidence

  • Added test coverage to ensure explicit config is not mutated on Coding Plan endpoints.

Human Verification (required)

  • Verified scenarios:
    • pnpm test extensions/qwen/provider-catalog.test.ts
    • pnpm test extensions/qwen/index.test.ts
  • Edge cases checked:
    • Built-in catalog behavior unchanged for Coding Plan endpoints.
  • What I did not verify:
    • Live calls against DashScope/Coding Plan with real credentials.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)

Risks and Mitigations

  • Risk: Users may opt-in to a model that the Coding Plan endpoint still rejects at runtime.
    • Mitigation: Built-in catalog suppression/default docs remain conservative; this only changes explicit user opt-in behavior.

Changed files

  • extensions/qwen/index.test.ts (added, +77/-0)
  • extensions/qwen/index.ts (modified, +27/-9)

Code Example

// Line ~138-155
normalizeConfig: ({ providerConfig }) => {
  if (!isQwenCodingPlanBaseUrl(providerConfig.baseUrl)) return;
  const models = providerConfig.models?.filter((model) => model.id !== QWEN_36_PLUS_MODEL_ID);
  return models && models.length !== providerConfig.models?.length ? {
    ...providerConfig,
    models
  } : void 0;
},
suppressBuiltInModel: (ctx) => {
  // ...
  return {
    suppress: true,
    errorMessage: "Unknown model: qwen/qwen3.6-plus. qwen3.6-plus is not supported on the Qwen Coding Plan endpoint; use a Standard pay-as-you-go Qwen endpoint or choose qwen/qwen3.5-plus."
  };
}

---

Unknown model: dashscope/qwen3.6-plus

---

{
     "models": {
       "providers": {
         "dashscope": {
           "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
           "apiKey": "...",
           "api": "openai-completions",
           "models": [{ "id": "qwen3.6-plus", "input": ["text", "image"] }]
         }
       }
     },
     "agents": {
       "defaults": {
         "imageModel": { "primary": "dashscope/qwen3.6-plus" }
       }
     }
   }

---

[tools] image failed: Unknown model: dashscope/qwen3.6-plus
RAW_BUFFERClick to expand / collapse

Summary

qwen3.6-plus is a multimodal model that supports image understanding, but the bundled qwen provider explicitly suppresses it when the configured endpoint is the Qwen Coding Plan (coding.dashscope.aliyuncs.com). This prevents the image tool and media-understanding pipeline from using qwen3.6-plus for vision tasks, even though the model itself supports it.

Why it matters

  • Users on the Coding Plan subscription cannot use qwen3.6-plus for image analysis via the image tool.
  • The model does support image understanding on Alibaba DashScope, but OpenClaw treats it as unavailable on the Coding Plan endpoint.
  • This forces users to either switch to the Standard (pay-as-you-go) endpoint or use a different model for vision, even when their Coding Plan key should theoretically work.

What changed

The restriction is implemented in extensions/qwen/index.js:

// Line ~138-155
normalizeConfig: ({ providerConfig }) => {
  if (!isQwenCodingPlanBaseUrl(providerConfig.baseUrl)) return;
  const models = providerConfig.models?.filter((model) => model.id !== QWEN_36_PLUS_MODEL_ID);
  return models && models.length !== providerConfig.models?.length ? {
    ...providerConfig,
    models
  } : void 0;
},
suppressBuiltInModel: (ctx) => {
  // ...
  return {
    suppress: true,
    errorMessage: "Unknown model: qwen/qwen3.6-plus. qwen3.6-plus is not supported on the Qwen Coding Plan endpoint; use a Standard pay-as-you-go Qwen endpoint or choose qwen/qwen3.5-plus."
  };
}

This causes the image tool to fail with:

Unknown model: dashscope/qwen3.6-plus

Repro + Verification

Environment

  • OS: Linux (Debian)
  • Runtime: OpenClaw v2026.4.9 (npm global install)
  • Provider: Qwen (bundled)
  • Endpoint: https://coding.dashscope.aliyuncs.com/v1
  • Model: qwen3.6-plus
  • Config: custom dashscope provider with openai-completions API style

Steps

  1. Configure a Qwen provider pointing to the Coding Plan endpoint:

    {
      "models": {
        "providers": {
          "dashscope": {
            "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
            "apiKey": "...",
            "api": "openai-completions",
            "models": [{ "id": "qwen3.6-plus", "input": ["text", "image"] }]
          }
        }
      },
      "agents": {
        "defaults": {
          "imageModel": { "primary": "dashscope/qwen3.6-plus" }
        }
      }
    }
  2. Send an image via Feishu (or any channel) and ask the model to analyze it.

  3. Observe that the image tool fails with Unknown model: dashscope/qwen3.6-plus.

Expected

  • qwen3.6-plus should be usable for image understanding when the Coding Plan endpoint supports it.
  • The image tool should successfully call the model with the image attachment.

Actual

  • The image tool throws Unknown model: dashscope/qwen3.6-plus.
  • The model hallucinates image content instead of actually analyzing it.

Evidence

  • Gateway log:
    [tools] image failed: Unknown model: dashscope/qwen3.6-plus
  • Session transcript shows the model receiving [media attached: /path/to/image.jpg] but never invoking the image tool successfully.
  • The restriction is explicitly coded in extensions/qwen/index.js (lines ~138-155).

Compatibility / Migration

  • This is not a regression; it's a deliberate design choice in the current release.
  • However, it creates a capability gap for Coding Plan users who expect qwen3.6-plus to handle vision tasks.

Suggested fix

  1. If Alibaba officially supports qwen3.6-plus image understanding on the Coding Plan endpoint, remove the suppression logic.
  2. If support is uncertain, consider making this behavior configurable (e.g., allowCodingPlanVision: true) rather than hard-blocking it.
  3. Update the documentation to clarify whether qwen3.6-plus vision is officially unsupported on Coding Plan, or if this is a conservative compatibility guard that could be relaxed.

References

  • Official docs state: qwen3.6-plus input includes text, image with 1,000,000 context.
  • Docs also note: "Prefer Standard endpoints when you need this model" and "Coding Plan support can lag behind the public catalog."
  • This issue is about whether the lag is still current, or if the restriction can now be safely lifted.

extent analysis

TL;DR

Remove the suppression logic for qwen3.6-plus in extensions/qwen/index.js if Alibaba officially supports it on the Coding Plan endpoint.

Guidance

  • Verify with Alibaba whether qwen3.6-plus image understanding is officially supported on the Coding Plan endpoint.
  • Consider making the suppression behavior configurable (e.g., allowCodingPlanVision: true) to provide flexibility for users.
  • Update the documentation to reflect the current support status of qwen3.6-plus vision on Coding Plan endpoints.
  • Review the normalizeConfig function in extensions/qwen/index.js to ensure it correctly handles the qwen3.6-plus model when the endpoint is set to the Coding Plan.

Example

No code snippet is provided as the issue is more related to configuration and documentation rather than a specific code fix.

Notes

The solution depends on the official support status of qwen3.6-plus on the Coding Plan endpoint, which is unclear from the provided information. It's essential to verify this with Alibaba before making any changes.

Recommendation

Apply a workaround by configuring allowCodingPlanVision: true if the suppression logic is removed or made configurable, allowing users to opt-in to using qwen3.6-plus for vision tasks on the Coding Plan endpoint.

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

openclaw - ✅(Solved) Fix Qwen: qwen3.6-plus image understanding blocked on Coding Plan endpoint despite model supporting vision [1 pull requests, 1 participants]