anomalyco / models.dev

---
Models.dev is a comprehensive open-source database of AI model specifications, pricing, and capabilities.
There's no single database with information about all the available AI models. We started Models.dev as a community-contributed project to address this. We also use it internally in opencode.
## API
You can access this data through an API.
 [code] 
Specialized model types are omitted by default. Filter by one or more
comma-separated model types, or use `all` for the complete catalog:
 [code] 
The currently supported model type is `decision`. The `type` parameter is also
available on `models.json`, `catalog.json`, and `model-schema.json`.
Use the **Model ID** field to do a lookup on any model; it's the identifier used by AI SDK.
Provider-agnostic model metadata is available separately:
 [code] 
Use this for facts about the model itself, independent of where it is served. If you need both provider endpoints and model-only metadata in one response:
 [code] 
### Logos
Provider logos are available as SVG files:
 [code] 
Replace `{provider}` with the **Provider ID** (e.g., `anthropic`, `openai`, `google`). If we don't have a provider's logo, a default logo is served instead.
## Contributing
The data is stored in the repo as TOML files; organized by provider and model. The logo is stored as an SVG. This is used to generate this page and power the API.
We need your help keeping the data up to date.
### Adding Model Metadata
Model-only facts live in `models/`, using the same path-style IDs as provider models. For example, `models/openai/gpt-5.toml` defines metadata for the underlying GPT-5 model, while `providers/openai/models/gpt-5.toml` defines OpenAI-specific serving details such as pricing.
Use model metadata for provider-agnostic facts:
- `name`, `family`, `release_date`, `last_updated`, `knowledge`
- `attachment`, `reasoning`, `tool_call`, `structured_output`, `temperature`
- `[limit]` defaults like context, input, and output token limits
- `[modalities]` defaults
- `open_weights`, `license`, `links`, `weights`, and `benchmarks`
Example:
 [code] 
Provider TOMLs can inherit these facts with `base_model` and then keep only provider-specific fields or overrides:
 [code] 
Provider fields win over model metadata during generation. Use this when the underlying model is the same but a provider serves it with different context limits, modalities, features, or pricing.
Generated provider models that use `base_model` expose its canonical lab/model ID as `canonical_model_id` in `api.json` and `catalog.json`. Consumers can use this field to attribute a provider-specific model ID to its originating lab without guessing from the model name.
### Adding a New Provider Model
To add a new model, start by checking if the provider already exists in the `providers/` directory. If not, then:
#### 1. Create a Provider
If the provider isn't already in `providers/`:
1. Create a new folder in `providers/` with the provider's ID. For example, `providers/newprovider/`.