GPT-6.1 Sol est désormais le moteur de sécurité de CodeRabbit — ce que l’offre d’analyse gratuite à 1 M$ vous apporte réellement

CodeRabbit prend en charge jusqu’à 5 000 $ de revue de sécurité par IA par organisation, et la fenêtre se ferme à 23:59:59 PST le 8 novembre 2026. Le modèle par lequel elle fait passer ce travail est GPT-6.1 Sol, qu’OpenAI a livré le 29 septembre — ce n’est pas une histoire de lancement, et l’âge du modèle est l’aspect le moins intéressant à son sujet. Ce qui a changé entre le 23 et le 26 octobre est plus circonscrit et plus lourd de conséquences : une entreprise de revue de code disposant d’une véritable portée auprès des entreprises a placé ce modèle au cœur d’un produit de sécurité, publié le flux de travail qui l’entoure et assorti d’une date limite la possibilité pour des inconnus de l’essayer.

Trois documents sont arrivés en quatre jours. Le billet de blog de CodeRabbit lui-même le 24 octobre, une étude de cas client d’OpenAI le 26 octobre, et un communiqué de Business Wire le même jour annonçant à la fois l’engagement de scan gratuit et l’entrée de CodeRabbit dans le Daybreak Defense Network d’OpenAI. Lus ensemble, ils décrivent un schéma de déploiement qui vaut la peine d’être compris même si vous n’achetez jamais l’un ou l’autre produit. Lus séparément, ce sont du marketing. Le travail utile consiste à séparer les deux.

Ce que CodeRabbit a réellement construit autour de GPT-6.1 Sol

L’étude de cas OpenAI est précise sur le positionnement, qui est l’aspect qui compte : GPT-6.1 Sol y est décrit comme le modèle principal de l’agent de sécurité de CodeRabbit, en collaboration avec d’autres modèles de pointe et les scanners que les clients utilisent déjà. Il n’est pas présenté comme un remplacement de l’analyse statique. Le billet de CodeRabbit lui-même va un peu plus loin, indiquant que CodeRabbit Secure utilise « GPT 6.1 Sol et les modèles GPT Cyber » — une pile, et non un appel unique.

Le produit comporte trois couches, et elles correspondent véritablement à des métiers différents :

• Revue de PR — lit chaque modification dès son arrivée, dans le flux de revue habituel.

• Analyse approfondie — cartographie l'ensemble du dépôt plutôt qu'un seul diff, en retraçant la façon dont les composants et les dépendances interagissent.

• CodeRabbit Secure — étend cela aux dépôts liés, de sorte qu'une faille dans une bibliothèque d'authentification partagée révèle son rayon d'impact sur chaque service qui l'importe.

L’ingénierie intéressante se trouve à la fin de la chaîne. Pour les constats qu’un utilisateur sélectionne, CodeRabbit tente de vérifier l’exploitabilité en exécutant le test contre le problème dans un bac à sable isolé — explicitement pas en production — et renvoie l’un de trois états : Reproduit, Non reproduit ou Non concluant. Seuls les constats étayés deviennent une correction proposée, livrée sous forme de pull request qu’un humain examine, teste et fusionne. Le point de contrôle de fusion n’est jamais confié au modèle.

Cet ordre — d'abord l'atteignabilité, ensuite l'exécution, enfin le correctif — est la raison pour laquelle ce déploiement mérite d'être lu. La plupart des produits « l'IA trouve des bugs » s'arrêtent à la première étape et vous remettent une liste classée selon la confiance d'un modèle de langage. Ajouter un sandbox transforme une affirmation en test. Ajouter une PR de correctif transforme un test en un diff que votre CI peut réellement évaluer.

L’offre de scan gratuit, dans les conditions qui déterminent si vous pouvez l’utiliser

La page d’accueil de CodeRabbit est inhabituellement explicite sur les mécanismes, ce qui rend l’offre facile à évaluer plutôt que de devoir la scruter en plissant les yeux :

• Fenêtre — du 23 octobre au 8 novembre 2026, se terminant à 23:59:59 PST.

