Fonctionnement de LLM Live

Chaque diagnostic sur ce site repose sur des règles transparentes détaillées ici. Aucun fournisseur ne paie pour son référencement, et les chiffres ci-dessous sont exactement ceux exécutés par le code.

État des services

Un verdict fondé sur quatre signaux. Le pire l’emporte.

Nos tests: Lorsque nous disposons d'une clé d'API, un worker envoie une courte requête en streaming (compter de 1 à 20, 80 tokens au maximum) à l'API du fournisseur toutes les 60 à 120 secondes, et enregistre le délai d'obtention du premier token ainsi que le débit de tokens par seconde. En cas d'échec, le test est retenté deux fois à 20 secondes d'intervalle. Les limites de débit et les erreurs liées à notre propre infrastructure sont exclues. Chaque page de service indique si nos tests y sont actifs.
Règles: 3 derniers tests échoués → Panne majeure. Au moins la moitié des tests échoués sur 10 minutes → Panne partielle. Au moins 20 % échoués, ou temps médian jusqu'au premier token supérieur à 3 s et 3 fois plus lent que sa médiane sur 24 heures → Dégradé.
Pages de statut officielles: Interrogées chaque minute. Un statut de plus de 15 minutes est ignoré, de sorte qu'une page bloquée ne puisse pas maintenir un service au vert ou au rouge.
Via OpenRouter: OpenRouter publie la part de requêtes réussies pour chaque fournisseur de chaque modèle. Si au moins 2 modèles sur les endpoints directs du fournisseur, et au moins la moitié d'entre eux, sont en dessous de 80 % sur 30 minutes et 10 points sous leur niveau des dernières 24 heures → Dégradé ; sous les 50 % en moyenne → Panne partielle. Si 3 fournisseurs ou plus échouent en même temps, le problème provient d'OpenRouter et le signal est ignoré.
Signalements d'utilisateurs: Au moins 10 signalements en 15 minutes et 4 fois le rythme habituel → Dégradé. Les signalements seuls ne marquent jamais un service comme interrompu.
Rétablissement et alertes: L'état est réévalué toutes les 30 secondes. Un service ne repasse Opérationnel qu'après 3 minutes sans incident, afin d'éviter qu'une API instable n'envoie des alertes en boucle. Les alertes sont déclenchées lorsqu'un problème commence, s'aggrave ou se résout.
Barres d'historique: Chaque barre représente 30 minutes, colorée selon le pire état constaté durant cette période. Le gris indique une absence de données. Le taux de disponibilité correspond à la part de barres sans incident.

Modèles et tarifs

Chaque tarif provient d'une API publique et est vérifié toutes les 5 minutes.

Source: Le catalogue de modèles, les tarifs et les fenêtres de contexte proviennent de l'API publique d'OpenRouter. Les prix sont affichés pour 1M de tokens tels que renseignés par OpenRouter, ce qui correspond généralement aux tarifs directs du fournisseur, mais pas toujours.
Historique des prix: Nous enregistrons un instantané toutes les 5 minutes et traçons chaque variation, de sorte que les baisses de prix ainsi que l'arrivée ou le retrait de modèles apparaissent dans le flux d'actualités en quelques minutes.
Où l'exécuter: Le nombre de fournisseurs distincts proposant un modèle donné sur OpenRouter. Les offres flex, batch, prioritaires ou spot ne sont pas comptabilisées, car elles sont souvent indisponibles par nature.

Arène d'échecs

Les modèles s'affrontent. Un moteur d'échecs veille à l'exactitude des scores.

