A short checklist for matching a task to model capabilities, then testing a small shortlist.

Start with a task, not a ranking​

Section ID: Blog Post/2p6vjt82j9#start-with-a-task-not-a-ranking

Write down one concrete input and what a useful answer must contain. Reading a screenshot needs different inputs from drafting a short text reply. A model name alone does not tell you whether it fits either job.

Make a capability checklist​

Section ID: Blog Post/2p6vjt82j9#make-a-capability-checklist

• Inputs and outputs: check the modalities the task needs, such as text or images, and the kind of output you expect.
• Context and response size: compare your largest expected prompt with the documented context capacity, leave room for the response, and check any separate output limit.
• Required options: if the workflow needs tool calls or a structured response, verify those specific capabilities instead of assuming every model supports them.
• Access and privacy: check the account and data-handling restrictions that apply to your use case.

Test a small shortlist​

Section ID: Blog Post/2p6vjt82j9#test-a-small-shortlist

Try the same representative cases with each candidate. Include an ambiguous input and a case where the expected output can be checked. Record missing information, format errors and factual mistakes. Choose acceptance criteria before comparing the answers; a fluent response is not enough if it fails the task.

Use model cards as a starting point​

Section ID: Blog Post/2p6vjt82j9#use-model-cards-as-a-starting-point

The Available Models page helps you inspect documented properties. Provider references can report input and output modalities, context capacity and supported parameters. Treat an unknown capability as a question to verify, and confirm access in your intended environment separately. Recheck the source when you change the task or model.

Further reading​

Section ID: Blog Post/2p6vjt82j9#further-reading

1. List all models and their properties — OpenRouter

Document ID: Blog Post/2p6vjt82j9