Can you send images to these models?
Three of the five see images. GLM-5.3 refuses the request outright. DeepSeek-V4-Pro accepts it, returns 200, and does not see the image.
What we found
Some of these models are multimodal upstream, and being multimodal upstream is not the same as accepting an image through an OpenAI-compatible endpoint. We sent one image part in a standard content array to all five, using a solid colour square and asking for the colour in one word, so that a model which received the image answers correctly and a model which did not cannot bluff. The colour was varied across runs, because a single colour cannot tell seeing from guessing.
Three work. GLM-5.3-Flash, Kimi K3 and DeepSeek-V4-Flash all named the colour correctly. GLM-5.3-Flash was tested hardest, across five colours and two passes, and got all ten right.
GLM-5.3 refuses, and refuses honestly. The request comes back as a 400 with the message that messages.content.type is invalid and the only allowed value is text. That is the good kind of failure: you find out immediately, and the error says exactly what is wrong.
DeepSeek-V4-Pro is the one to know about. It accepts the request, returns a normal 200, and answers Unknown. It did this on nine of ten attempts across five colours. There is no error, no warning, and nothing in the response to tell you the image was not used. If you are branching on the status code, this looks like success.
Note that the two DeepSeek rows differ from each other, which is the opposite of what most people would assume. The Flash row sees images and the Pro row does not, so picking the larger model here costs you the capability.
What to do instead
- For image input, use GLM-5.3-Flash, Kimi K3 or DeepSeek-V4-Flash. All three answered correctly on every attempt.
- Do not send images to DeepSeek-V4-Pro expecting a failure to be visible. Check the answer, not the status code.
- If you are testing this yourself, give the request a generous max_tokens. On a reasoning model a small budget returns an empty string, which looks exactly like a vision failure and is not one. Our own first run made this mistake.
How this was measured
An unattributed measurement is a marketing claim, so here is the receipt.
- Probe
- probe_vision.py
- Measured
- 2026-09-21
- Applies to
- every model we serve
We found this by running the probe against the models we serve, which is also why it is worth trusting: it is a reading rather than a restatement of somebody's documentation. The full catalog is on /models, and what a request costs is on /pricing.
Upstream behaviour changes without notice, and a measurement is only as good as its date. If you find this is no longer true, tell us on the support page and we will re-run the probe.