Un coup: Le modèle reçoit la position (FEN) et la liste des coups, puis répond par un coup et un court commentaire. La validité est vérifiée avec chess.js. Après un coup illégal, le modèle reçoit la liste des coups autorisés et réessaie ; un troisième coup illégal entraîne la perte de la partie. Trois réponses d'affilée sans aucun coup font perdre au temps.
Budget de réflexion: Le raisonnement est plafonné à 1024 tokens par coup afin qu'une partie ne coûte que quelques centimes. Cela sous-évalue la force des modèles de raisonnement : l'arène compare donc les modèles avec la même limite stricte, et non à leur plein potentiel.
Classement: Méthode Glicko-2, qui prend en compte l'incertitude du classement. Le classement général est trié selon la note moins deux écarts-types, une estimation prudente. Un modèle reste provisoire tant qu'il n'a pas disputé 10 parties. Les appariements favorisent les modèles ayant le moins de parties et des niveaux proches.
Précision: Stockfish évalue chaque position à une profondeur de 14 demi-coups. Une baisse des chances de gain de 5, 10 ou 15 points correspond à une imprécision, une erreur ou une gaffe ; le calcul de précision suit la formule de Lichess.
Parties non classées: Une partie interrompue en raison d'erreurs d'API du fournisseur n'est pas prise en compte dans le classement. Une partie peut également être annulée manuellement, avec indication du motif.

Votes de la communauté

Choisissez la meilleure de deux réponses anonymes. Un modèle Bradley–Terry convertit les votes en classements.

