Models.dev: Open-Source AI Model Database

Models.dev: A Community-Driven Atlas of AI Model Specifications, Pricing, and Capabilities

In the fast-evolving world of AI, having a single, reliable repository of model specifications, pricing, and capabilities is a rare luxury. Models.dev is built to fill that gap. It’s an open-source database, grown by a global community, that documents model providers, individual models, their costs, features, and limits. It’s also used internally by opencode to power a trusted catalog of AI tools. The goal is simple: give developers, researchers, and organizations a transparent, up-to-date reference you can trust and contribute to.

A Friendly, Open, and API-Powered Catalog

• Open to contributions from the community: data is stored as TOML files and organized by provider and model, with a real-world, human-friendly structure.
• Public API access: you can fetch the entire dataset as JSON to build dashboards, comparisons, or internal tooling.
• Provider logos and branding: provider logos are available as SVGs, making it easy to display clean branding in your integrations.
• A streamlined workflow to add new models: clear steps, validation, and tooling that keep the catalog consistent and safe to publish.

Accessing the Data via API

If you’re looking to integrate or explore programmatically, the API is designed for straightforward access. The data exposed via the API includes the same fields you’ll use when contributing, just in a machine-friendly format.

• API endpoint to fetch all data:
• bash curl https://models.dev/api.json
• How to look up a specific model: use the Model ID field as the canonical identifier.
• This ID is the same one used by the AI SDK ecosystem, ensuring smooth interoperability across tools and integrations.
• Understanding the Model ID: it’s the unique path-style identifier for a model, sometimes reflecting the provider and model family (for example, a canonical model that mirrors another provider can be referenced via a wrapper with extends).

Provider Logos and SVGs

Branding matters for quick recognition and professional presentation. Models.dev provides:

• Logos available as SVG files: curl https://models.dev/logos/{provider}.svg
• Replace {provider} with the Provider ID (e.g., anthropic, openai, google)
• If a provider logo is not present, a default logo is served to maintain a consistent visual experience
• SVGs are designed to be flexible: no fixed size or color, using currentColor for fills and strokes so the logo can harmonize with any site theme

Contributing: A Community-Driven Data Engine

Models.dev isn’t just a static directory. It’s a living, community-driven project that stores data in the repo and uses automation to validate and publish. The core idea is to empower anyone to contribute models, providers, and accurate metadata with a transparent review process.

• Core data format: TOML files
• Organized by provider and by model
• A provider’s logo is stored as an SVG
• Why TOML? It’s human-friendly, supports complex structures needed for model specs, and integrates well with tooling
• The end-to-end flow: propose changes via a pull request, have them validated by automated checks, and then merged into the canonical catalog

Adding a New Model: A Step-By-Step Guide

To add a new model, you’ll navigate a clean, well-documented process designed to keep data consistent and useful to developers.

1) Create a Provider (if it doesn’t exist)

• When the provider isn’t already present in providers/, start here:
• Create a new folder in providers/ with the provider’s ID (for example, providers/newprovider/).
• Add a provider.toml with these essential details:
  • name = "Provider Name"
  • npm = "@ai-sdk/provider" // AI SDK Package name
  • env = ["PROVIDERAPIKEY"] // Environment variable keys used for auth
  • doc = "https://example.com/docs/models" // Link to provider’s docs
• If the provider lacks an npm package but offers an OpenAI-compatible endpoint, adapt the fields accordingly:
  • npm = "@ai-sdk/openai-compatible" // SDK name
  • api = "https://api.example.com/v1" // Base URL for the API

2) Add a Logo (optional)

• To give a provider a recognizable visual brand:
• Place a logo.svg file in the provider’s directory: providers/newprovider/logo.svg
• Use an SVG that adheres to currentColor: no fixed sizes or colors
• An example structure for the SVG helps future-proof rendering across platforms

3) Add a Model Definition

• Create a new TOML file in the provider’s models/ directory
• If the model ID contains a slash, use subfolders. For example, for openai/gpt-5:
  • Create a folder openai/ and place gpt-5.toml inside it
