models.dev : base de données open source des modèles d'IA

Genèse et structure du projet

models.dev a émergé d'un besoin simple : aucune base de données unique ne couvrait tous les modèles d'IA disponibles avec leurs spécifications respectives. Le dépôt TypeScript organise ces données en fichiers TOML, qui alimentent à la fois le site https://models.dev et son API publique. Les créateurs du projet, maintainers de SST, l'utilisent aussi en interne pour alimenter opencode. Cette double utilisation (site public et consommation interne) crée une boucle de rétroaction : les besoins d'opencode guident les schémas de modèles, tandis que les contributions communautaires enrichissent l'ensemble des données.

Trois vues des données via l'API

Le projet expose trois points de terminaison JSON pour accéder aux données. curl https://models.dev/api.json renvoie le catalogue complet avec les détails des fournisseurs et modèles fusionnés. Le champ Model ID dans cette réponse correspond à l'identifiant utilisé par AI SDK, permettant une recherche directe. curl https://models.dev/models.json renvoie les métadonnées indépendantes du fournisseur : faits sur le modèle lui-même, détachés de l'endroit où il est servé. curl https://models.dev/catalog.json combine les deux en une seule réponse. Les logos des fournisseurs arrivent sous forme SVG via https://models.dev/logos/{provider}.svg, où {provider} est l'ID du fournisseur (anthropic, openai, google, etc.). Si le logo manque, un logo par défaut est servi. Le README ne documenta pas les limites de taux, les seuils de réponse ou les exigences d'authentification pour ces endpoints.

Organisation TOML : modèles et fournisseurs séparés

Les données se rangent dans le répertoire en deux branches. models/ contient les métadonnées immuables du modèle : nom, famille, date de sortie, date de mise à jour, date de cutoff des connaissances, capacités (attachment, reasoning, tool_call, structured_output, temperature). providers/ contient les détails spécifiques au fournisseur : tarification (input, output, cache_read, cache_write), limites (context, input, output tokens), modalités (text, image, audio), options de raisonnement avec dégradés (low, medium, high, max). Un fichier provider TOML peut hériter des métadonnées du modèle via le champ base_model, pointant vers models/<provider>/<model-id>. Après l'héritage, le provider ne déclare que les champs qui divergent de la base. Cette séparation élimine la duplication quand plusieurs fournisseurs servent le même modèle sous-jacent.

Schéma et champs du provider

Le schéma TypeScript réside dans packages/core/src/schema.ts. Un provider.toml exige name (nom lisible), npm (nom du package AI SDK, par exemple @ai-sdk/anthropic ou @ai-sdk/openai-compatible), env (tableau de clés de variables d'environnement pour l'auth, par exemple ["ANTHROPIC_API_KEY"]), et doc (URL vers la documentation du provider). Pour les endpoints compatibles OpenAI en utilisant @ai-sdk/openai-compatible, un champ api spécifie l'URL de base (par exemple https://api.example.com/v1). Un fichier provider de modèle énumère les champs de coût (input, output, reasoning, cache_read, cache_write, input_audio, output_audio en dollars par million de tokens), de limite (context, input, output en tokens), et de modalités (input et output comme tableaux de chaînes : text, image, audio). Un champ status optionnel accepte alpha, beta ou deprecated. Chaque fournisseur doit fournir un logo.svg en SVG sans taille fixe, utilisant currentColor pour les remplissages et les traits.

Flux de contribution et validation

Pour ajouter un nouveau modèle, vérifiez d'abord si le fournisseur existe déjà dans providers/. Si non, créez providers/<provider-id>/ avec un provider.toml décrivant l'authentification et les endpoints, ajoutez un logo.svg, puis créez le répertoire models/ pour les définitions des modèles. Le nom de fichier TOML est l'ID du modèle ; les IDs contenant / utilisent des sous-dossiers (par exemple openai/gpt-5 crée openai/gpt-5.toml). Les contributions sont validées par une GitHub Action qui vérifie les champs obligatoires (name, npm, env, doc pour les providers ; name, release_date, last_updated pour les modèles), les types de données (les tarifs doivent être des nombres positifs), et les plages de valeurs (status doit être alpha|beta|deprecated ou vide). La syntaxe TOML est lintée. Une commande bun run compare:migrations imprime les diffs des champs migrant de provider vers model metadata.

Métadonnées héritables et règles d'override

Un provider peut utiliser base_model pour pointer vers le modèle sous-jacent et réutiliser ses métadonnées. Les règles sont strictes : base_model doit référencer <provider>/<model-id> dans models/. Après base_model, écrivez uniquement les champs spécifiques au provider qui diffèrent de la base ; ne répétez pas description, structured_output, dates ou autres faits invariants. Les champs du provider surpassent les métadonnées du modèle lors de la génération. Pour les tables imbriquées comme [cost], [limit] ou [modalities], fournissez les valeurs complètes ; les arrays remplacent, les objets fusionnent profondément. Un champ base_model_omit optionnel (tableau de chemins dot-path comme ["limit.input"]) supprime les champs hérités après fusion. Le README note qu'on ne doit pas utiliser [extends] pour hériter des tables.

Configuration du développement avec Bun

Le frontend s'utilise avec Bun. bun install télécharge les dépendances, cd packages/web change de répertoire, bun run dev lance le serveur de développement sur http://localhost:3000. Pour les tests intégrés avec opencode, la séquence est bun install, cd packages/web, bun run build, puis exporter OPENCODE_MODELS_PATH=/Users/mac/.hysenlabs-rewrite/output/fr/dist/_api.json avant de lancer opencode. C'est le seul flux de développement documenté ; le README ne couvre pas le déploiement, les tests unitaires ou la configuration CI au-delà de la GitHub Action de validation des TOML.

Licence MIT et absence de garanties

Le dépôt s'enregistre sous licence MIT, copyright models.dev. La licence accorde le droit d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies du logiciel, pourvu que les notices de droit d'auteur et de permission apparaissent dans toutes les copies ou portions substantielles. Le logiciel est livré « tel quel », sans aucune garantie, y compris explicite ou implicite : merchantability, fitness for a particular purpose, noninfringement. La licence ne porte pas sur le support, les garanties de sécurité ou l'état de préparation à la production. Le README énumère les créateurs (SST), les liens vers Discord, YouTube et X.com, mais ne décrit aucun processus de gouvernance formelle ou d'assistance communautaire organisée.

Conclusion éditoriale

models.dev offre un catalogue centralisé des modèles d'IA maintenu par la communauté. Les développeurs qui construisent des outils autour des modèles d'IA trouveront ici un point de référence pour les tarifs, les capacités et les métadonnées d'identifiant de modèle utilisées par AI SDK.

Sources officielles

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