Searching and filtering models
Search and narrow Model Library records by text, capability, provider, status, sorting, categories, and verified URL state.
Searching and filtering models
The Model Library explorer supports a reproducible set of search, filter, sort, category, and column controls. Use this page when a model list is too broad, when you need to share a view with another reviewer, or when results do not match an earlier session. The controls operate on current catalog data, so a saved URL preserves query state rather than a permanent snapshot.
Search
Text search is represented by the q URL parameter. Use it for model IDs, names, providers, or other searchable record text exposed by the current explorer.
Search deliberately:
- Start with an exact model ID when you already have one.
- Use a provider name to inspect records associated with that provider.
- Use a distinctive model-family term when several versions are expected.
- Remove the query before concluding that a filter has no matches.
A text match does not establish compatibility. After finding a record, inspect capability, provider, status, context, output, and source evidence.
When sharing a search URL, explain the intended question. A URL containing q can reproduce the query, but the catalog may change after the link is created.
The verified search field matches text built from model ID, provider, display name, capability family, and notes. The query is synchronized to the q URL parameter.
Use specific terms first, such as an exact model ID or provider. A search result still needs status and evidence review; text matching does not imply runtime support.
Search scope
A broad query can match model ID, provider, display name, capability family, or notes represented by the explorer. Inspect why a result matched before treating it as relevant. A provider name in notes, for example, may not mean the selected record uses that provider path.
Filters
The verified filter dimensions include capability family, provider, status, and other exposed attributes. Core URL parameters are family, provider, and status.
| Filter | Use it to answer | Common mistake |
|---|---|---|
| Capability family | Which records are classified for this kind of work? | Assuming classification proves every modality detail |
| Provider | Which records are associated with a particular provider? | Treating provider presence as account access |
| Status | Which records are catalog-only, configured, runnable, unsupported, or missing a key? | Combining different statuses into a simple available/unavailable label |
| Attribute controls | Which records meet an exposed catalog property? | Assuming a missing field means zero or false |
Apply the narrowest required filter first. For an execution task, capability and status usually matter before price or benchmark comparison. For research, provider and profile evidence may matter more.
When no records remain, remove filters one at a time. This identifies whether the conflict comes from capability, provider, status, or the text query.
Capability-family tabs, provider selection, and attribute status filters can be combined. The selected values are synchronized to family, provider, and status URL parameters.
Text includes text, reasoning, long-context, and unknown/general-chat records. The Embed label maps to the internal embedding family. Attribute filters describe catalog truth rather than quality ranking.
Sorting
The inspected implementation verifies sorting by:
- model name;
- provider;
- status;
- context window.
The sort choice is synchronized through sort. Sorting changes order, not eligibility. A model at the top of a context-window sort is not automatically best for long-context work, and a status sort does not replace task-specific testing.
Use name or provider sorting for inventory review. Use status sorting to separate records by operational readiness. Use context-window sorting only when context capacity is a genuine requirement and the field is present.
If a record lacks the sort field, inspect how it appears in the current UI rather than assuming a numeric default. Missing catalog values should remain unknown.
Selectable columns can improve a comparison without changing the underlying records. Show only fields needed for the decision so missing or dynamic values remain visible rather than being lost in a wide table.
Verified sorting options are name, provider, status, and context window, with the selected value synchronized to the sort URL parameter.
Context sorting treats available numeric values as the comparison key, but missing data should still be read as unavailable. Sorting changes order; it does not establish a recommendation.
Categories
Capability-family tabs provide a category-oriented way to browse. Verified families are text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown.
A category is a discovery aid. It should not be interpreted as a complete input/output contract. For example, a multimodal or vision-oriented record may support only particular combinations of text and image. A long-context label does not establish quality at maximum capacity. An unknown family signals that the catalog cannot confidently place the record.
Model Intelligence may also expose category pages derived from normalized data. Those research categories and Model Library capability families may use related language while serving different purposes.
Model Library capability tabs are based on normalized catalog families. Model Intelligence categories are a separate research taxonomy and may use model type or name-based derivation.
Do not assume that the same label has identical derivation across both products. Use Model Library for runtime-oriented families and Model Intelligence for broader comparison views.
Pagination
Pagination controls were not verified in the inspected Model Library explorer. The implementation renders the filtered model list within a scrollable region and maps the filtered records directly into that list.
Do not document page numbers, page-size selectors, next or previous controls, result limits, or pagination URL parameters for this surface. If a later implementation adds pagination, the route and control behavior should be inspected before this section is updated.
For a large result set today:
- narrow by capability, provider, or status;
- add a text query;
- choose the relevant sort;
- reduce visible columns;
- inspect the selected record rather than scanning every row.
This approach improves navigability without claiming a pagination mechanism that is not present in the source.
The inspected Model Library explorer does not expose pagination state, page numbers, next/previous controls, or a verified page size. It maps the entire filtered result set into a vertically scrollable region.
Do not document pagination as available. Narrow large result sets with search and filters. Revisit this section if the implementation later adds explicit pagination or virtualization controls.
Troubleshooting
| Problem | Check | Resolution |
|---|---|---|
| Expected model is absent | Query spelling, provider filter, capability family, and status | Clear controls individually and search the exact ID |
| Shared link returns a different list | Current catalog data and URL parameters | Confirm q, family, provider, status, and sort; note that data is dynamic |
| Model appears under an unexpected category | Catalog classification and capability tags | Treat the family as broad metadata and inspect the record details |
| Price, latency, or context seems to be zero | Whether the field is actually missing | Keep the value unavailable; do not convert absence to zero |
| A record is visible but cannot run | Status, provider configuration, credential, and modality | Follow the status-specific remediation rather than changing search controls |
| List is difficult to scan | Active columns and sort | Show decision-relevant columns and narrow the filters |
| No pagination control exists | Current explorer behavior | Use search and filters; do not infer a hidden page size |
When reporting a search issue, include the URL state, selected model ID, provider, status, and the date of observation. Those details make the result reproducible without treating it as permanent.
If expected models are missing, clear filters one at a time, check the capability tab, provider selection, status filter, search query, and sort.
A model may also be absent because the current catalog snapshot does not contain it. If a record appears but cannot be used, inspect its status: catalog-only, missing-key, unsupported-modality, provider-configured, or runnable.
Reproducing a catalog view
A reproducible report should include the full approved route, active q, family, provider, status, and sort values, selected model ID, and observation date. Also record which columns were visible if the issue involves a missing field.
This captures the user-controlled state without claiming that the underlying catalog is frozen. Another reviewer can open the same parameters, compare current results, and determine whether the difference comes from data updates or control state.
Filter order for common questions
For execution readiness, apply capability family, then status, then provider. For provider inventory, select the provider first and review the status distribution. For long-context research, choose the relevant family or query, sort by context window, and inspect missing values individually. For a known model, search the exact ID before applying broad categories.
The order does not change catalog truth, but it makes contradictions easier to diagnose. A provider filter that removes the intended record should be noticed before a user assumes the model is unavailable everywhere.
Attribute ambiguity
Attribute controls describe fields represented in the catalog. They should not be used as quality labels unless the implementation explicitly defines them that way. If the meaning of an attribute is not clear from the current UI or types, leave it out of procedural guidance and retain a verification note.
When a category or family appears to include unexpected records, inspect the capability tags and notes. Classification may be broad, derived, or unresolved. The unknown family should remain available for records that cannot be classified confidently.