Best Model for Vision Tasks: What Images Are Actually For

Vision support in a coding workflow is narrower than the marketing suggests. You are almost never doing image classification. You are pasting a screenshot of a broken UI, a whiteboard photo of an architecture, an error dialog, or a page of a scanned PDF, and asking a model to work from it.

Those are four different tasks with quite different success rates, and knowing which one you have is more useful than knowing which model tops a multimodal leaderboard.

Which open-weight models take images at all

The first filter is blunt: most strong open-weight coding models are text-only, so the shortlist is short before you compare anything.

MiniMax M3 is natively multimodal, meaning image handling is part of the architecture rather than an adapter bolted on, and it ships a one-million-token context. Kimi K2.6 is a vision-language model with a 256K context, MLA attention, and a 1T-total mixture-of-experts design activating 32B per token.

That is a genuinely restrictive shortlist, and it produces a real trade-off: the models with the strongest text coding results are not necessarily the ones that accept images. If a task truly needs vision, you may be choosing a weaker coder to get it, and you should check whether the image is load-bearing before accepting that.

Often it is not. A screenshot of a stack trace is worse input than the stack trace as text, in every respect — it costs more tokens, introduces OCR error, and gives the model less to work with. Paste text as text.

Screenshots of broken UI: the strongest case

This is where image input genuinely adds something. A rendered page contains information the source does not: what actually overlapped, where the text clipped, whether the contrast is unreadable in dark mode.

Models handle gross layout failure reasonably. Elements on top of each other, truncated labels, a component pushed off-screen, obviously wrong spacing — these are detectable and a model will describe them accurately enough to act on.

Fine visual judgement is a different matter and expectations should be low. Whether the spacing is balanced, whether the typographic hierarchy reads correctly, whether a colour choice feels right — models are unreliable here and confidently so. Treat vision-driven UI iteration as an automated smoke test that catches breakage, not as design review.

Pair it with a text description of what the screen is supposed to show. Comparing an image against a stated intent produces far better findings than asking a model to evaluate an image on its own. Mobile development model selection covers wiring this into a simulator loop.

Diagrams and whiteboards: better than expected

Photographing an architecture diagram and asking a model to turn it into a description, a schema, or scaffolding code works surprisingly well, because diagrams are structured. Boxes and arrows encode relationships explicitly, and that is the kind of structure a model extracts reliably.

The failure mode is handwriting and ambiguity rather than reasoning. Faint marker, a photograph at an angle, arrows whose direction is unclear, labels that overlap. Take the photo straight-on with good light and most of that disappears.

Always have the model restate its reading of the diagram before it acts on it. If it has the arrow direction backwards, you want to know that in one sentence rather than in three files of generated code built on the misreading.

Documents and OCR: verify before trusting

Extracting structured data from scanned invoices, forms or reports is a common ask, and multimodal models do it competently on clean input.

The problem is that errors are silent. A model misreading 8 as 3 in an amount produces perfectly well-formed JSON containing a wrong number, and nothing downstream flags it. Compare that to a coding error, which fails a test.

So build verification into the pipeline rather than into the model choice. Ask for the extracted value together with a confidence signal and the surrounding text it read the value from. Cross-check totals against line items where the document has arithmetic. Route anything below a threshold to a human. Structured outputs and JSON mode covers constraining the response shape so these checks are mechanical.

Images are expensive in ways that surprise people

An image is converted into tokens, and a high-resolution screenshot is not cheap. A full-page capture can consume as many tokens as several thousand words of text, and that cost recurs on every turn the image stays in context.

This bites hardest in agentic loops. An agent that takes a screenshot on each iteration and keeps them all accumulates image tokens fast, and by turn fifteen most of the context is stale pictures of screens that have since changed.

Two rules handle it. Downscale before sending — most tasks do not need full resolution, and half the pixels is a quarter of the tokens. And drop old images from the transcript once they have been used, keeping only the model's text description of what it saw. Context compaction strategies covers doing that cleanly.

Choosing

For vision inside a long agentic loop, MiniMax M3 — native multimodality and a one-million-token window suit the pattern, though note that pricing sources disagree on M3, quoting figures roughly a factor of two apart, so check the vendor page before budgeting.

For one-shot image work where 256K of context is plenty, Kimi K2.6 is the alternative, at roughly $0.95 in and $4.00 out per million.

For everything else, ask first whether the image is genuinely necessary. Text pasted as text is cheaper, more accurate and available on every model including the strongest text-only coders. Reserve vision for the cases where the rendered output carries information the source genuinely does not. Multimodal models explained covers how image tokenisation works if you want the mechanics.