Models.dev: A Community-Maintained Registry of AI Model Metadata, Pricing, and Provider Endpoints

The Problem: Fragmented Model Information Across Providers

The data lives in TOML files organized by provider and model. The separation is deliberate. A model-only file under models/ holds facts that do not depend on where the model runs, such as release date, knowledge cutoff, whether it supports reasoning or tool calling, and its default token limits. A provider file under providers/ holds serving details like cost per token, cache read pricing, and provider-specific context overrides. This split avoids duplicating the same model facts across every provider that serves it. The README gives an example where models/openai/gpt-5.toml defines the underlying GPT-5 metadata, while providers/openai/models/gpt-5.toml adds OpenAI-specific pricing and limits. The generation process merges these two layers, and provider fields win when they conflict. That rule is simple, but it means a provider can silently override a model-level fact without changing the base record, which is both a feature and a potential source of drift.

The API: Three JSON Endpoints and SVG Logos

The project exposes its data through a straightforward HTTP API. The primary endpoint is https://models.dev/api.json, which combines provider and model information; specialized model types are omitted unless requested with the type parameter. A second endpoint, https://models.dev/models.json, returns provider-agnostic model metadata only, for facts about the model itself independent of where it is served. A third endpoint, https://models.dev/catalog.json, returns both provider endpoints and model-only metadata in a single response. Provider logos are available as SVG files at https://models.dev/logos/{provider}.svg, where {provider} is the Provider ID such as anthropic or openai. If a logo is missing, a default is served instead. The API is read-only and requires no authentication, which makes it easy to pull into scripts or CI pipelines.

Contribution Workflow: TOML Files and base_model Inheritance

The key mechanism for avoiding duplication is the base_model field. A provider file can set base_model to a model-only ID, such as openai/gpt-5, and then specify only provider-specific fields like cost and reasoning options. The README states that after base_model, you should write only fields that differ from the base, and you must not restate the base's name, description, dates, modalities, limit, etc. unless this host actually differs. Plain tables like [limit], [modalities] and [capabilities] deep-merge, while arrays and primitives replace. There is also an optional base_model_omit field that removes inherited metadata fields after local overrides are merged, using dot-path strings such as base_model_omit = ["limit.input"]. This inheritance model is powerful but introduces a learning curve. Contributors must understand which fields are provider-specific and which are model-level, and mistakes can lead to unintended overrides or missing data.

Running It Locally: No Install Instructions Provided

The README focuses entirely on the hosted API and contribution workflow. The repository is written in TypeScript, and the default branch is dev, and the README says `bun validate` rejects model files without `schema = 2`. The only way to interact with the data is through the public endpoints or by editing TOML files directly in the repo. To verify a change locally, package.json defines a test script (bun test) and a validate script.

Limitations and Failure Modes

The project is also wrong for certain use cases. If you need a real-time source of truth for pricing that updates automatically when providers change their rates, this database will not give you that. If you need detailed benchmark results with full methodology, the TOML schema includes a benchmarks array with name, score, metric, and source. Finally, the API returns the entire database as a single JSON file, which could be large and unwieldy for clients that only need one model. The documented type query parameter filters by model type, and models.json and catalog.json are separate endpoints, but there is no per-model filter shown.

Alternatives: Provider-Specific SDKs and Model Registries

The main alternative is to skip a central database entirely and use the official SDKs and documentation from each provider. The AI SDK itself provides typed access to models through packages like @ai-sdk/openai or @ai-sdk/anthropic. This approach gives you tighter integration and guaranteed consistency with the provider's own API, but it fragments across providers and requires you to manage multiple dependencies. Another alternative is a model registry like Hugging Face's model hub, which hosts model weights, and metadata, but it is not focused on serving details like token costs or context overrides per provider. Models.dev's differentiator is the explicit separation between model facts and provider serving details, plus the base_model inheritance mechanism that reduces duplication. That design is genuinely useful if you work across many providers, but it comes with the maintenance burden of a community-run dataset. For a single-provider project, the extra layer is unnecessary complexity.

Maintenance and License Implications

The project is licensed under MIT, which means you can use, modify, and redistribute the code and data freely, provided you include the original copyright notice. The data itself is stored as TOML files, so you can fork the repository and maintain your own private copy if you need stricter control over freshness. The repository license is MIT. The maintenance cost is real. Because the project depends on community contributions, you must either accept periodic gaps or contribute updates yourself. The base_model inheritance model reduces duplication but adds complexity, and the README warns against restating fields, which means contributors must understand the merge rules. The repository publishes no GitHub releases, and its last push was on 2026-11-02. Before adopting it, check the dev branch for recent commits and verify that the models you rely on are present and accurate.

Editorial conclusion

Adopt Models.dev if you need a centralized, community-maintained reference for AI model facts and provider-specific pricing, especially if you already use the AI SDK and want a consistent Model ID across tools. Do not adopt it if you require guaranteed accuracy or real-time updates, since the data depends on volunteer contributions and the repository publishes no GitHub releases. Before relying on it in production, verify that the specific models and providers you use are present, check the last commit date on the dev branch, and confirm that the TOML entries match the official documentation from each provider.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository