Model capabilities
What to verify before you rely on a model for images, tools, long context, or media.
Pick a model for what the request needs, then verify the exact provider and model. A family name is not a promise.
#Before you send
| Need | Check |
|---|---|
| Images | The model is marked as able to see images |
| Reasoning control | The picker shows a strength for it |
| Tool use | The provider and model support the loaded tool schema |
| Long context | The provider's limit fits the thread and attachments |
| Media | Atoi lists the model under image, video, audio, or 3D |
| Structured output | The provider keeps the schema and reports errors |
Atoi refuses an image attachment when the selected model cannot see images. Accepting a PDF or JSON does not mean the model will reason well about it.
#Surface support is separate
A model can support something a surface has not shipped yet, and a surface can also lag behind a model. Guides mark surface gaps as Preview.
#Judge on the task
Run a representative request, keep the provider-qualified ID, note the settings, and look at the result. For consequential work the receipt records which model ran. Start with one default and add models only when repeated evidence earns them.
See The layers and Providers.
Was this useful?