Reasoning, coding, vision, and multimodal models
Distinguish reasoning, coding, vision, and multimodal model categories using verified capability families and disclosed classification limits.
Reasoning, coding, vision, and multimodal models
Model modalities describe the types of work a model can accept or produce. Use this page to narrow candidates before comparing cost, quality, latency, or provider status. Ethen’s verified capability-family vocabulary is broader than a simple text-versus-image split, but a family label does not prove every input/output combination or route supports the same behavior.
Reasoning models
The reasoning family identifies models classified for reasoning-oriented work. That can be relevant to multi-step analysis, planning, evaluation, or structured problem solving, but the label does not guarantee correctness or a particular internal method.
Evaluate reasoning candidates through task-relevant evidence:
- benchmarks that resemble the workload;
- quality flags and source coverage;
- context and output requirements;
- latency and cost implications;
- representative tests with reviewable answers.
Some text models may also reason without being placed in the reasoning family, and a reasoning label does not replace verification. Use the category to discover candidates, then inspect the record and profile.
Long-context classification can be relevant to reasoning over larger inputs, but context capacity and reasoning quality are different properties.
Reasoning is a verified capability family and also appears as a Model Intelligence category derived partly from model names.
Use reasoning as an indicator that a model is intended for more complex multi-step tasks, but do not assume a specific hidden reasoning method, accuracy level, or tool capability. Compare evidence and runtime status.
Coding models
The code family helps find models oriented toward programming tasks. A coding task may include explanation, generation, transformation, debugging, or review, but Batch 01 does not define a universal coding-agent runtime.
Before selecting a coding model, define the environment and expected artifact. A model that produces plausible code still requires review, testing, and integration through the appropriate product workflow.
Useful checks include:
- language and framework relevance;
- amount of repository context required;
- expected output size;
- need for tool use or execution;
- quality of explanations and diffs;
- current provider and runtime status.
A model capability does not authorize shell commands, repository writes, or deployment. Those actions belong to tool, permission, approval, and execution boundaries.
Code is a verified capability family, and coding is also a derived Model Intelligence category.
Select coding candidates for code-oriented tasks, then verify language fit, context, output limits, latency, and current gateway status. The category is not proof of repository access, tool execution, or safe code.
Vision models
Vision-oriented work uses image input, image output, or both. The catalog vocabulary includes image, while normalized categories may also derive vision-oriented groupings.
Do not treat “vision” as a complete contract. A model may analyze images without generating them, generate images without accepting arbitrary visual input, or require a specific route. Check the model record, capability tags, provider, and requested modality.
For image analysis, document the type of source image and expected text output. For image generation, verify that the owning product and provider support generation rather than assuming any image-classified model can be used through every surface.
Privacy and rights questions about image content require separate review; modality metadata does not answer them.
Image is a verified Model Library family, while vision is a Model Intelligence category derived from names such as vision, visual, VL, VLM, or multimodal.
Check whether the current route supports the intended image input and text or image output. A research classification does not establish executable modality support.
Multimodal models
A multimodal model can work across more than one type of input or output, but the supported combinations matter. Text plus image input, text plus audio, realtime speech, transcription, video, and image generation are distinct paths.
The verified capability families relevant to multimodal work include:
| Family | Broad purpose | Required follow-up |
|---|---|---|
image | Image-related input or output | Confirm analysis versus generation and route support |
video | Video-oriented work | Verify accepted input, output, and product surface |
realtime | Low-latency interactive behavior | Confirm provider, modality, and runtime readiness |
speech | Speech-oriented generation or interaction | Verify direction and audio format support |
transcription | Convert speech or audio to text | Confirm input support and provider route |
text | General text work | Check whether non-text inputs are actually supported |
unknown | Classification is unresolved | Inspect notes and avoid capability assumptions |
Embedding and rerank are also specialized families. They support representation and ranking tasks rather than ordinary conversational output.
Multimodal describes models intended to work across more than one input or output type. The current catalog represents families separately, including image, video, speech, transcription, realtime, and text-related categories.
Do not assume a multimodal label means all modalities are accepted in one endpoint or workflow. Consult the owning product implementation for supported combinations.
Tradeoffs
Modality affects more than model quality.
Context shape. Images, audio, video, and long text have different capacity and preprocessing requirements.
Output review. Code can be tested; text can be checked against sources; media may require visual or audio review; embeddings and reranking require evaluation against retrieval outcomes.
Latency and throughput. Realtime interaction has different performance needs from batch transcription or image generation.
Cost. Pricing units may vary by provider and modality. Batch 01 does not define those units beyond the fields represented in the catalog.
Provider support. A model family can be represented while the current provider path reports unsupported modality or missing key.
Product surface. Model Library and Model Intelligence can describe a capability even when the execution product route is unverified in this batch.
Evidence quality. Derived categories and missing fields can weaken confidence in the classification.
Modality affects input preparation, context use, latency, cost, output review, and provider support.
A model with broader capability may not be the best choice for a narrow task. Missing metadata and keyword-derived categories should lower confidence until representative evidence is available.
Artifact continuity
At a modality boundary, define the artifact passed to the next stage. A transcript should retain its audio reference; an image analysis should identify the source image; generated code should remain tied to the prompt and repository context; an embedding result should remain tied to the source text and model identity.
Continuity makes a multistage workflow reviewable. Without it, a later model can produce a polished answer from an intermediate artifact whose origin or quality is no longer visible.
Selection guidance
Follow this modality-first sequence:
- Define the exact input and output types.
- Select the closest verified capability family.
- Inspect capability tags, notes, and profile data.
- Confirm provider and status.
- Check context, output, latency, throughput, and price fields when present.
- Verify the product route that owns execution.
- Test with representative, non-sensitive material.
- Record unsupported combinations rather than generalizing from one successful case.
Use unknown as an explicit uncertainty state. Do not force an unclassified model into text or another familiar family.
When a task spans modalities, verify every stage. A workflow that transcribes audio, reasons over text, and generates speech may require several models or tools. One “multimodal” label is not sufficient evidence for the complete chain.
Use the task’s actual input and output as the first filter, then compare quality evidence, context, limits, speed, cost, provider status, and source confidence.
Treat category membership as a starting point. Confirm the exact model ID and runnable status before moving from research to use.
Exact input-output contracts
Write the task as an input-output pair before choosing a family. “Use vision” is ambiguous. “Accept one image and return a text description grounded in visible content” is testable. “Generate an image from text” requires a different route. “Transcribe speech to text” differs from “generate speech from text” and from realtime conversation.
For each side of the pair, record format, size or duration constraints when verified, expected artifact, and review method. Batch 01 does not supply universal media limits, so leave those fields unresolved until the product guide defines them.
Specialized families
embedding and rerank should not be evaluated like conversational models. An embedding model produces representations used by another system, while a reranker orders candidates. Their quality must be assessed through retrieval or ranking outcomes rather than prose style.
realtime also describes an interaction requirement rather than one content type. Confirm whether the route supports the needed audio, text, event, or streaming behavior. A realtime classification does not guarantee the same latency or feature set across providers.
Multistage modality pipelines
A task can move through several modality boundaries. Consider audio transcription followed by text reasoning and speech generation. Each stage needs its own model or tool identity, provider status, input/output contract, and evidence. The intermediate transcript becomes an artifact and context source for the next stage.
An error in one stage can contaminate the rest. Review intermediate artifacts before execution or publication, especially when the later stage sounds confident. One multimodal model may combine stages, but the supported combinations still need direct verification.
Modality fallback
Fallback must preserve the required input and output. A text model cannot replace a vision model merely because it can reason about a user-provided caption. A hosted speech route may not be an acceptable fallback for a task intended to remain local. A video-capable label does not prove support for the desired output format.
Define acceptable degradation in advance. The workflow may pause, ask the user for a text description, switch to another verified route, or produce a proposal without execution. The selected behavior should be visible.
Review methods by modality
Text and reasoning outputs can be checked against supplied sources and constraints. Code requires review and testing. Image or video output needs visual inspection and may require source or rights review. Transcription needs comparison against the audio. Speech output needs intelligibility and content review. Embedding and rerank outputs need task-level evaluation.
A model’s family helps choose the review method; it never removes the need for review.