• Plafond — jusqu'à 5 000 $ par organisation pour l'utilisation et les corrections de Deep Scan.

• Réserve totale — 1 million de dollars, prélevés sur une limite partagée de 1 000 000 de crédits, premier arrivé, premier servi.

• Admissibilité — les organisations comptant au moins deux membres. Les projets open source, les clients actuels, les anciens clients et les équipes n’ayant jamais eu affaire à CodeRabbit sont tous admissibles.

• Ce qui est converti — seuls les constats étayés deviennent des correctifs ; le crédit finance donc l'investigation et la remédiation, et non la promesse que tout ce qui est découvert sera corrigé.

• Crédit inutilisé — les crédits réclamés mais non dépensés ne sont pas reportés au-delà de la date limite ni au-delà de l'épuisement du pool partagé.

Cette ligne d’éligibilité est celle qu’il faut lire deux fois. « Any organization » dans le communiqué de presse signifie toute organisation comptant au moins deux membres, ce qui exclut les mainteneurs solo — un groupe qui gère une grande part du code open source dont dépendent la plupart des entreprises. Si vous êtes une personne seule avec un dépôt, l’offre ne s’applique pas à vous, et aucune inscription, aussi nombreuse soit-elle, n’y changera rien.

Le deuxième élément à planifier est le compteur. Deep Scan est facturé à l’usage, et le contexte inter-dépôts fait partie de ce qui est facturé ; les dépôts liés sont en lecture seule, ce qui limite la profondeur d’une investigation mais ne plafonne pas ce que coûte une tentative. Un plafond de 5 000 $ est généreux pour un monorepo de taille moyenne et banal pour un grand, donc le geste pratique est de pointer le premier scan vers le dépôt qui vous fait le plus peur plutôt que vers celui qui est le plus facile à confier.

Pourquoi un modèle à un million de tokens est le bon format pour le travail sur les dépôts

La fiche technique de GPT-6.1 Sol explique mieux l’adéquation que n’importe quel argumentaire marketing. Il dispose d’une fenêtre de contexte de 1 050 000 jetons avec jusqu’à 128 000 jetons de sortie, accepte les entrées textuelles et d’images, et prend en charge le mode batch mais pas le fine-tuning. La date limite des connaissances est le 30 avril 2026. Cinq réglages de raisonnement sont inclus — low, medium, high, xhigh et max — medium étant celui par défaut, sans option « none » ni « minimal » pour désactiver entièrement le raisonnement.

C'est dans la tarification que la structure devient une stratégie. Le tarif standard est de 2 $ par million de tokens d'entrée et de 10 $ par million de tokens de sortie, avec l'entrée mise en cache à 0,10 $ et les écritures de cache à 2,50 $. Les requêtes dépassant 272 000 tokens paient le double sur l'entrée et le cache, et une fois et demie sur la sortie, pour l'ensemble de la requête. Batch et Flex fonctionnent à 50 % du tarif Standard ; le mode rapide double ce tarif ; les points de terminaison régionaux ajoutent environ 10 %.

Lisez ces deux faits ensemble et la conception de CodeRabbit cesse de paraître arbitraire. Le profil de coût d’un agent de sécurité n’est pas celui d’un chat. Il lit d’énormes quantités de code source globalement inchangé, produit relativement peu de sortie et bénéficie plus que presque toute autre charge de travail de la mise en cache des prompts — un dépôt que vous analysez chaque semaine est un dépôt dont le contexte bouge à peine d’une exécution à l’autre. À 0,10 $ par million de tokens d’entrée mis en cache, relire une grande base de code coûte peu, ce qui n’est pas le cas à 2 $. Le seuil de surcoût de 272K est le chiffre à surveiller : il représente environ un quart de la fenêtre, ce qui signifie que les très grandes analyses paient le multiplicateur sur chaque token de la requête, et pas seulement sur l’excédent.

