Someone on a procurement committee sees that DeepSeek-R1 tops a reasoning leaderboard, notes that the shortlisted workload includes screenshots and scanned invoices, and pencils the model in for the whole task. That single assumption — that a headline model must handle images because it handles everything else well — is where an evaluation cycle goes wrong before it starts.

Here is the short answer: DeepSeek-R1 is a text-input, text-output reasoning model. It is not a vision-language model, and feeding it image inputs is not a supported path. If your prompt distribution contains images — document photos, UI screenshots, chart crops — DeepSeek-R1 cannot serve that part of the workload, no matter how strong its reasoning scores look in isolation. Confirming this before you build an eval harness is the difference between a filtered shortlist and days of wasted engineering.

What modalities does DeepSeek-R1 actually support?

Modality scope is a plain question: what can go in, and what comes out? For DeepSeek-R1 the answer is text in, text in the form of tokens out, with the model’s distinctive strength being long-form chain-of-thought reasoning over that text. The reasoning focus is what earns it a place on shortlists — it is built to work through multi-step problems, show intermediate steps, and produce structured answers. That focus does not extend to pixels.

A vision-language model — the class that includes systems designed to accept an image alongside a text prompt — carries an image encoder that turns visual input into embeddings the language model can attend over. A text-only reasoning model has no such encoder in its supported input path. The distinction is architectural, not a matter of prompt phrasing. You cannot coax image understanding out of a model that was never wired to receive an image.

This matters because reputation travels faster than specification. A model becomes known for one thing — reasoning, in this case — and buyers extrapolate a general competence that the model’s actual input contract does not grant. We see this pattern regularly when a team shortlists on leaderboard position rather than on the input and output types their own task requires.

Why verify modality scope instead of assuming it from reputation?

An LLM evaluation is expensive to run properly. You build a prompt set that mirrors the real workload, you construct scoring rubrics, you run calibration passes to understand how the model’s confidence signals map to actual error rates. All of that assumes the model can accept the inputs in the first place. If it cannot, the evaluation is not merely inaccurate — it is undefined.

Consider what happens mechanically. A procurement-grade eval scores a candidate against a task that includes image inputs. The harness sends an image-bearing prompt to a text-only model. The model either rejects the input, silently ignores the image and answers from the text alone, or produces a plausible-sounding response with no grounding in the visual content. Every one of those outcomes corrupts the score. A confidence-calibration curve built on responses that never saw the image is measuring noise. The eval produces numbers, and the numbers are meaningless — which is worse than no numbers, because someone will read them.

That is why capability verification is the divergence point between the naive and the expert approach. The naive path treats the advertised capability list as ground truth and shortlists on reputation. The expert path checks the model’s real modality scope against the buyer’s prompt distribution before any evaluation runs. This is the same discipline that separates a workload evaluation from a leaderboard number: the published figure describes the model’s behaviour on the benchmark’s inputs, not on yours.

The modality gate: a screening check that runs before scoring

The cleanest way to enforce this is a hard capability gate at the candidate-screening step, before any measured error-rate or confidence-calibration work begins. The gate is binary: does the model’s supported input and output modality set cover every modality present in the task’s prompt distribution? If not, the model fails screening and never reaches the calibration stage.

Modality-scope screening rubric

Run this per candidate model, before building any eval harness:

Check	Question	Pass condition
Input modalities	What input types does the task’s prompt distribution contain?	Enumerate: text, image, audio, structured tables
Model input contract	What input types does the model officially accept?	Confirmed against the model’s documented input path, not reputation
Coverage	Does the model’s input set cover every task input type?	No task modality is unsupported
Output modalities	What output types does the workload consume downstream?	Model output type matches consumer expectation
Gate result	Any uncovered modality?	Pass only if coverage is complete; otherwise fail screening

For DeepSeek-R1 against a workload that includes screenshots, the coverage check fails at the first image input. That is a clean, cheap rejection — recorded in one line, costing no harness engineering. Against a pure text-reasoning workload, DeepSeek-R1 passes the gate and earns its place in the measured stage, where its reasoning strength is exactly what you want to calibrate.