Un duel: Votre prompt est envoyé à deux modèles différents choisis parmi un ensemble d'une vingtaine de modèles récents issus d'une dizaine de laboratoires ; l'ordre est aléatoire et les noms restent masqués jusqu'au vote. Les modèles et paires ayant reçu moins de votes sont sélectionnés plus fréquemment, les modèles de pointe plus onéreux moins souvent. Chaque réponse est limitée à 1024 tokens avec le raisonnement désactivé, ou plafonnée à 512 tokens lorsqu'il ne peut pas l'être : le duel compare ainsi des réponses rapides du quotidien, et non chaque modèle à pleine puissance.
Votes: Vous ne pouvez voter qu'une fois les deux réponses terminées, et un seul vote est autorisé par duel. Un vote pour A ou B donne une victoire à ce modèle ; une égalité ou le choix « les deux sont mauvais » compte pour une demi-victoire de chaque côté, comme sur LMArena. Les duels où un modèle n'a pas pu répondre ne sont pas pris en compte.
Classement: Un modèle Bradley–Terry est ajusté sur l'ensemble des votes en une seule passe : contrairement au système Elo, l'ordre des votes n'a donc pas d'impact. Il est présenté sur l'échelle Elo : un écart de 400 points correspond à une probabilité de 10 contre 1 d'être préféré, et le modèle médian est fixé à 1000. Une légère régularisation a priori (une égalité virtuelle par modèle) maintient un score fini pour un modèle qui n'a encore jamais perdu.
Confiance: L'intervalle à 95 % est calculé à partir de 100 rééchantillonnages par bootstrap des votes. Le rang correspond à 1 plus le nombre de modèles dont l'intervalle complet se situe au-dessus de celui du modèle ; ainsi, les modèles aux intervalles qui se chevauchent partagent le même rang. Les modèles ayant moins de 20 votes sont répertoriés après les autres. Tout est recalculé toutes les 10 minutes.
Catégories: Un petit modèle de langage classe les prompts ayant fait l'objet d'un vote en plusieurs catégories : code, maths, écriture créative, conseils & guides, connaissances & faits ou autre, et détecte la langue ; le classement des prompts en russe ne retient que les requêtes dans cette langue. Un modèle apparaît dans une catégorie dès qu'il y cumule au moins 20 votes.
Limites de la méthode: Tout le monde peut voter, anonymement. Des limites par visiteur (8 duels par heure, 40 par jour, comptabilisés par un hachage salé de l'adresse IP) et un budget quotidien rendent le bourrage d'urnes coûteux sans pouvoir l'exclure totalement. Les internautes jugent autant la forme que le fond : les réponses plus longues et bien mises en page ont tendance à gagner. Les prompts sont conservés pour l'attribution des catégories et peuvent être publiés de façon agrégée ; les adresses IP brutes ne sont jamais stockées.

Débats

Deux modèles débattent d'un sujet en trois manches. Une IA juge note la prestation à deux reprises, puis les spectateurs votent.

Sujets: Une quarantaine de sujets sélectionnés dans cinq domaines : tech & IA, société, sciences, éthique et vie quotidienne, chacun rédigé en anglais et en russe. Nous écartons les élections et les candidats, les oppositions religieuses et tout ce qui vise des groupes de personnes. Le sujet suivant est le moins utilisé qui ne figurait pas parmi les dix derniers ; un débat sur trois a lieu en russe.
Débatteurs: Deux modèles distincts tirés parmi la sélection d'une vingtaine de modèles récents. Les modèles comptant moins de débats et les paires qui se sont moins souvent affrontées sont tirés plus régulièrement, les flagships onéreux moins souvent. Les positions sont attribuées au hasard : un modèle ne choisit pas le camp qu'il approuve. Un modèle qui échoue à répétition est mis en pause pendant 2 heures, ou pendant 24 heures après une erreur de compte ou de modèle. Un nouveau débat commence 30 à 60 minutes après le précédent, dans la limite du budget quotidien.
Personnages: Depuis le 29 octobre 2026, les modèles débattent dans un rôle : deux personnages choisis parmi dix figures fictives (aucune personnalité réelle, politique ou religieuse), chacune dotée de son propre style d'expression. Les personnages sont attribués indépendamment des modèles, en privilégiant ceux qui ont le moins débattu. Chacun dispose d'une mémoire : son historique de résultats, son bilan face à l'adversaire du jour, de courtes notes sur ses trois derniers débats et une citation emblématique, le tout injecté dans son prompt. Un petit modèle (Qwen Flash) rédige ces notes après chaque débat ; elles suivent la même modération que les discours, et une citation n'est retenue que si elle figure mot pour mot dans les prises de parole du personnage. Le classement des personnages repose sur les verdicts du juge selon la même méthode ; la consigne donnée au juge est d'évaluer les arguments, pas le personnage.
Manches: Six interventions en alternance stricte : déclarations liminaires, réfutations et conclusions. Le Pour s'exprime en premier à chaque manche et le Contre répond, ce qui donne le dernier mot au Contre. Chaque participant a connaissance du sujet, de son camp et de l'intégralité de la transcription jusqu'alors, et dispose d'un maximum de 250 mots (600 tokens, 800 en russe) avec le raisonnement désactivé, ou limité à 512 tokens s'il ne peut pas l'être. La consigne interdit d'inventer des statistiques ou des citations et de décliner sa propre identité.
Modération: Chaque réplique est vérifiée avant publication : par Llama Guard 4, un classifieur de sécurité compact, avec un petit modèle généraliste en secours. Si une prise de parole est signalée, son contenu est remplacé par « supprimé par la modération », le débat s'interrompt et il n'est comptabilisé dans aucun classement.
Le juge: Un modèle compact provenant d'un laboratoire différent de celui des deux débatteurs (Claude Haiku, DeepSeek Flash ou Qwen Flash) examine les interventions regroupées par camp, sans mention du nom des modèles. Il attribue à chaque camp une note de 1 à 10 sur l'argumentation, la réfutation et la clarté, puis désigne un vainqueur accompagné d'une brève justification. Il évalue deux fois le débat, d'abord avec les arguments du Pour en premier, puis avec ceux du Contre en premier, les juges LLM ayant tendance à favoriser le camp qu'ils lisent en premier. Un camp ne l'emporte que si les deux lectures s'accordent ; dans le cas contraire, le verdict conclut à un match nul.
Spectateurs: À la fin d'un débat, chacun peut voter Pour, Contre ou Nul pendant 7 jours : un seul vote par débat et par visiteur (hachage salé de l'adresse IP, jamais l'adresse elle-même) et au maximum 30 votes par heure. Les résultats s'affichent une fois votre vote enregistré, tout comme le verdict du juge, à moins que vous ne demandiez à le consulter au préalable. Un débat intègre le classement des spectateurs dès qu'il réunit au moins 5 votes ; l'option la plus votée l'emporte, et une égalité entre Pour et Contre donne un match nul.
Classements: Deux classements Bradley–Terry, selon la même méthode que pour les votes de duels : l'un fondé sur les verdicts du juge, l'autre sur la majorité des spectateurs ; un match nul rapporte une demi-victoire à chaque camp. Tous les résultats sont ajustés simultanément : l'ordre chronologique des débats n'a pas d'influence et un débat annulé est simplement retiré. Échelle Elo avec le modèle médian calé à 1000, intervalle à 95 % obtenu par 100 rééchantillonnages par bootstrap, et modèles de moins de 10 débats classés relégués en fin de liste. Recalcul toutes les 15 minutes.
Limites de la méthode: Ce système évalue l'art du débat sous de strictes contraintes, non le savoir encyclopédique ou la véracité des faits : un modèle peut s'imposer en défendant habilement une thèse fragile. Le juge reste un modèle compact avec ses propres biais, comme une préférence pour un ton assuré ; inverser l'ordre de lecture élimine le biais de position, mais pas tous les autres. Certains thèmes favorisent un camp, mais l'attribution aléatoire des côtés équilibre les chances sur un grand nombre de rencontres.

Arène de code

Les modèles résolvent le même problème en Python ou JavaScript. Les tests cachés tranchent ; la vitesse ne sert qu'à départager les égalités parfaites.

Problèmes: 71 problèmes soigneusement sélectionnés : 12 faciles, 21 intermédiaires et 38 difficiles. Les plus simples abordent l'algorithmique classique et le traitement de texte ou de données (CSV, versions, logs, chemins JSON) ; les plus ardus requièrent un algorithme avancé ou une rigueur sans faille : arbres de segments à propagation paresseuse, flot maximal et couplage, automates de suffixes, programmation dynamique sur masques de bits ou sur arbres, géométrie en coordonnées entières exactes, mini-interpréteur, carnet d'ordres, ordonnanceur. Chacun propose un énoncé, une signature de fonction, des exemples publics, 6 à 19 tests cachés ciblant les cas limites et, pour 66 d'entre eux, des entrées volumineuses soumises à une limite de temps. Les résultats attendus proviennent de solutions de référence validées contre une recherche exhaustive sur des milliers de petites entrées aléatoires. La limite de temps équivaut au double de la plus lente de trois exécutions en bac à sable de la référence et d'une solution classique de cours, plus 100 ms : le bon algorithme passe largement, une complexité quadratique échoue. Six manches sur dix portent sur un problème difficile, trois sur un intermédiaire et une sur un facile ; dans chaque niveau, le choix se porte sur le sujet le moins utilisé hors des dix derniers.
Une manche: Quatre modèles issus d'un groupe d'une vingtaine de modèles spécialisés en code, un seul par laboratoire dans la mesure du possible, reçoivent l'énoncé au même instant avec le raisonnement désactivé (ou limité à 1024 tokens s'il ne peut pas l'être) et jusqu'à 2048 tokens pour répondre, 4096 sur les problèmes difficiles. Environ deux manches sur trois se déroulent en Python 3.12 et une en JavaScript (Node.js 24) sur l'un des 65 problèmes dont JavaScript gère les entrées et sorties sans altération (pas d'entiers au-delà de 2^53) ; JavaScript est soumis aux mêmes tests et limites de temps, avec signature et exemples adaptés au langage. Les modèles répondent par un unique bloc de code ; nous retenons le bloc qui déclare la fonction attendue. Le temps de réponse s'étend de la requête jusqu'à la fin de la génération et s'affiche à titre informatif. Une nouvelle manche démarre 20 à 30 minutes après la précédente, dans la limite du budget quotidien.
Bac à sable: Chaque solution est exécutée une fois dans un conteneur neuf sous gVisor : pas d'accès réseau, système de fichiers en lecture seule, 512 Mo de mémoire pour le conteneur (environ 380 Mo pour le code Python ; pour JavaScript, un tas de 192 Mo plus les tampons), un seul cœur processeur, 64 processus, un dossier temporaire de 16 Mo et une sortie standard plafonnée. Le code tourne dans son propre processus ; un processus superviseur distinct lui soumet les tests un par un et chronomètre chaque appel de l'extérieur, de l'envoi des données à la réception complète du résultat, empêchant le code d'accéder à l'horloge ou de la modifier. Un test qui dépasse le temps imparti ou fait planter le processus est arrêté net, et les tests restants reprennent dans un nouveau processus. Les résultats attendus n'entrent jamais dans le conteneur : le superviseur renvoie un hachage de chaque résultat, vérifié à l'extérieur. Les exemples publics montrent ce que le code a renvoyé ; les entrées et résultats cachés ne sont jamais divulgués.
Attribution des points: Un problème est considéré comme résolu lorsque l'ensemble des tests passe, y compris les entrées volumineuses dans les délais. Au sein d'une manche, chaque paire de modèles forme un duel départagé par la proportion de tests validés. La vitesse n'intervient qu'en cas d'égalité parfaite : le code dont le temps d'exécution total dans le bac à sable est inférieur d'au moins 25 % et de 20 ms l'emporte, sinon le duel est déclaré nul. Le temps mis par le modèle pour formuler sa réponse n'est jamais pris en compte. Jusqu'au 28 octobre 2026, la vitesse de réponse départageait les solutions valides ; tous les classements ont ensuite été recalculés à partir de l'historique des manches selon les règles actuelles.
Classement: Calcul Bradley–Terry sur l'ensemble des duels simultanément, selon la même méthode que pour les votes de duels : échelle Elo avec le modèle médian calé à 1000, intervalle à 95 % obtenu par 100 rééchantillonnages par bootstrap, modèles de moins de 10 manches classées relégués en fin de tableau. Un modèle qui ne parvient pas à répondre en raison d'une défaillance du fournisseur est retiré de la manche et suspendu 2 heures, ou 24 heures en cas d'erreur de compte ou liée au modèle.
Limites de la méthode: Le classement mesure une unique tentative par problème, sans possibilité de tester le code au préalable : il s'agit donc d'un taux pass@1 sous un budget de tokens restreint, et non de chaque modèle exploité au maximum de ses capacités. Le temps d'exécution est relevé sur un serveur partagé, ce qui rend les infimes variations non significatives ; seules des différences franches sont ainsi retenues. Les limites de temps ayant été calibrées sur Python, elles se révèlent plus généreuses pour JavaScript, généralement plus rapide à l'exécution. Les problèmes sont uniquement en anglais et la série de 71 problèmes finit par tourner en boucle ; un modèle peut donc avoir rencontré des exercices similaires durant son entraînement.
Seconde chance: Un modèle dont le code a échoué à au moins un test bénéficie d'une tentative supplémentaire avec son code d'origine et le compte-rendu : nombre de tests réussis, détail de chaque exemple public en échec avec valeur attendue et obtenue ou message d'erreur, et, pour les tests cachés et volumineux, uniquement le nombre d'échecs et leur cause, sans jamais dévoiler leurs entrées. Le nouveau code est soumis aux mêmes tests. Le résultat apparaît sous la première réponse et dans le classement avec la mention corrigé / retenté, sans jamais modifier le classement ou les rangs attribués.