• Core fields you’ll define (illustrative subset):
• name = "Model Display Name"
• attachment = true|false
• reasoning = true|false
• tool_call = true|false
• structured_output = true|false
• temperature = true|false
• knowledge = "YYYY-MM" or "YYYY-MM-DD" format
• release_date = "YYYY-MM-DD" (or YYYY-MM)
• last_updated = "YYYY-MM-DD" (or YYYY-MM)
• open_weights = true|false
• interleaved = true|false or an object like { field = "reasoning_content" }
• cost (a nested table) with fields like input, output, reasoning, cacheread, cachewrite, inputaudio, outputaudio
• limit (a nested table) with fields like context, input, output
• modalities (a nested table) with arrays:
  • input = ["text","image"]
  • output = ["text"]
• A sample TOML snippet (illustrative):
• [cost] input = 3.00 output = 15.00 reasoning = 15.00 cacheread = 0.30 cachewrite = 3.75 inputaudio = 1.00 outputaudio = 10.00
• [limit] context = 400000 input = 272000 output = 8192
• [modalities] input = ["text", "image"] output = ["text"]
• [interleaved] field = "reasoning_content"

3a) Reuse an Existing Model with extends (for wrappers)

• In some cases, wrapper providers mirror an existing model from another provider.
• Use extends to reuse the canonical model definition when appropriate:
• Example:
  • [extends] from = "anthropic/claude-opus-4-6"
  • omit = ["experimental.modes.fast"]
  • [provider] npm = "@ai-sdk/anthropic"
• Rules and caveats:
• from must point to another model using a / path
• omit is optional and removes fields after merging; you can still override top-level fields
• If you override nested tables like [cost], [limit], or [modalities], you must provide the full values needed for those tables
• The id field comes from the filename; do not add it as a field in TOML
• Use extends only for wrappers that are materially identical to the source and differ only by overrides

4) Submit a Pull Request

• The workflow is designed to keep a clean, auditable trail:
• Fork the repository
• Create a new branch for your changes
• Add your provider and/or model files
• Open a PR with a clear description of what you added or changed

Validation: Making sure the Data Stays Consistent

• There is a GitHub Action that automatically validates new submissions against a schema
• What gets validated:
• All required fields are present
• Data types align with the schema
• Values sit within acceptable ranges
• TOML syntax is valid
• If you migrate existing wrapper models to extends, a diff is produced to verify changes:
• Use bun run compare:migrations
• The tool prints a diff for each changed model TOML so you can confirm the generated JSON only changed where intended

Schema Reference: What the Catalog Expects

Models.dev defines two core schemas: provider and model. Here’s a high-level look at what each includes, to help you understand how data is structured and consumed.

Provider Schema

• name: String — Display name of the provider
• npm: String — AI SDK Package name
• env: String[] — Environment variable keys used for auth
• doc: String — Link to provider’s documentation
• api: String (optional) — OpenAI-compatible API endpoint (required if using the openai-compatible package)

Model Schema

• name: String — Display name of the model
• attachment: Boolean — Supports file attachments
• reasoning: Boolean — Supports reasoning / chain-of-thought
• tool_call: Boolean — Supports tool calling
• structured_output: Boolean (optional) — Supports structured output
• temperature: Boolean (optional) — Supports temperature control
• knowledge: String (optional) — Knowledge-cutoff
• release_date: String — First public release date
• last_updated: String — Most recent update date
• open_weights: Boolean — Trained weights publicly available?
• interleaved: Boolean or Object (optional) — Supports interleaved reasoning
• interleaved.field: "reasoningcontent" or "reasoningdetails"
• cost.input: Number — Cost per million input tokens (USD)
• cost.output: Number — Cost per million output tokens (USD)
• cost.reasoning: Number (optional) — Cost per million reasoning tokens
• cost.cache_read: Number (optional)
• cost.cache_write: Number (optional)
• cost.input_audio: Number (optional)
• cost.output_audio: Number (optional)
• limit.context: Number — Context window
• limit.input: Number — Maximum input tokens
• limit.output: Number — Maximum output tokens
• modalities.input: Array of Strings — Supported input modalities
• modalities.output: Array of Strings — Supported output modalities
• status: String (optional) — alpha / beta / deprecated

