# Models.dev: Community-maintained registry of AI model metadata

> An open-source API and database of AI models with pricing, capabilities, and provider-specific configurations. Data is stored as TOML files and served via REST endpoints.

**anomalyco/models.dev** — Project brief: An open-source database of AI models. Use the Model ID field to do a lookup on any model; it's the identifier used by AI SDK.

- Repository: https://github.com/anomalyco/models.dev
- Website: https://models.dev
- Stars: 7,051 · Forks: 1,737
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/anomalyco-models-dev

## A shared registry for AI model metadata across providers

Models.dev solves the problem that no single canonical source documents all AI models, their capabilities, and their pricing across vendors. The README states the project began as a community-contributed effort to address this gap and is used internally by opencode.ai. The database includes model specifications like token limits, modalities, special capabilities (reasoning, tool calling, structured output), and per-provider details such as cost, availability, and environment variables. The software is written in TypeScript and licensed under MIT. Model metadata is stored as TOML files in the models/ directory, organized by provider and model name. Provider-specific serving details and pricing live separately in providers/, allowing the same underlying model to be documented once and then referenced by multiple vendors. The API serves this data via JSON endpoints, allowing you to fetch the entire catalog or filter by model type.

## API endpoints and data structure

The Models.dev API serves JSON from three main endpoints. Fetch all models at https://models.dev/api.json, or filter by model type with the type parameter. The README documents a "decision" type; specialized types are excluded by default. To get only decision models, query https://models.dev/api.json?type=decision, or retrieve the complete catalog with type=all. The models.json endpoint returns provider-agnostic facts: name, release date, knowledge cutoff, token limits, modality support, and licensing. The catalog.json endpoint returns both provider-agnostic and provider-specific data in one response, including pricing in the cost field. Provider logos are available as SVG at https://models.dev/logos/{provider}.svg, where provider is the Provider ID (e.g., "anthropic", "openai", "google"). If a provider has no logo, a default is returned. The type parameter also works on models.json and catalog.json. All endpoints return JSON; there is no GraphQL interface.

Fetch all models with a single request:

```bash
curl https://models.dev/api.json
```

Filter the response to decision models only:

```bash
curl "https://models.dev/api.json?type=decision"
```

Get the complete catalog including specialized types:

```bash
curl "https://models.dev/api.json?type=all"
```

## How the database is organized

The repository uses workspace structure with TypeScript packages in packages/. The models/ directory holds provider-agnostic metadata as TOML files; for example, models/openai/gpt-5.toml documents the GPT-5 model itself, with facts like name, family, release date, knowledge cutoff, and capability flags such as attachment, reasoning, tool_call, and structured_output. Each model defines context and output token limits in a [limit] section, and supported input and output modalities (text, image, video) in a [modalities] section. Benchmark results and weight links are added as arrays: [[benchmarks]] entries hold name, score, metric and source URL; [[weights]] entries hold a label, download URL, and format (like safetensors). The providers/ directory contains provider-specific configurations, including npm package names (@ai-sdk/provider), required API keys (env field), documentation links, and pricing. When a provider serves an existing model with different pricing or limits, it can reference the model metadata with base_model and override only the differing fields. This avoids duplicating provider-agnostic facts.

## Contributing new models and updating existing data

The README describes the contribution workflow: for a new provider, create a folder in providers/ with the provider's ID, add a provider.toml with name, npm package, environment variable keys, and doc link, and add a logo.svg file. For OpenAI-compatible endpoints that do not publish an npm package, set npm to @ai-sdk/openai-compatible and include the api field with the base URL. For each model, create a TOML file in the provider's models/ directory. The filename is the model ID; if the ID contains a slash (e.g., openai/gpt-5), use nested folders. Each model TOML lists its display name, capability flags, knowledge cutoff, release and update dates, licensing info, and token limits. To reuse model metadata across providers, use base_model to point to an existing model definition in models/, then override only the provider-specific fields like cost and limit. Provider fields always win over inherited model metadata during generation. A validate script tests the data structure; run bun ./packages/core/script/validate.ts to check your edits.

