Which models actually read images
A model page saying “Vision” is not evidence. We sent every model in our catalog the same two images and asked what was in them — and the answers split the catalog in half. Three models read images and are sold as such; four do not and are marked accordingly, so a request with an image is refused before it costs you anything.
Results, model by model
- qwen3.8-27b
- Reads images — both probe images identified correctly
- kimi-k2.6
- Reads images — both probe images identified correctly
- kimi-k2.7-code
- Reads images — both probe images identified correctly
- glm-5.2
- Does not — accepted the images, answered “Unknown”, then nothing
- glm-4.7-flash
- Does not — refuses image input explicitly, the honest failure
- deepseek-v4-pro
- Does not — accepted the images and returned nothing at all
- deepseek-v4-flash
- Does not — accepted the images, answered “unknown” twice
The three that read images (40% off list)
- Input
$0.45$0.27- Output
$3.20$1.92
@cf/qwen/qwen3.8-27b
- Input
$0.95$0.57- Output
$4.00$2.40
@cf/moonshotai/kimi-k2.6
- Input
$0.95$0.57- Output
$4.00$2.40
@cf/moonshotai/kimi-k2.7-code
Images bill as input tokens at each model’s normal rate — no separate image fee. Live pricing for all seven models on the models page.
Three ways a model can fail at vision
Our probe, 2026-08-18. The middle case is the expensive one: no error, real compute spent, an answer that sounds fine and is not grounded in your image.
3 of 7
models that genuinely read images
Silent
accepts the image, ignores it, still bills you
Explicit
refuses image input outright — the failure you want
0 requests
we let reach a blind model with an image
Sending an image
Same call on any of the three: a content array with your text and a base64 data URI. Remote http(s) links are not fetched.
import base64
from openai import OpenAI
client = OpenAI(
base_url="https://api.clfaigateway.dev/v1",
api_key="sk-gw-...", # app.clfaigateway.dev
)
with open("screenshot.png", "rb") as f:
b64 = base64.b64encode(f.read()).decode()
resp = client.chat.completions.create(
model="qwen3.8-27b",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "What does this screen show?"},
# Must be a data: URI. Remote http(s) links are not fetched.
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{b64}"}},
],
}],
# Leave room: the model thinks before it answers, and a tiny budget
# can be spent entirely on reasoning, returning empty content.
max_completion_tokens=400,
)
print(resp.choices[0].message.content)Vision on the gateway — common questions
Because a capability listed on a model page describes what the weights are meant to do, not what the served endpoint does with your request today. Two models advertised as vision-capable took our images and answered as if they had never seen them. We publish what our own probes returned, and we re-run them whenever we add a model.
See capabilities per model →We mark image capability per model from probe results, and the gateway refuses image input on any model not marked for it — a 400 before the request goes upstream, at no cost to you. The failure mode we protect against is the silent one: a model that takes the image, ignores it, answers confidently from the text, and bills you in full.
Error reference →qwen3.8-27b is the cheapest of the three and the newest. kimi-k2.6 is the balanced generalist, kimi-k2.7-code is tuned for repository-scale code work — both carry the same 262K window. All three take the same request shape, so trying another one is a one-word change.
Compare prices →Small print, scanned documents and dense charts. Our probe establishes that a model genuinely reads the image it is given — it does not establish OCR quality, so we do not sell OCR. If you need that, test it on your own documents first; a failed request that produced nothing costs $0.
Image quickstart →