Summary
Qwen3.8-Max-Preview is a multimodal model (text + images + video + documents) per Alibaba's model card, but OpenWorker strips image attachments sent to it, showing "[image attachment — not viewable by this model]". The cause is OpenWorker's own capability table, not the model: the curated matrix has no Qwen3.8 entry, and the qwen prefix heuristic hardcodes vision=False, so image parts are dropped client-side before the request ever reaches the model.
Why this matters
Vision is a core reason to pick Qwen3.8-Max-Preview over the text-only Qwen3-Max. Right now, selecting it in OpenWorker silently degrades it to text-only — a user has no way to enable vision short of a code change, and the failure is invisible (no error; the image is just quietly replaced with a placeholder string).
What I expected
Sending an image to a session running qwen3.8-max-preview would pass the image to the model, as it does for the vision-true entries in the matrix (Claude, Gemini, GPT-5.x, Muse Spark, Kimi-K3).
What happens instead
The image is removed from the user turn before the model is called. The assistant receives only the text of the message, prefixed with the literal placeholder:
[image attachment — not viewable by this model]
Root cause (traced in source)
- No matrix entry for Qwen3.8-Max-Preview
In coworker/providers/matrix.py, the only Qwen entry is the text-only Qwen3-Max:
_AGENTIC = ModelCapabilities(
tools=True, vision=False, parallel_tool_calls=True, streaming=True
)
...
"qwen:qwen3-max": ModelEntry("Qwen3 Max · Alibaba", _AGENTIC, 256_000),
There is no qwen:qwen3.8-max-preview (or any Qwen-VL) entry, so entry_for() returns None and the capability probe falls through to the heuristics.
- The qwen prefix heuristic forces vision=False
In coworker/providers/capabilities.py, the fallback for OpenAI-compatible vendors matches on the qwen prefix and unconditionally sets vision=False:
if name.startswith(
("deepseek", "glm", "kimi", "minimax", "qwen", "grok", "mistral", "magistral")
):
return ModelCapabilities(
tools=True, vision=False, parallel_tool_calls=True, streaming=True
)
This fires for any custom-added qwen… model string, so adding qwen3.8-max-preview via "add any model string at your own risk" does not enable vision — the prefix match overrides the model's real capability.
- vision=False causes the client-side strip
In coworker/attachments.py, build_user_content() constructs the OpenAI content-parts (and does handle image_url parts correctly), but image parts built this way are dropped before the turn is sent when the selected model's capability flag says vision=False. The placeholder text is what the model then sees.
Proposed fix
Either (preferred) add a curated matrix entry for Qwen3.8-Max-Preview flagged vision-true, mirroring how Muse Spark and Kimi-K3 were given vision exceptions:
"qwen:qwen3.8-max-preview": ModelEntry(
"Qwen3.8 Max Preview · Alibaba",
ModelCapabilities(
tools=True, vision=True, parallel_tool_calls=True, streaming=True
),
1_000_000, # 1M-token context per Alibaba's spec
),
or, more general, narrow the qwen prefix heuristic so it does not blanket-disable vision for the whole family (e.g. match the text-only flagships qwen3-max / qwen2.5-max explicitly, and leave newer/preview multimodal Qwen models to a matrix entry or a -vl/multimodal heuristic).
The same currently affects glm (GLM-5.2 is marked _AGENTIC / vision=False in the matrix), so a GLM-4V-style vision entry would be the analogous ask for that family.
Evidence that the model is multimodal
Alibaba's Qwen3.8-Max-Preview model card lists "Visual Understanding" among its capabilities.
Multiple independent sources (eesel AI, vp-land, MarkTechPost, 2026-07) describe it as a 2.4T-parameter sparse-MoE multimodal model (text, images, video, documents) with a 1M-token context window.
Reproduction
Configure the Qwen provider in OpenWorker with a valid Alibaba/DashScope API key.
Add qwen3.8-max-preview as the session model (custom model string, or once a curated entry exists, select it).
Start a new session (capability flags are read at session start).
Attach an image and send any message.
Observe: the assistant's turn begins with [image attachment — not viewable by this model], and the model never receives the image.
Environment
OpenWorker, latest main (capabilities/matrix/registry read from github.com/andrewyng/openworker on 2026-08-02).
macOS, Apple Silicon.
Model: qwen3.8-max-preview via the Qwen (Alibaba DashScope) OpenAI-compatible endpoint.
Context window note
Alibaba lists a 1M-token context for Qwen3.8-Max-Preview; the current Qwen3-Max matrix entry uses 256_000. If Qwen3.8 is added, the context-window value should be updated so the GUI's context-fill meter is accurate.
Summary
Qwen3.8-Max-Preview is a multimodal model (text + images + video + documents) per Alibaba's model card, but OpenWorker strips image attachments sent to it, showing "[image attachment — not viewable by this model]". The cause is OpenWorker's own capability table, not the model: the curated matrix has no Qwen3.8 entry, and the qwen prefix heuristic hardcodes vision=False, so image parts are dropped client-side before the request ever reaches the model.
Why this matters
Vision is a core reason to pick Qwen3.8-Max-Preview over the text-only Qwen3-Max. Right now, selecting it in OpenWorker silently degrades it to text-only — a user has no way to enable vision short of a code change, and the failure is invisible (no error; the image is just quietly replaced with a placeholder string).
What I expected
Sending an image to a session running qwen3.8-max-preview would pass the image to the model, as it does for the vision-true entries in the matrix (Claude, Gemini, GPT-5.x, Muse Spark, Kimi-K3).
What happens instead
The image is removed from the user turn before the model is called. The assistant receives only the text of the message, prefixed with the literal placeholder:
[image attachment — not viewable by this model]
Root cause (traced in source)
In coworker/providers/matrix.py, the only Qwen entry is the text-only Qwen3-Max:
_AGENTIC = ModelCapabilities(
tools=True, vision=False, parallel_tool_calls=True, streaming=True
)
...
"qwen:qwen3-max": ModelEntry("Qwen3 Max · Alibaba", _AGENTIC, 256_000),
There is no qwen:qwen3.8-max-preview (or any Qwen-VL) entry, so entry_for() returns None and the capability probe falls through to the heuristics.
In coworker/providers/capabilities.py, the fallback for OpenAI-compatible vendors matches on the qwen prefix and unconditionally sets vision=False:
if name.startswith(
("deepseek", "glm", "kimi", "minimax", "qwen", "grok", "mistral", "magistral")
):
return ModelCapabilities(
tools=True, vision=False, parallel_tool_calls=True, streaming=True
)
This fires for any custom-added qwen… model string, so adding qwen3.8-max-preview via "add any model string at your own risk" does not enable vision — the prefix match overrides the model's real capability.
In coworker/attachments.py, build_user_content() constructs the OpenAI content-parts (and does handle image_url parts correctly), but image parts built this way are dropped before the turn is sent when the selected model's capability flag says vision=False. The placeholder text is what the model then sees.
Proposed fix
Either (preferred) add a curated matrix entry for Qwen3.8-Max-Preview flagged vision-true, mirroring how Muse Spark and Kimi-K3 were given vision exceptions:
"qwen:qwen3.8-max-preview": ModelEntry(
"Qwen3.8 Max Preview · Alibaba",
ModelCapabilities(
tools=True, vision=True, parallel_tool_calls=True, streaming=True
),
1_000_000, # 1M-token context per Alibaba's spec
),
or, more general, narrow the qwen prefix heuristic so it does not blanket-disable vision for the whole family (e.g. match the text-only flagships qwen3-max / qwen2.5-max explicitly, and leave newer/preview multimodal Qwen models to a matrix entry or a -vl/multimodal heuristic).
The same currently affects glm (GLM-5.2 is marked _AGENTIC / vision=False in the matrix), so a GLM-4V-style vision entry would be the analogous ask for that family.
Evidence that the model is multimodal
Alibaba's Qwen3.8-Max-Preview model card lists "Visual Understanding" among its capabilities.
Multiple independent sources (eesel AI, vp-land, MarkTechPost, 2026-07) describe it as a 2.4T-parameter sparse-MoE multimodal model (text, images, video, documents) with a 1M-token context window.
Reproduction
Configure the Qwen provider in OpenWorker with a valid Alibaba/DashScope API key.
Add qwen3.8-max-preview as the session model (custom model string, or once a curated entry exists, select it).
Start a new session (capability flags are read at session start).
Attach an image and send any message.
Observe: the assistant's turn begins with [image attachment — not viewable by this model], and the model never receives the image.
Environment
OpenWorker, latest main (capabilities/matrix/registry read from github.com/andrewyng/openworker on 2026-08-02).
macOS, Apple Silicon.
Model: qwen3.8-max-preview via the Qwen (Alibaba DashScope) OpenAI-compatible endpoint.
Context window note
Alibaba lists a 1M-token context for Qwen3.8-Max-Preview; the current Qwen3-Max matrix entry uses 256_000. If Qwen3.8 is added, the context-window value should be updated so the GUI's context-fill meter is accurate.