## Model IDs and SDK integration

The README emphasizes that the Model ID field is the identifier used by AI SDK (ai-sdk.dev). When you look up a model in the database, use its Model ID to construct API calls in your code. For example, if models.dev documents a model with ID "anthropic/claude-opus-4-6", you will use that same identifier in the AI SDK. This standardization lets you fetch model facts from Models.dev and match them to the IDs you already use in your application. The canonical_model_id field in api.json and catalog.json exposesthe underlying model for wrapper providers; you can use this to attribute a provider-specific ID to its originating lab without guessing from the model name. The sync.md file documents how to keep Models.dev synchronized with official model lists from providers, using provider-specific scripts.

## Community-maintained pricing data that lags behind real changes

The README explicitly calls out that Models.dev relies on community contributions to stay current. Pricing changes frequently, and the database may not reflect the latest rates; you should verify pricing against your actual bills. Models are added and removed by humans reading provider announcements, so new models may not appear immediately. The documentation gives no timeline or SLA for updates. There is no mechanism to flag stale data or subscribe to changes; you must poll the API periodically to detect updates. The database covers major providers well but may have gaps for smaller or newer vendors. The special model type "decision" is documented, but the README does not explain what it means or how it differs from other types. If a provider changes pricing or discontinues a model, edits are pull requests on GitHub; there is no automated sync with provider APIs except for a few vendors with sync scripts in packages/core/script/

## Comparing Models.dev to OpenRouter and provider websites

OpenRouter is a commercial proxy for multiple LLM providers with built-in rate limiting and fallback logic; it publishes its own model list. Models.dev is a free, community-maintained database with no proxy functionality. OpenRouter prioritizes stability and support; Models.dev prioritizes comprehensiveness and standardization. Provider websites (OpenAI's API docs, Anthropic's model cards, etc.) are authoritative but require visiting each site separately. Models.dev aggregates all of them in one REST API. The tradeoff is that Models.dev lags behind real changes while provider websites are always current. For a tool that needs to enumerate models without depending on any vendor's proprietary proxy, Models.dev is the right choice.

## Conclusion

Models.dev is useful for engineers building tools that need to enumerate models and pricing across multiple providers, or for teams standardizing on the Model ID format used by AI SDK. The data completeness depends on community contributions, so you should verify that all the models you care about are documented. Before integrating the API, check that your provider is in the database and that its pricing matches your latest bill, since updates are community-driven and may lag behind real price changes.

## FAQ

### How do I use the Models.dev API?

Query https://models.dev/api.json to fetch all models as JSON. Use the type parameter to filter by model type, e.g., https://models.dev/api.json?type=decision. Use the Model ID field to look up models by their identifier used in AI SDK.

### What is Models.dev?

Models.dev is an open-source database of AI model specifications, pricing, and capabilities. It provides a REST API for querying models across all providers and allows community contributions to keep data up to date.

### Can I contribute a new model to Models.dev?

Yes. The repository accepts pull requests. Add a TOML file for the model in the provider's models/ directory, including name, capabilities, token limits, and pricing. Use base_model to reuse existing model metadata across providers.

### Is the pricing data in Models.dev always up to date?

No. Models.dev is community-maintained, and pricing updates depend on contributions. You should verify pricing against your actual bills, since changes may not be reflected immediately.

### What is the canonical_model_id field?

When a provider wraps an existing model under a different ID, canonical_model_id shows the original model's ID in the models/ directory. You can use this to trace any provider-specific ID back to its source.

## Sources

- [Official documentation](https://models.dev)
- [Official README](https://github.com/anomalyco/models.dev#readme)
- [Project repository](https://github.com/anomalyco/models.dev)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anomalyco-models-dev