[web] Pasted/dragged images are sent inline to non-multimodal models, aborting the turn with provider 400 — please degrade to a file reference

What feature would you like to see?

Summary

When the active model does not declare image_in / video_in capability (e.g. a third-party text-only model configured via an OpenAI-compatible provider), pasting or dragging an image into the Kimi Code Web UI input still attaches the image inline to the model request. The provider rejects it (400 ... is not a multimodal model) and the whole turn is aborted — the agent never gets a chance to handle the image through tools.

Environment

• Client: Kimi Code Web UI (kimi web)
• Provider: custom OpenAI-compatible endpoint, model deepseek-v4-flash
• Model entry in config.toml declares capabilities = ["tool_use", "thinking"] — no image_in
• OS: Windows 11

Steps to reproduce

1. Switch to a model without image_in capability.
2. Drag an image file into the Web UI input box (or paste one from the clipboard).
3. Type any question about the image and submit.

Actual behavior

The image is embedded into the chat request as a multimodal content part. The provider responds:

400 deepseek-v4-flash is not a multimodal model
provider.api_error · HTTP 400

The turn fails immediately ("模型请求失败，本轮对话已中断"). Since the request never succeeds, the model cannot fall back to vision-capable MCP tools (e.g. an MCP server that forwards the image to a vision model and returns text).

Expected behavior

Either of the following, when the active model lacks image_in / video_in:

1. Preferred: automatically convert the pasted/dragged media into a file reference (save the attachment to the session/workspace directory and reference it by path in the prompt). The agent can then decide how to process it — e.g. call a vision MCP tool with that path. This keeps text-only models fully usable with image inputs.
2. Minimum: block media attachment in the input for non-multimodal models, with a clear notice, instead of letting the request fail at the provider.

The docs already state that media support "depends on the current model's multimodal capabilities (image_in / video_in)", so letting the attachment through to a 400 looks like a gap between design and the Web UI implementation.

Context

Text-only strong-reasoning models (DeepSeek etc.) are commonly paired with vision MCP plugins that analyze images out-of-band and return text. That workflow only works when images arrive as file paths — an inline attachment makes the whole session unusable the moment a user reflexively pastes a screenshot.

Additional information

No response

Start at the kimi web Web UI attachment and submission flow, and inspect how the active model's image_in/video_in capabilities are checked before a request is sent. Reproduce with a text-only model and an image attachment; done means media is converted to a file reference or clearly blocked instead of producing a provider 400.