Kimi K3.1 Pro a réduit sa propre capacité cyber de 9,5 points. Les deux autres laboratoires ont fait un choix différent

Moonshot a fait le 24 octobre quelque chose que les laboratoires ne font habituellement pas : il a livré un modèle plus faible que celui qu’il aurait pu livrer, et publié le coût exact. Sur xdev-bench-hard à pass@3, un checkpoint entraîné sans les mesures de réduction des risques cyber de l’entreprise obtient 90,5 %. Kimi K3.1 Pro, le modèle que vous pouvez appeler, obtient 81,0 %. L’écart de 9,5 points est le prix à payer pour avoir retiré les données liées au cyber de l’entraînement intermédiaire et de l’apprentissage par renforcement, et c’est la déclaration la plus claire faite cette année par l’un des trois laboratoires de pointe sur ce qu’il est prêt à sacrifier en échange de capacités.

Chaque grand laboratoire dispose désormais d’une politique cyber. Elles diffèrent par leur mécanisme plutôt que par leur intention, et le mécanisme détermine ce que vous obtenez réellement lorsque vous appelez l’API. Moonshot soustrait la capacité des poids. Anthropic redirige la requête vers un autre modèle. OpenAI conditionne l’accès à une évaluation de risque. Pour une équipe de sécurité — ou pour quiconque dont la charge de travail frôle des outils offensifs —, les trois approches produisent trois types différents de surprise.

Ce que Moonshot a supprimé, et ce qu’il a conservé

Le matériel de lancement est d'une précision inhabituelle. Les données liées à la cybersécurité ont été retirées à la fois de l'étape d'entraînement intermédiaire et de celle de l'apprentissage par renforcement, tandis que les tâches de programmation générale ont été conservées. Le principe énoncé par l'entreprise est de ne pas publier de poids ouverts qui étendraient la frontière absolue des capacités cyber, et elle décrit la capacité offensive du modèle livré comme « par conception, inférieure à ce que notre pipeline peut produire » et en retard sur ce que les modèles propriétaires de pointe proposent publiquement depuis au moins trois mois.

Deux détails de cette politique comptent davantage que le chiffre phare.

Premièrement, la réduction est relative au propre pipeline de Moonshot, et non au marché. Un modèle plafonné à 81,0 % obtient encore un score largement supérieur aux 33,3 % de Kimi K3, et supérieur aux 57,1 % de GLM-5.3 sur le même benchmark. Le plafond fait reculer un modèle de pointe, sans le faire sortir de la catégorie.

Le deuxième point est que Moonshot déclare qu’il « augmentera progressivement » la capacité cyber disponible dans les poids ouverts. Il s’agit d’un calendrier, et non d’une limite fixe : les évaluations qui supposent le plafond actuel pourraient ne plus être valables lors de la prochaine version, et une copie auto-hébergée hérite du plafond qui existait à sa date de publication.

Ce que le benchmark demande réellement

La documentation de Moonshot décrit l’évaluation avec suffisamment de détails pour pouvoir en juger. xdev-bench-hard est construit à partir de vulnérabilités récemment divulguées dans des logiciels tels que le noyau Linux, Node.js, JavaScriptCore, Exim et VirGL, avec les mesures d’atténuation activées. Chaque tâche fournit le code source vulnérable, un bref indice sur le bug et le binaire compilé ; l’agent doit développer un exploit, obtenir une exécution de code arbitraire dans un bac à sable séparé et récupérer une chaîne secrète afin que le résultat puisse être vérifié automatiquement. Le score est calculé en pass@3 sur un sous-ensemble aléatoire, sans délai d’expiration strict ni limite de tokens de sortie.

Il s'agit là d'un test exigeant et ciblé : il mesure la capacité d'un modèle à transformer un binaire connu comme vulnérable en exploit fonctionnel, et non à écrire un scanner ou à qualifier une alerte. L'écart de 9,5 points entre le checkpoint sans atténuations et le modèle livré est donc la mesure réelle d'une véritable différence de capacités — et un rappel que ce chiffre ne dit pas grand-chose du travail défensif que la plupart des équipes font réellement avec le modèle.

L'alternative d'Anthropic : conserver la capacité, changer la réponse

L'approche d'Anthropic pour Claude Opus 5.5 repose sur un routage côté service. Sa documentation indique que la plupart des tâches liées à la cybersécurité peuvent être redirigées vers Claude Opus 4.8, et que les travaux en biologie et en développement de modèles de pointe peuvent être basculés vers Claude Opus 5. L'appelant ne reçoit pas d'erreur ; la réponse provient simplement d'un autre modèle. Le niveau de capacité le plus élevé, Claude Mythos 5.1, n'est disponible que pour les organisations vérifiées via des programmes tels que le Cyber Verification Program.