Si vous voulez calculer ce prix par rapport à votre propre dépôt, GPT-6.1 Sol est sur OrcaRouter au prix catalogue — en pass-through, avec 0 % de marge, donc les tarifs de 2 $/10 $ et le tarif de 0,10 $ pour les entrées mises en cache correspondent exactement aux chiffres publiés par OpenAI et évoluent le jour où OpenAI les modifie. Cela compte davantage pour cette charge de travail que pour le chat : les entrées mises en cache font l'essentiel du travail, et un pourcentage qui s'y ajoute se cumule à chaque analyse d'une série.

Les chiffres de capacité publiés par OpenAI pour le modèle, qui sont rapportés par le fournisseur et non reproduits indépendamment :

• DeepSWE v1.1 — 75,22 % à effort élevé, à environ 0,65 $ par tâche.

• Terminal-Bench Science 0.1 — 57,02 % à effort maximal, à environ 5,47 $ par tâche.

• OSWorld 2.0 — 71,42 % à effort maximal, pour environ 1,27 $ par tâche.

• AutomationBench — 36,10 % à effort maximal ; GDP.pdf — 32,0 % à effort élevé.

• Taux d'erreurs factuelles — 7,7 % en effort faible, contre 11,4 % pour GPT-6 Sol, une réduction qu'OpenAI décrit comme d'environ 32 % en relatif.

Un détail dans ce tableau mérite plus d’attention qu’il n’en reçoit : sur DeepSWE, l’effort élevé obtient 75,22 % et l’effort maximal 71,90 %. Plus de raisonnement a produit un moins bon résultat. Quiconque choisit par défaut le réglage le plus haut en supposant qu’il est uniformément meilleur devrait examiner cette paire avant de brancher un pipeline de sécurité sur le maximum.

Le chiffre indépendant qui devrait tempérer le discours commercial

Neuf jours avant l'annonce de CodeRabbit, Endor Labs a publié une évaluation qui porte directement sur la question laissée en suspens par l'étude de cas. Son Agent Security League a fait passer 200 tâches à Codex CLI 0.144.6 sur toute la gamme GPT-6 et a noté deux choses : si l'agent avait accompli la tâche tout court, et s'il l'avait accomplie de manière sécurisée.

GPT-6.1 Sol a obtenu 77,7 % de FuncPass et 34,1 % de SecPass sur 179 tâches évaluées. GPT-6 Astra a obtenu 82,1 % et 34,6 %. GPT-6 Sol a obtenu 72,1 % et 25,1 %. Le rapport SecPass/FuncPass de Sol, 43,9 %, était le meilleur des quatre modèles Codex testés — ce qui signifie qu’il a sacrifié le moins de justesse lorsque des contraintes de sécurité ont été appliquées, même si son taux absolu de réussite en sécurité se situe juste en dessous de celui d’Astra, à une seule tâche près.

Deux tiers des tâches échouant sur le plan de la sécurité : voilà le titre, et c’est un constat réel. Ce n’est pas non plus une mesure de la détection des vulnérabilités. SecPass demande si un agent de codage a produit du code fonctionnel qui était aussi sécurisé — une question différente de celle de savoir si un agent de sécurité trouve des failles dans du code écrit par quelqu’un d’autre. Interpréter 34,1 % comme « GPT-6.1 Sol manque deux tiers des vulnérabilités » serait une erreur de catégorie, et le billet d’Endor ne formule pas cette affirmation. Ce qu’il étaye est un point plus étroit et plus difficile : sur les tâches où sécurité et fonctionnalité sont en concurrence, les modèles de pointe actuels échangent l’une contre l’autre plus souvent que les fournisseurs ne le laissent entendre. Un produit de sécurité bâti sur ces modèles se comprend mieux comme un relecteur supplémentaire doté d’un budget de lecture inhabituel, et non comme un oracle.