These fields are designed to capture the practical, decision-relevant details developers need when comparing models, while keeping the structure extensible for future additions.

Working on the Frontend and Local Development

If you’re curious about the frontend workflow or contributing to the UI, there are practical steps to get you started locally.

• Prerequisite: Have Bun installed
• Frontend setup and dev run:
• bash bun install cd packages/web bun run dev
• What you’ll see: a frontend that interfaces with the catalog, allowing you to browse providers, models, and their associated metadata

Manual Testing with opencode

For developers who want to test provider changes in a more end-to-end fashion, opencode provides a helpful workflow.

• Build for testing:
• bash bun install cd packages/web bun run build
• Run opencode against a local API:
• OPENCODEMODELSPATH="dist/_api.json" opencode

This integration test helps ensure your changes are reflected in a realistic API surface and that downstream consumers can rely on the emitted JSON.

Where This All Comes From

Models.dev is created by the maintainers of SST. The project thrives on a sense of community and curiosity, bringing together developers who value transparent AI tooling and reproducible data.

Join the Community

If you’re excited about contributing or want to stay in the loop about new models, updates, and tooling, consider connecting with the community:

• Discord: a place to ask questions, share improvements, and discuss best practices
• YouTube: tutorials, walkthroughs, and presentations
• X (formerly Twitter): updates and quick notices

Using Models.dev to Build Better AI Tools

For developers, Models.dev isn’t just a catalog—it’s a practical resource for discovering capabilities, pricing, and integration considerations. When you’re comparing models for a product, the combination of provider metadata, a model’s features, and real-world constraints (like context length and price) helps you make informed choices quickly. And because the data comes from a vibrant, open ecosystem, you can trust that the catalog is both current and corrigible when new information emerges.

A Practical Path to Keeping Data Fresh

The repository-and-PR workflow is designed to minimize drift in a fast-moving landscape. By requiring TOML-structured entries, validating with automated checks, and encouraging verification against live docs, the catalog remains accurate and useful without becoming brittle.

• Your contribution improves the spectrum of models available to the community
• The validation pipeline reduces the risk of bad data making its way into the public API
• The combination of provider metadata and per-model cost data enables practical price-performance analyses

Reflecting on the Model Ecosystem

Models.dev captures a moment in time when the AI model landscape is rapidly expanding and evolving. The catalog provides a stable, navigable map for developers to explore, compare, and implement.

• A transparent view of capabilities: tooling, reasoning support, and interactivity
• Clear cost structures: what you pay per token, per operation, and per modality
• A forward-looking structure: the schema is ready to accommodate new modalities, new pricing models, and new interaction patterns as the ecosystem grows

Closing Thoughts

Models.dev stands as a community-driven beacon for AI model specifications, pricing, and capabilities. By combining open, contribution-friendly workflows with a robust API and clear schemas, it offers a practical, scalable resource for developers, researchers, and product teams. It’s not just about listing models—it’s about enabling meaningful comparisons, transparent pricing, and a collaborative approach to documenting a rapidly changing technological landscape.

If you’re part of a provider, a contributor, or simply an avid consumer of AI tools, consider exploring the catalog, contributing a model, or helping refine the data model and validation processes. The strength of Models.dev lies in its community: the more people who participate, the more accurate, comprehensive, and useful the catalog becomes for everyone building with AI.

Images and Visuals

• The Models.dev logo at the top anchors this post, signaling the collaborative, open-source spirit of the project.
• Provider logos, when available, are offered as scalable SVGs to ensure clean branding across different platforms and displays.

A Final Note

For those curious about the technical underpinnings, the project is designed to be approachable for newcomers and robust enough for advanced users. The TOML-based data model, the clear separation between provider and model definitions, and the built-in validation ensure contributions are consistent and trustworthy. Whether you’re contributing a new provider, adding a novel model, or simply using the API to power your own dashboards, Models.dev offers a reliable, community-driven foundation for understanding the AI model landscape.