AI Capability Search

What Is AI Capability Search?

AI Capability Search is a free search engine for large language models, filtered by what a model can actually do. Instead of browsing provider websites and reading model cards, you tick the capabilities you need, such as vision, tool calling or JSON output, and get back a list of models that support them, with price and context size next to each one.

The tool searches the live catalog published at models.dev, which collects thousands of models from OpenAI, Anthropic, Google, DeepSeek, Meta, Mistral, Alibaba, xAI, Amazon, Cohere and many other providers. Every row shows the model name, the provider, its context window, and its input and output price in USD per 1 million tokens, sorted so the cheapest input price is at the top.

It answers a very specific question: which model can do this job, and what does it cost? That question comes up constantly when you are building a document reader, a voice assistant, a structured-data pipeline or an agent that calls tools.

Why Use It — and Who It Is For

Capability is a harder filter than price or brand. A model can be cheap and still useless for your task because it cannot read images, or because it does not support structured output. Common situations where this tool saves real time:

• Building a document pipeline and needing models that read PDFs or images rather than plain text.
• Creating an agent that must call tools or functions and return reliable JSON.
• Prototyping a voice product and looking for models that accept and produce audio.
• Comparing open-weight models for a private deployment on a budget.
• Replacing a discontinued model and wanting every alternative that supports the same kind of input.
• Shortlisting options before you take the next step of checking benchmarks, latency and rate limits.

It is built for developers, technical founders, students and anyone who compares models often enough to want a filter instead of a bookmark folder.

How This Tool Works

When the page opens, the browser makes two calls to our backend. One loads the capability list and the match modes. The other loads the provider list, which also reports how fresh the pricing data is. Both come from the same catalog that our server downloads from models.dev, caches for 24 hours and keeps a stored copy of, so the tool keeps working during an upstream outage. Responses carry a last update time and a stale flag, and the page shows a warning if pricing data could not be loaded at all.

When you press Search Models (or hit Enter in the keyword box), the page sends your selected capabilities, the match mode, the keyword and the provider to the search endpoint. The server then walks every provider and model in the catalog and applies these rules:

1. Capability check. In match all (AND) mode the model must support every selected capability. In match any (OR) mode one is enough. If you selected nothing, every model matches.
2. Keyword check. Your keyword is matched against the model id, the model name and the provider name, case insensitively.
3. Provider check. If you picked a provider, models from everyone else are dropped.
4. Sorting. Matches are sorted by input price ascending, cheapest first. Models with no published input price sink to the end, and ties are broken alphabetically by model id.
5. Slicing. The first 100 matches are returned for the table, along with the full match count so the page can show how many results it is displaying out of the total.

How a capability is detected depends on the signal behind it. Vision comes from the image modality, OCR and PDF reading from the pdf modality, audio and video from their own modalities, tool calling and function calling from the tool call flag, and JSON output from the structured output flag. These are structural signals published by the catalog and are reliable.

Three chips are marked with a small est. badge: image generation, search and code. The catalog does not publish a dedicated flag for them, so the server estimates them from words in the model description. Treat those three as a starting point and confirm on the model card before you commit.

Key Features

• Ten capability filters - vision, image generation, OCR and PDF, tool calling, function calling, JSON output, audio, video, search and code, each with an icon and its source explained in a tooltip.
• Two match modes - match all (AND) for strict requirements, match any (OR) for broad browsing.
• Keyword box - filters by model id, model name or provider, for example gpt, claude or qwen.
• Provider dropdown - every provider in the catalog with its model count, plus an all providers option.
• Result table - model name, provider and id, capability badges, context window, input price and output price per 1 million tokens.
• Cheapest first by default - sorted by input price, with unpublished prices placed last instead of treated as zero.
• Match counter - shows how many rows you are seeing out of how many models matched in total.
• Deprecated badge - discontinued models are flagged in red so you do not build on a dead model.
• Estimated chips - the est. badge tells you which capabilities are inferred rather than published.
• Freshness data - every response carries the last update time and a stale flag, and the page warns if pricing data could not be loaded.

How to Use — Step by Step

1. Wait a moment for the capability chips and the provider dropdown to load from the catalog.
2. Click the capability chips you need. Selected chips are highlighted. Hover a chip to see where its signal comes from.
3. Choose a Match mode. Leave it on Match all (AND) if a model must support everything you ticked, or switch to Match any (OR) to browse more broadly.
4. Optional: type a Keyword such as gpt, claude, qwen or llama to focus on a family or provider.
5. Optional: choose a Provider to search inside one vendor only.
6. Click Search Models or press Enter. The button shows a spinner and the inputs are disabled while the catalog is searched.
7. Read the table: badges show which capabilities matched, the context column shows the window size in tokens (n/a when the provider does not publish it), and the price columns are USD per 1 million tokens.
8. If the result set is too wide, add one more capability to move to AND mode logic, or add a keyword, and search again.

Limits and Rules

• Search requests are rate limited to 120 per minute, which is more than enough for interactive use.
• The table shows the first 100 matches per search. The counter also shows the total match count, so refine with a keyword or provider when the list is wider than you need.
• The capability list is fixed to the ten supported keys. An unknown key is rejected with a validation error rather than ignored.
• Image generation, search and code are estimated from descriptions and are not guaranteed capabilities. Vision, OCR, audio, video, tool calling, function calling and JSON output come from published catalog flags.
• Prices are USD per 1 million tokens and refresh every 24 hours with the catalog.
• An empty capability selection returns the whole catalog, which is useful for browsing but rarely what you want.
• No login, no API key and no captcha are required, and your search terms are only used to filter the catalog.

When to Use It — and When Not To

Use it when you are starting a project and need a shortlist of models that support a specific input type or output format, when you are replacing a model that lost support for something, when you are comparing prices across providers for one capability, or when a client asks which cheap model can read PDFs and still return JSON.

Do not treat it as a benchmark. Capability flags tell you whether a feature is supported, not how well it works. Image generation and code results are keyword estimates. Always follow up with a hands on test, the provider documentation, and a look at latency, rate limits and data retention policies before you ship. For deep cost modelling, run the numbers through a cost calculator using your real token volumes.

Frequently Asked Questions