Recording the gate result is not bookkeeping for its own sake. In a procurement-evidence context, the screening record is what lets a reviewer later confirm that a text-only model was never scored against a multimodal task — the audit answer to “why wasn’t this candidate evaluated on the image portion?” The modality-scope check belongs in the eval pack’s candidate-screening step, one recorded decision per model, so the shortlist filter is defensible rather than remembered. Our approach to AI governance and trust treats this candidate screening as the first documented step of the evidence trail, not an informal pre-filter.

What if the workload genuinely needs both text and images?

Many real workloads are mixed. A moderation or document-processing task might need strong text reasoning and image understanding. The mistake is treating that as a single-model problem and hoping one model covers both.

The disciplined move is to decompose the prompt distribution by modality first, then shortlist each modality’s candidate pool separately. Text-reasoning-heavy prompts go to a pool where DeepSeek-R1 is a legitimate candidate. Image-bearing prompts go to a pool of vision-language models. Only after each pool passes its modality gate do you run measured evaluation — error rates, confidence calibration, latency — on the candidates that survived. The confidence and error-rate work described in our note on reading AI confidence scores in an LLM evaluation is only meaningful once the modality gate has already been cleared; calibrating a score on inputs the model cannot process produces a number with no referent.

This ordering — capability gates before calibration measurement — is the same sequencing LynxBenchAI applies when it separates what a system can do from how well it does it. A model that structurally cannot accept an input type is filtered by a hard gate; only the survivors reach the measurement that ranks them. For DeepSeek-R1 specifically, its documented reasoning behaviour is worth understanding on its own terms, which is what our breakdown of DeepSeek-R1 benchmarks and reasoning evals covers — but no reasoning score changes the fact that the model’s input path is text.

FAQ

Is DeepSeek-R1 multimodal?

No. DeepSeek-R1 is a text-input, text-output reasoning model. It does not carry an image encoder in its supported input path, so feeding it image inputs is not a supported way to use the model. If your task includes images, DeepSeek-R1 cannot serve that portion of the workload.

What input and output modalities does DeepSeek-R1 actually support, and where does its reasoning focus sit?

It accepts text as input and produces text as output. Its distinctive strength is long-form chain-of-thought reasoning over that text — working through multi-step problems and showing intermediate steps. That reasoning focus is what earns it shortlist attention, but it does not extend to visual input.

Why does a model’s modality scope have to be verified before running an LLM evaluation rather than assumed from its reputation?

Because reputation travels faster than specification: a model known for reasoning gets assumed to be generally capable, including at modalities it never supported. An evaluation assumes the model can accept the required inputs; if it cannot, the eval is not just inaccurate but undefined. Verifying scope first turns a costly late discovery into a cheap up-front filter.

What happens to a procurement-grade eval if a text-only model is mistakenly scored against a task that includes image inputs?

The harness sends image-bearing prompts to a model that cannot process them, so the model rejects the input, ignores the image and answers from text alone, or produces an ungrounded response. Every outcome corrupts the score, and a confidence-calibration curve built on those responses is measuring noise. The eval produces numbers that are meaningless — worse than no numbers, because someone will act on them.

How should a modality-scope check be recorded as a capability gate inside the evaluation pack’s candidate-screening step?

As a binary, per-model screening decision recorded before any harness is built: enumerate the task’s input modalities, confirm the model’s documented input contract, and record pass only if coverage is complete. The one-line record is what later lets a reviewer confirm a text-only model was never scored against a multimodal task, making the shortlist filter defensible rather than remembered.

If a workload needs both text reasoning and image understanding, how do you shortlist models by modality before measuring confidence and error rates?

Decompose the prompt distribution by modality first, then shortlist each modality’s candidate pool separately — text-reasoning prompts to a text-model pool, image-bearing prompts to a vision-language pool. Only candidates that pass their modality gate proceed to measured evaluation. This keeps calibration and error-rate work concentrated on models that can actually process the inputs.

Modality mismatch is the cheapest shortfall to catch and the most expensive to miss. The question worth asking before any leaderboard rank enters the conversation is simply: which of the inputs my task actually contains can this model accept — and have I recorded that answer, or am I assuming it?