Narrow the published model catalog to candidates that meet documented requirements. Use the results to design an evaluation, with unknown attributes kept visible.

Find models

Interactive tool

Find a model that fits

Your text and estimates stay in this browser. No API requests are sent to model providers.

Loading verified model records…

Start with requirements that can be checked

Write down the input and output types the application requires, then decide which constraints are mandatory. A model that cannot accept the required input should not survive the shortlist merely because its text rate looks attractive. Keep cost, context and operating status as separate checks so a large value in one column does not conceal a failed requirement in another.

Apply the provider and modality filters before fine-tuning price thresholds. This gives you a more understandable result set and makes an unexpectedly empty result easier to investigate. If the query returns no candidates, relax one condition at a time and record which requirement caused the exclusion. Do not silently convert a mandatory capability into a preference just to obtain a recommendation.

Official model catalogs describe capabilities and identifiers, while pricing pages define the charge categories used to compare eligible candidates. Official documentation.

The finder lists the published records available to this reference. It is not a claim that every model ever announced is represented or that every published model is available in your account. Follow the model source when access, release state or a missing attribute matters to the decision.

Read price and context filters carefully

Price filters apply to the recorded category and unit. Inspect the row before comparing an ordinary token rate with a qualified tier or a different billing unit. A threshold on input price does not constrain output cost, and neither threshold captures every possible hosted-feature charge. Use filters to narrow the search, then evaluate the full request shape.

A context filter checks documented capacity. It does not establish that a model will reliably find every relevant fact in a long document or that a request can use the full capacity while generating the output you want. Test retrieval, ordering and answer grounding on the actual application fixture. Capacity and task quality belong in different columns of your decision record.

Unknown data should remain unknown. If an important field lacks sufficient evidence, inspect the source or exclude the candidate until the uncertainty is resolved. Treating a blank as zero can distort a price sort; treating a blank capability as supported can produce a shortlist that fails on the first real request.

Sort and export a reproducible shortlist

Sort the relevant columns to inspect extremes and ties, then review the individual model pages. Preserve the exact identifier and host rather than exporting only a display name. Similar names can refer to different routes or versions, and a compatible host may apply its own access and billing conditions.

Export the filtered table as CSV when you need an evaluation worksheet. Add your own columns for test fixture, accepted result, measured usage and unresolved questions. Keep published data separate from observed outcomes. That makes it possible to refresh the reference columns later without overwriting the application evidence.

Open the comparison tool for a closer side-by-side view, and use the cost calculator with the same workload assumptions for the surviving candidates.

Move from catalog fit to application evidence

Choose a small group of candidates whose documented attributes fit the task. Run the same safe fixtures and define acceptance before inspecting outputs. Include the cases that are costly to get wrong, such as missing evidence, ambiguous instructions or invalid structured output. A useful model shortlist reduces evaluation work; it does not replace that work.

Revisit the selection when a candidate changes status or the application adds a capability. Keep a dated record of why a model was selected, which fields were verified and which behavior was observed. The model finder can help detect a changed reference attribute, while your regression fixtures establish whether the application still meets its own requirements.

Last verified · Source ↗

Frequently asked questions

Does this list every announced model?
It lists the published records available to the reference. Missing or insufficiently documented records must not be presented as complete.
Does a context filter measure answer quality?
No. It filters documented capacity; your application evaluation measures whether the output is useful and grounded.
Why is input price insufficient for a decision?
Output, caching, processing mode and other applicable charge categories can change the workload total.
What should I do with an unknown field?
Keep the uncertainty visible and investigate the official source before relying on the attribute.
What belongs in an exported evaluation sheet?
Exact model and host identities, source dates, fixtures, acceptance results, measured usage and unresolved questions.
Does appearing in the catalog guarantee account access?
No. Confirm the provider’s actual access conditions in the account that will send the request.

Sources

Last verified · Source ↗