Graphiques

Les graphiques du marché s'appuient uniquement sur nos données. Lorsqu'elles sont limitées, le graphique le précise.

Prix vs qualité: Le prix correspond au tarif combiné pour 1M de tokens sur une base de 3 tokens d'entrée pour 1 token de sortie (le ratio retenu sur tout le site), sur échelle logarithmique ; les modèles gratuits sont exclus. La qualité correspond au classement des votes humains (Bradley–Terry) dès lors qu'au moins 5 modèles totalisent plus de 20 votes, ou à défaut au classement d'échecs (Glicko-2) ; vous pouvez basculer de l'un à l'autre. Un modèle se situe sur la frontière de Pareto lorsqu'aucun modèle plus abordable n'obtient un meilleur score. Avec moins de 3 modèles classés de manière confirmée, la frontière inclut les notes provisoires, ce que le graphique indique. Nous n'importons aucun score issu d'autres classements.
Dates de sortie: Le trimestre d'un modèle correspond à sa date d'ajout au catalogue d'OpenRouter, qui intervient généralement quelques jours après son lancement. Les instantanés horodatés d'un même modèle (« 0902 ») ne sont pas répertoriés séparément. Le catalogue n'intègre que les modèles encore disponibles lorsque nous avons commencé notre suivi en octobre 2026 : les trimestres antérieurs ne tiennent donc pas compte des modèles retirés avant cette période.
Pays: Chaque éditeur sur OpenRouter est rattaché au pays du siège du laboratoire via une table de correspondance interne. Les créateurs de fine-tuning communautaires, les modèles anonymes et les laboratoires impossibles à situer avec certitude sont regroupés sous Autre / inconnu. Aucun laboratoire russe (Yandex, Sber GigaChat, T-Bank) n'étant référencé sur OpenRouter à ce jour, la Russie ne figure pas dans les graphiques.
Poids ouverts: Un modèle est qualifié de open-weights si OpenRouter associe un dépôt Hugging Face à sa fiche (hugging_face_id), et de propriétaire dans le cas contraire. Cela atteste uniquement de la publication des poids, et non d'une licence libre : beaucoup de modèles à poids ouverts restreignent les usages commerciaux.
Part de tokens: OpenRouter diffuse les volumes quotidiens de tokens par modèle et hebdomadaires par laboratoire (le top 9, le reste étant regroupé) sous licence CC BY 4.0. Nous les récupérons toutes les 6 heures, conservons un instantané glissant sur 7 jours par modèle chaque jour et laissons la semaine en cours de côté tant qu'elle n'est pas achevée. Cette métrique reflète la part des volumes transitant par OpenRouter, non l'ensemble du marché : le trafic direct par API, les interfaces grand public et les contrats d'entreprise ne sont pas comptabilisés, tandis que les modèles économiques, gratuits ou très sollicités par des agents y occupent une place prépondérante. Ces éléments proviennent des données brutes de la page de classement d'OpenRouter, et non d'une API documentée ; en cas d'évolution, les graphiques conservent les dernières données collectées.
Données ouvertes: L'ensemble des données de la page des graphiques est accessible au format JSON à l'adresse /api/v1/charts.

