Match the model to the job, by capability
Picking a model on benchmarks alone misses the practical question: does it actually do the thing you need? This matrix maps leading LLMs to concrete capabilities — code, vision, audio, function calling, web search, long context and deep reasoning — so you can filter to exactly the models that fit your requirements.
How it works
Tick the capabilities your project depends on and the matrix applies an AND filter, showing only models that support every one. A checkmark grid then lets you see the full capability spread of the qualifying models at a glance, so you can spot a model that covers your must-haves and a few nice-to-haves too. An optional provider filter narrows the set further when you are committed to a vendor.
Reading the capabilities
- Code: strong code generation and editing — table stakes for most current flagships.
- Vision / Audio: multimodal input. Vision means image understanding; audio means speech in (or out, depending on the API surface).
- Function calling: structured tool use — the backbone of agents and any app that fetches live data or takes actions.
- Web search: built-in retrieval of current information; availability often depends on the API tier, so confirm in provider docs.
- Long context: very large context windows for whole documents or codebases.
- Deep reasoning: dedicated step-by-step problem solving for hard math and logic.
Capability vs. benchmark: why both matter
Benchmarks like MMLU, HumanEval, and MATH measure a model’s knowledge and reasoning on standardised test sets. They are useful for comparing models on the same task type, but they don’t answer capability questions:
A model that scores very highly on coding benchmarks may not support function calling, which means it can write code about an API but cannot actually call one during inference. A model with excellent vision benchmark performance may expose image input only in specific API tiers or products, not the raw API you are integrating with.
Conversely, a model that supports web search natively has a major practical advantage for knowledge-work applications regardless of its static benchmark scores, because it has access to current information. That capability doesn’t show up on most benchmark leaderboards.
The right model selection process is: identify the capabilities your application genuinely requires, confirm they are available at the API tier you intend to use, then use benchmarks to break ties between models that satisfy the capability filter.
A note on capability drift
Capability support for LLM APIs changes frequently. Models are updated, new versions are released, features are added to or removed from certain API tiers, and pricing changes alter which options are economically viable. The matrix represents the landscape at the time of last update; verify the current state in each provider’s documentation before committing to a model for a production application.
Capability support changes fast and can hinge on the specific API tier, so treat this as a shortlist generator and verify the details in each provider’s documentation before you build.