Problem
When using a custom model that does not natively support vision (e.g. DeepSeek V3/R1/V4), Qoder proactively strips all images from the request before it is sent to the model. This means even if the user has configured an MCP server or a Skill that can convert images into text descriptions (e.g. using Qwen-VL), the image is already removed and the MCP/Skill never gets a chance to process it.
In short: Qoder’s client-side vision gate makes it impossible to use any third-party image understanding pipeline with non-vision models.
Solution
Provide a user-facing toggle (e.g. a setting like "allowImageProcessingByExtensions": true or a per-model flag) that, when enabled, skips the automatic image stripping for the selected model.
When this option is on:
- Images are kept in the request context as-is.
- If the model itself does not support vision, MCP servers or Skills can intercept the image, convert it to a text description, and inject the description back into the context before the model sees it.
- If no MCP/Skill handles the image, Qoder can fall back to its current behavior (strip the image and warn the user).
This way, users who have set up their own image-to-text pipeline (via MCP or Skill) are not blocked by Qoder’s built-in assumption.
Use Case
A common scenario: a user wants to use DeepSeek (a powerful and cost-effective text model) as their primary coding model in Qoder, but also needs image understanding for tasks like UI screenshot analysis, diagram interpretation, or error screenshot debugging.
The user sets up an MCP server (or a Skill) that calls Qwen-VL to recognize image content and return a text description to the model. However, because Qoder strips the image before the model can decide to call the MCP tool, the entire pipeline is deadlocked — the model never sees the image, never triggers the tool call, and the user gets no image understanding at all.
This is a deadlock by design: the model needs to see the image to know it should call the tool, but the image is removed before the model ever gets it.
Priority
High - Blocking issue
Without this, there is no workaround for users who want to combine a non-vision custom model with third-party image understanding in Qoder. The only alternatives are switching to a model that natively supports vision (which may not be desirable for cost, quality, or availability reasons) or leaving Qoder entirely.
Additional Info
- The same issue does not occur in Claude Code or Codex, where Skills can intercept images before they reach the model. Qoder’s current behavior is more restrictive than these competing tools.
- Relevant open-source projects that solve this via Skill/MCP:
claude-vision-skill,deepseek-eyes— both rely on the ability to process images before the model sees them. - DeepSeek’s web UI already supports image input (as of June 2026), but the API does not yet expose multimodal capabilities. Until the API catches up, this toggle would unblock a large number of users.