Les chiffres opérationnels d'Endor constituent la partie utile pour quiconque cherche à en chiffrer le coût. Une médiane de 7,9 minutes par tâche, une moyenne de 13,5, neuf dépassements de délai, et une exécution complète avec quatre workers qui se termine en environ 13 heures. La consommation de tokens s'élevait à environ 235 millions de tokens d'entrée, dont près de 94 % en cache, avec 1,5 million en sortie — soit un coût estimé entre 70 et 85 $ aux tarifs catalogue, contre 104 $ pour GPT-6 Sol et 468 $ pour GPT-6 Astra. Endor a également signalé 13 cas de triche présumée sur cinq signaux et les a tous écartés, ne rapportant aucun cas confirmé.

Ce que l’étude de cas ne vous dit pas

Le témoignage client d'OpenAI ne contient ni taux de faux positifs, ni delta de détection par rapport à la configuration pré-Sol de CodeRabbit, ni chiffres de latence, ni coût par constat. L'article de CodeRabbit ne les fournit pas non plus. Ni l'un ni l'autre n'y est obligé — un témoignage client n'est pas une évaluation —, mais cet écart détermine le poids que l'annonce peut porter.

La statistique la plus citée de la publication est celle qui appelle le plus de prudence. CodeRabbit rapporte plus de 8 000 vulnérabilités de gravité élevée ou critique détectées dans 600 organisations en 30 jours, le contrôle d’accès défaillant, l’injection SQL et les échecs d’authentification représentant plus de 70 % d’entre elles. Il s’agit d’un chiffre agrégé pour CodeRabbit Secure, et non d’un résultat de GPT-6.1 Sol, et rien de ce qui a été publié n’attribue une quelconque partie de ce chiffre au modèle plutôt qu’aux scanners et aux humains qui l’entourent.

Il existe aussi un chiffre largement relayé qui est mal interprété. Une analyse secondaire de ce déploiement cite un taux de rejet des suggestions de 56,3 % issu d’une enquête menée auprès de développeurs en 2026 — sans nommer le fournisseur de l’enquête, la taille de l’échantillon ni la méthode. Un rejet n’est pas équivalent à un faux positif : un développeur peut écarter un constat correct parce qu’il sort du périmètre, est mal formulé ou simplement incommode. Considérez 56,3 % comme la preuve que le bruit de révision coûte cher, et non comme un taux de faux positifs mesuré, car personne n’en a publié.

La troisième réserve est propre à la conception. Étant donné que le bac à sable renvoie « Non concluant » comme résultat distinct, aux côtés de « Reproduit » et « Non reproduit », une équipe qui trie rapidement apprendra à ignorer cette catégorie. Une fois que l’omission devient une habitude, les alertes sont mises en sourdine en masse — le même mode de défaillance qui rendait les outils SAST hérités faciles à ignorer. Consacrez de l’attention aux résultats non concluants, sinon l’outil se dégrade en simple case à cocher de conformité.

Rien de tout cela ne plaide contre le lancement de l’analyse gratuite. Cela plaide pour la mener comme une évaluation avec un avant et un après, et non comme un remplacement. Le positionnement de CodeRabbit lui-même présente Secure comme un complément aux outils existants, et c’est le bon choix par défaut : gardez Snyk, Semgrep ou CodeQL dans le pipeline, et mesurez ce que la nouvelle couche apporte en plus plutôt que ce qu’elle dit d’elle-même.

La porte que personne n’inclut dans le communiqué de presse

OpenAI classe GPT-6.1 Sol comme « critique en cybersécurité et élevé en biologique/chimique » et achemine l’accès via la même pile de protections que GPT-6 Astra, notamment Trusted Access et Daybreak. En pratique, cela signifie que les usages à capacité cyber sont soumis à des restrictions, et ces restrictions produisent leurs propres faux positifs.

Il existe un cas documenté. Le 3 octobre, un développeur a signalé sur le forum communautaire d’OpenAI qu’une revue de pull request AppSec défensive en lecture seule sur son propre dépôt avait été bloquée purement et simplement comme contenu de cybersécurité restreint ; la réponse du support l’a classée dans Daybreak Blue et Trusted Access for Cyber. Il s’agit d’un signalement d’utilisateur face à un volume inconnu de requêtes réussies, pas d’une mesure — mais c’est le mode de défaillance à anticiper. Si la revue de sécurité est une dépendance de production, partez du principe qu’une certaine proportion de travail défensif légitime sera refusée, et conservez un chemin qui ne passe pas par un point de terminaison soumis à autorisation.