Le compromis est l’inverse de celui de Moonshot. La capacité de pointe existe et est servie — aux clients vérifiés, sous un autre identifiant de modèle — tandis que les appelants non vérifiés reçoivent silencieusement la réponse d’un modèle plus ancien. Pour une équipe de sécurité au sein d’une organisation vérifiée, c’est l’option la plus performante des trois. Pour quiconque se trouve en dehors d’une telle organisation, c’est un modèle qui répond discrètement avec autre chose, précisément sur les tâches où cette personne voulait le plus la capacité de pointe.

L'approche d'OpenAI : décider avant le lancement

GPT-6 Astra a été le premier modèle OpenAI classé « critique » au titre du Preparedness Framework de l’entreprise, car il peut identifier de manière indépendante de nouvelles failles de sécurité. Le déploiement a été progressif — partenaires en accès anticipé, puis paliers d’abonnement, puis l’API — et les capacités les plus risquées sont restreintes selon la notation plutôt que par un filtrage des prompts. L’accès est décidé au niveau du compte, avant toute requête.

C’est plus net qu’un réacheminement silencieux et plus lent que l’une ou l’autre des alternatives. Cela signifie aussi que la réponse à « puis-je utiliser ce modèle pour mon travail de sécurité » peut être connue à l’avance, ce qui a de la valeur pour un acheteur qui doit rédiger un document de passation de marché.

Ce que les trois stratégies font à une évaluation

Si vous évaluez des modèles sur des tâches de sécurité, les mécanismes faussent la mesure différemment, et les distorsions ne s’annulent pas.

• Le plafond de Moonshot est inscrit dans les poids. Une exécution de benchmark sur l’API et une exécution de benchmark sur une copie auto-hébergée devraient concorder, et toutes deux mesurent un modèle délibérément moins performant dans cette catégorie. Le nombre est honnête et reproductible.

• Le routage d'Anthropic se situe à l'intérieur de la pile de service. Une même requête peut produire une qualité différente selon qu'elle déclenche ou non une mesure de protection, et les chiffres de référence publiés par le fournisseur peuvent ne pas refléter le routage que reçoit votre compte. Notre propre couverture du tableau de référence d'Opus 5.5 a signalé le même problème sous un autre angle : le chiffre indépendant d'Artificial Analysis pour Terminal-Bench était de 59,6 % contre 66,4 % pour Anthropic, dans une configuration qui inclut le routage de protection côté serveur.

• Le filtrage d’accès d’OpenAI s’effectue hors du modèle. Une fois l’accès obtenu, le modèle se comporte comme lors des benchmarks ; dans le cas contraire, vous ne pouvez pas du tout effectuer la comparaison.

Ce qu’une équipe de sécurité devrait en retenir

Trois conclusions pratiques, par ordre de confiance.

D’abord, la « capacité cyber » n’est plus une propriété que l’on peut lire sur une fiche de modèle. Elle dépend des poids que vous recevez, du routage que déclenche votre compte et du programme de vérification auquel vous appartenez. Toute évaluation qui ne précise pas ces trois éléments mesure autre chose.

Deuxièmement, si votre travail est défensif — triage, rédaction de correctifs, ingénierie de détection —, le plafond de capacités coûte moins que cela n’en a l’air. Les 9,5 points sont concentrés dans les comportements adversariaux et proches de l’exploitation ; les capacités générales de codage et d’utilisation d’outils du modèle, dont le travail défensif a surtout besoin, sont précisément ce que la phase de post-entraînement a cherché à améliorer. Moonshot rapporte que Kimi Code Bench 3.0 long-horizon est passé de 55,95 % à 61,2 % dans la même version.

Troisièmement, les plafonds évoluent. Moonshot a annoncé qu’il relèvera son plafond ; les programmes de vérification d’Anthropic s’étendent ; les évaluations d’OpenAI varient d’un modèle à l’autre. Une politique qui a guidé une décision de déploiement en octobre peut être erronée d’ici janvier, ce qui plaide pour relire la documentation d’accès à chaque mise à niveau de modèle plutôt que de la considérer comme une barrière à franchir une seule fois.

Kimi K3.1 Pro est appelable via OrcaRouter à 2,00 $ par million de tokens en entrée et 10,00 $ par million en sortie, avec le même état final que partout ailleurs : le plafond est dans les poids, pas dans ce qu'un fournisseur particulier fait de votre requête. Si votre charge de travail dépend du fait de savoir quel modèle a réellement répondu, c'est une fonctionnalité. Si elle dépend du plafond offensif des modèles de pointe, aucune API du marché ne vous le donnera sans un programme de vérification.