Context length and modalities: the two facts buyers filter on

Hard constraints come before preferences

Context length and modalities are the facts buyers filter on before anything else, because each is a hard limit. If a contract runs longer than the context, or the task needs an image read and the model takes only text, nothing else on the page matters. State the context length as a number of tokens, the maximum output as a separate number, and the input and output types as plain lists. Anything vaguer gets the model excluded from a filter it might have passed.

The two facts go wrong in different ways. Context can be stated in the wrong unit, or as one number covering two limits. Modalities can be implied rather than stated.

A third fact sits close to both: whether the model can return structured output, such as JSON that follows a schema. A buyer building a pipeline filters on it in the same way, and should not have to discover it in testing.

Tokens are the unit, and only tokens

A token is a chunk of text, roughly four characters of English. Text is priced per million tokens and API limits are commonly set in tokens, so the context length has to be in tokens too. Pages that say a model reads a few hundred pages or a whole novel are giving a translation of the number, and the buyer has to translate it back, with your tokenizer, which they do not have yet.

Write the exact figure. A context described as 128K might be 128,000 tokens or 131,072, and somebody building a pipeline that packs the window full needs to know which. The rounded figure is fine in a headline as long as the exact one sits underneath it.

Different tokenizers split the same text differently, so a window of a given size holds more English under one model than under another. That is a reason to name the tokenizer as well, not a reason to switch units.

Input window and output limit are two numbers

The context window is usually shared between what goes in and what comes out, and there is usually a separate cap on output. A buyer generating long reports cares about the cap far more than the window. A page that states only the window lets them assume the model can write as much as it can read, and that may not be true.

Hosts complicate this. A seller serving your weights may run them with a shorter window than the model supports, for example to fit more requests on each GPU. Your page cannot fix that, but stating the model's own maximum clearly gives buyers something to check a host's figure against. The token price table lists 750 input-price listings, and the same model can appear with different limits at different sellers.

Longer context is not free to use either. Every token in the window is billed as input, so run the LLM cost calculator at the length a buyer actually plans to send, not the maximum.

Modalities as a list, not a mood

Multimodal is a word, not a specification. Buyers want two short lists: what the model accepts (text, images, audio, video, documents as files) and what it returns (text, structured output, images, audio). Add limits where they exist, such as the number of images per request or the longest audio clip, because those are what a buyer hits in testing.

Say what is excluded too. If images are accepted but charts and handwriting are weak, or audio is accepted only as a transcript produced elsewhere, a sentence saying so saves the buyer an afternoon and saves you a disappointed one.

Use the words other pages use: image input, audio input, text output. A maker that invents a name for its modality support forces every directory and comparison to guess which standard field it maps to, and a guess can land in the wrong column.

A long window costs the host memory

Context length is also a hardware fact for anyone serving the model. The key-value cache grows with the length of each request, so a host that allows the full window on every request fits fewer requests on each GPU. That is one plausible reason a seller caps the window below the model's own figure, and one way the same model ends up offered with different limits at different prices.

A maker that publishes weights can help by stating how the cache grows for its architecture, with the settings it measured at. Without that, every host works it out separately, and buyers see limits that look arbitrary because nobody wrote down where they came from.

What a missing field costs

On the large language model listings a fact we could not find is shown as no answer on record. A buyer filtering for a context of at least a given length, or for image input, will not see a model whose field is empty, because a filter cannot include what it cannot read. The model is not ranked low. It is absent.

The same is true of a search or an assistant answering a question such as which models read images. They work from stated facts. The cheapest fix in this whole subject is a short block near the top of the model page with both numbers and both lists, which also needs the parameter count beside it to be useful for sizing.

A missing field also invites someone else to fill it. Hosts, aggregators and summaries may state a context length for your model whether or not you do, and if your page is silent the figure they choose becomes the one buyers repeat.