Le Daybreak Defense Network constitue l’autre moitié de cette structure. Il s’agit du programme partenaires d’OpenAI visant à intégrer des modèles cyber de pointe dans les produits et services de fournisseurs de sécurité agréés, plutôt que directement entre les mains des clients, avec vérification d’identité, tests à périmètre défini, journalisation et supervision humaine associés. L’adhésion de CodeRabbit à ce programme, et son intention d’intégrer les modèles cyber GPT dédiés d’OpenAI dans CodeRabbit Secure, constitue un signal plus important que la substitution de modèle elle-même : cela suggère que la chaîne d’examen de sécurité est en cours de scission, avec un modèle de raisonnement général prenant en charge l’étendue des cas et des modèles cyber spécialement conçus prenant en charge les cas les plus pointus.

Le modèle à copier, même si vous faites l’impasse sur les deux produits.

Retirez l’image de marque, et ce que CodeRabbit a publié est une boucle en trois étapes que n’importe quelle équipe peut assembler : fournir au modèle un contexte à l’échelle du dépôt, y compris les dépendances liées, soumettre les constats suspects à une vérification fondée sur l’exécution dans un environnement isolé, et produire un diff examinable qu’un humain pourra fusionner. Le modèle est l’élément le moins propriétaire. Le bac à sable et le point de contrôle avant fusion sont ce qui rend la sortie fiable, et les deux sont des choses que vous contrôlez.

C’est aussi la manière la moins coûteuse de décider si l’offre gratuite vaut votre temps. Prenez un dépôt comportant une vulnérabilité connue que vous avez corrigée il y a des mois, lancez l’analyse et voyez si elle fait apparaître ce problème, combien de temps elle prend et quelle part du rapport vous exploiteriez réellement. Si elle détecte le cas introduit et ne signale rien d’autre, les 5 000 $ valent la peine d’être dépensés avant le 8 novembre. Si elle renvoie une multitude de résultats non concluants, vous l’aurez appris pour le prix d’un après-midi.

Pour les équipes qui construisent la boucle elles-mêmes plutôt que de l'acheter, la couche de routage est là où réside le risque opérationnel. Faire tourner un modèle non éprouvé sur un chemin de revue en production est un pari, et le basculement automatique est la façon de le prendre sans perdre le pipeline lorsqu'un fournisseur se dégrade — la requête est envoyée à un modèle de repli au lieu de faire échouer la tâche. Le même point de terminaison sert GPT-6.1 Sol et les modèles vers lesquels vous basculeriez, donc les comparer coûte un changement de paramètre plutôt qu'un second contrat et un second SDK.

Que faire des douze prochains jours

L’offre n’est pas un lancement de modèle et ne doit pas être évaluée comme tel. GPT-6.1 Sol est appelable depuis le 29 septembre et ses benchmarks sont publics depuis cette date ; rien n’a changé cette semaine concernant ses capacités. Ce qui a changé, c’est qu’un fournisseur de sécurité disposant d’une distribution auprès des entreprises s’est publiquement engagé à le soutenir, a publié le processus de vérification associé et a fixé une échéance ferme pour l’accès gratuit.

Si vous dirigez une équipe d’au moins deux membres et une base de code qui vous inquiète, l’arithmétique est simple : un plafond de 5 000 $, un pool au premier arrivé, premier servi, et onze jours restants après aujourd’hui. Réservez dès maintenant l’analyse de votre pire dépôt, introduisez un bug connu si vous voulez un contrôle, et notez avec autant de soin ce que le rapport se trompe que ce qu’il voit juste. Si vous êtes seul, ou si votre code est déjà couvert par des scanners auxquels vous faites confiance, la réponse honnête est que cette annonce change peu de choses pour vous — le modèle était disponible avant le communiqué de presse, et il le sera après l’épuisement des crédits.