Actualités

Nos propres observations en priorité, puis la communication des fournisseurs.

Nos événements: Nouveaux modèles, ajustements tarifaires, retraits de versions, pannes et meneurs de l'arène sont générés automatiquement à partir des données ci-dessus, sans intervention éditoriale.
Sources externes: Blogs des fournisseurs via flux RSS, publications GitHub des principaux outils et sujets Hacker News consacrés à l'IA atteignant au moins 150 points, analysés toutes les 15 minutes.
Traitement éditorial: Un petit modèle de langage compose un titre et un résumé en une ligne, évalue l'importance de 1 à 5 et identifie les doublons. Il n'a accès qu'au titre et à l'extrait du flux RSS, jamais à l'article complet, et chaque sujet renvoie vers sa source d'origine.

Limites

Ce qui échappe encore à ce site.

Une seule localisation: Les vérifications sont opérées depuis un unique serveur situé en Finlande. Une panne régionale ailleurs dans le monde peut ainsi passer inaperçue, et un incident réseau de notre côté peut faussement imputer une défaillance au fournisseur ; c'est pourquoi un signal isolé ne tranche jamais face à des indicateurs contraires.
Pas toutes les API: Certains fournisseurs ne disposent pas de page de statut lisible par machine, et nos tests directs nécessitent une clé d'API propre à chaque service. En l'absence de ces deux sources, le constat repose sur les données d'OpenRouter et les signalements d'utilisateurs.
Données ouvertes: L'état en temps réel de l'ensemble des services est mis à disposition au format JSON à l'adresse /api/v1/status, gratuitement et sans clé requise.