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, tool calling, or structured output, 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 returns the full database combining provider and model information. 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. The README describes these as distinct options, but it does not explain the exact schema differences beyond that. 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. There is no mention of versioning, rate limits, or caching headers in the README, so consumers should treat the JSON as a changing snapshot rather than a stable contract.

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 anthropic/claude-opus-4-6, 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 same description, structured_output, modalities, or dates. Nested tables like [cost], [limit], or [modalities] require full values if overridden; arrays and primitives replace, while plain objects deep-merge. 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. There are no commands to clone, build, or run the project locally. The repository is written in TypeScript, and the default branch is dev, but the README does not mention a package manager, build script, or development server. This is a notable gap for engineers who want to self-host the API or test changes before submitting a pull request. The only way to interact with the data is through the public endpoints or by editing TOML files directly in the repo. If you want to verify a change locally, you would need to inspect the repository structure and figure out the build process yourself, since the README does not document it. The lack of setup instructions may be acceptable for a data-focused project, but it makes local development harder than it needs to be.

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, but the README does not describe how benchmarks are validated or updated. 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. There is no mention of query parameters or filtering in the README, so consumers must download everything and filter client-side.

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, and those packages include model definitions and pricing at the time of release. 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, metadata, and sometimes pricing, 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. However, the README does not specify a data license separate from the code license, so you should treat the data as covered by the MIT license as well. 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 has no recent releases, so the project may be in a continuous dev state. 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 shows no recent 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.

Official sources

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