Official AI Model Catalogs: Provider Links and Verification Guide

AI model names, endpoints, prices, and availability change quickly. A static page cannot reliably list every AI company and every current release. This curated directory points readers to first-party model catalogs and explains which details to verify before choosing a model. It covers major providers with public model documentation; it is not an exhaustive list of labs or products.

Last checked October 10, 2026. This refresh expands the developer directory, adds cloud-host and API catalog links, and separates text generation from decision, image, and other model types. Entries point to provider-maintained sources rather than guessed “latest” model names.

These services host or route models from multiple developers. Their catalog membership is evidence of a serving route, not evidence that the service trained the underlying model. Compare the requested route with the original model card and your account’s enabled deployments.

OpenRouter’s default Models API returns text-output models. Use output_modalities=all for all output types or output_modalities=decisions for the decision category. A text-only query cannot establish that an omitted image, embedding, or decision model has been retired. Our decision-model directory records the category’s exact IDs and current pricing, including free variants and moving aliases.

A model family can have multiple snapshots and model sizes. A provider API may expose a different ID from a model's public weights, and a hosting platform may route the same ID to a specific checkpoint or quantization. Aggregators such as OpenRouter are useful for model discovery and switching, but the upstream provider still determines the model and its data terms. Check the selected route instead of assuming a catalog label fully describes it.

1. Verify the release. Find a dated announcement or model card from the model developer. Do not treat a provider catalog entry or an anonymous preview name as proof of a public release.

2. Confirm the exact model ID and status. Check whether the entry is stable, preview, retired, or a compatibility alias to a newer model.

3. Check limits and inputs. Context size, output caps, supported modalities, tool calling, and reasoning options vary by model and endpoint.

4. Calculate cost for your use. Read input, output, cache, batch, tool, and rate-limit details. Promotions and free quotas often differ between models and accounts.

5. Review deployment and license. Hosted APIs, open weights, and quantized checkpoints have different privacy, hardware, and redistribution terms.

6. Treat benchmark numbers as scoped evidence. Record who ran the evaluation, the model snapshot, harness, tools, prompt, number of trials, and uncertainty. Vendor results can guide what to test; they do not establish the winner for every workload.

Choose a few models whose published access terms fit your project, then evaluate them on the same held-out tasks. Store the tested model ID and date with results. Recheck the provider catalog before a migration or a production launch, and rerun the comparison when a model version, pricing tier, prompt, or tool harness changes.

A directory is most useful when it helps readers verify claims and make a decision. These official catalogs provide a maintained starting point; the workload-specific test determines which model belongs in your application.