Ce que nous savons sur oai-2.1 jusqu'à présent

Dora ici. Quelqu’un dans mon équipe m’a transféré une capture d’écran le mois dernier. Un menu déroulant de sélection de modèle Codex avec des noms que personne n’avait vus auparavant — oai-2.1, arcanine, glacier-alpha, deux variantes de glacier-alpha-block. La réaction dans notre canal a été immédiate : « Est-ce que c’est la prochaine chose ? » Suivie de la question qui m’intéressait vraiment : devrions-nous planifier en conséquence ?

Alors j’ai vérifié. Au moment où j’écris ces lignes, il n’existe aucune page de documentation officielle pour oai-2.1. Pas d’entrée tarifaire. Pas de référence API. Pas d’avis de dépréciation. Le nom est apparu dans un menu déroulant, brièvement, sur certains comptes Pro, puis a disparu. C’est tout.

Cet article ne porte pas sur ce que oai-2.1 pourrait être. Je n’en ai aucune idée, et quiconque vous dit le contraire ne fait que supposer. Il s’agit de ce que les équipes qui se soucient des nouveaux modèles devraient — et ne devraient pas — faire avec des informations à ce niveau de certitude. Surtout le « ne devraient pas ».

Pourquoi oai-2.1 est en train d’être discuté

Où le nom apparaît

La séquence, pour autant que je puisse la reconstituer : aux alentours du 22 avril 2026, un utilisateur Codex Pro a posté une capture d’écran du sélecteur de modèle montrant des noms au-delà du catalogue publiquement disponible. gpt-5.5 figurait sur la liste — alors encore non publié — aux côtés de oai-2.1 et de noms de code. La capture d’écran a circulé. TestingCatalog l’a amplifié. Hacker News a repris un fil de discussion. Les noms ont été retirés du menu déroulant peu après.

GPT-5.5 a depuis été lancé. Il apparaît désormais dans le catalogue officiel des modèles Codex comme le modèle frontier recommandé pour le codage complexe et les workflows agentiques. Ainsi, l’un des noms divulgués est passé de la rumeur au produit.

Les autres — oai-2.1, arcanine, glacier-alpha, et les variantes block — ne l’ont pas fait. Ils sont toujours là où ils étaient le 22 avril : absents de la documentation, absents de l’API, absents des tarifs.

Pourquoi cela n’équivaut pas à un lancement

Un nom de modèle dans un menu déroulant d’interface utilisateur est l’un des signaux les plus faibles possible dans cette catégorie. Cela peut signifier qu’un modèle est proche d’une sortie. Cela peut aussi signifier un slug de test interne, une variante de routage, un checkpoint renommé, une branche A/B, une expérience dépréciée qui n’a jamais été supprimée d’un fichier de configuration, ou quelque chose qui ne verra jamais le jour. Le même menu déroulant a fait apparaître à la fois un nom qui est devenu un vrai produit (gpt-5.5) et plusieurs qui — au moment d’écrire ces lignes — ne l’ont pas fait.

Le fait qu’un nom divulgué ait abouti à un lancement n’est pas la preuve que les autres le feront. C’est la preuve que les espaces de nommage internes sont plus grands que les catalogues publics.

Je me suis arrêté ici en esquissant cet article. Traiter un lancement confirmé comme prédictif des autres est la même erreur de raisonnement que de traiter une rumeur de dépréciation comme un avis de dépréciation. Le type de signal est mauvais.

Ce qui est confirmé et ce qui ne l’est pas

Vérification de la réalité du catalogue officiel des modèles

Si je prends tout ce que je peux vérifier par rapport aux propres surfaces d’OpenAI aujourd’hui, le tableau est court.

Ce qui est confirmé : gpt-5.5 existe, est documenté, dispose d’une entrée API, et est l’actuel modèle frontier Codex recommandé aux côtés de gpt-5.4, gpt-5.4-mini, et la famille gpt-5.3-codex. Le journal des modifications de l’API OpenAI enregistre sa sortie avec 1M de contexte, entrée d’images, sorties structurées, appel de fonctions, mise en cache des prompts, traitement par lots, et une longue liste de support d’outils. Concret, daté, tarifé.

Ce qui n’est pas confirmé : quoi que ce soit concernant oai-2.1. Il n’y a pas de fiche modèle. Pas de SKU. Pas de niveau tarifaire. Pas de taille de fenêtre de contexte. Pas de liste de modalités. Pas de calendrier de dépréciation. Pas d’association avec un ensemble de capacités connu. La chaîne oai-2.1 n’apparaît dans aucune documentation OpenAI accessible au public que je puisse trouver à la date d’écriture.

Je veux être précis ici, car l’absence est le point central. Pas « la documentation est lacunaire sur oai-2.1. » Pas « oai-2.1 a des informations publiques limitées. » Il n’y a aucune information publique sur oai-2.1 au-delà du fait que la chaîne est apparue dans un sélecteur d’interface utilisateur. C’est l’intégralité de la surface connaissable.

Pourquoi les étiquettes internes ne devraient pas orienter les décisions de feuille de route

Les étiquettes de modèles internes dans les grands laboratoires ne sont pas identiques aux produits. Elles vivent dans des cycles de vie différents. Les produits font l’objet d’engagements : documentés, tarifés, supportés, régis par la politique de dépréciation publique. Les étiquettes internes sont un état de travail. Elles sont renommées, fusionnées, divisées, supprimées, retirées silencieusement. Traiter une étiquette d’état de travail comme une entrée de feuille de route produit est une erreur de catégorie.

Le coût de cette erreur s’accumule. Une fois qu’une équipe commence à dire « nous attendrons oai-2.1 » ou « nous devrions planifier pour oai-2.1 », cela apparaît dans la planification des sprints, dans les conversations avec les fournisseurs, dans les décisions de capacité. Aucune de celles-ci ne devrait dépendre d’un nom qui n’a pas d’existence documentée.

C’est tout ce que je peux confirmer. Le reste, vous devrez le vérifier vous-même, par rapport aux surfaces officielles, quand et si quelque chose apparaît.

Ce que les développeurs devraient surveiller avant de le considérer comme réel

C’est là que je veux être utile. Si vous dirigez une équipe qui se soucie des nouvelles sorties de modèles — ce qui représente la plupart des dirigeants d’ingénierie et de produit qui lisent ceci — voici la liste de contrôle que j’utilise avant de laisser un modèle supposé influencer une décision quelconque. Je l’ai notée après la troisième fois que quelqu’un m’a contacté à propos de oai-2.1 en demandant si nous devrions « faire quelque chose ».

Un modèle supposé est suffisamment réel pour être planifié quand, et seulement quand, tout ce qui suit est vrai :

Il a une entrée dans la page du catalogue officiel des modèles pour la surface API concernée (Codex, Responses, Chat Completions, Realtime).
Il a une ligne tarifaire documentée, en dollars par million de tokens ou par appel, sur la page de tarification publiée.
Il a au moins une affirmation de capacité explicite du fournisseur — fenêtre de contexte, support de modalité, support d’outils, date de snapshot.
Il a une chaîne de modèle API qui renvoie une réponse valide lorsqu’elle est appelée sur votre compte, pas un 404 ou model-not-found.
Il apparaît dans le journal des modifications avec une date de sortie, pas seulement dans un menu déroulant d’interface utilisateur.

Si l’une de ces conditions manque, le modèle n’est pas réel à des fins de planification. Le menu déroulant affichant le nom ne compte pas comme l’une de ces conditions. J’ai vérifié.

Une question séparée : devriez-vous surveiller du tout ? À quelle fréquence ? Ma règle est approximativement hebdomadaire pour le journal des modifications officiel, jamais pour les captures d’écran. Le rapport signal/bruit sur les captures d’écran est suffisamment mauvais pour que le temps consacré à les trier coûte plus cher que l’avance qu’il pourrait éventuellement apporter. La propre orientation d’OpenAI, intégrée dans sa documentation, arrive au même point : épinglez les applications de production à des snapshots de modèle spécifiques, construisez des évaluations qui mesurent le comportement à travers les changements de version, traitez la sélection de modèle comme une décision de stabilité. C’est le workflow qui absorbe gracieusement les nouvelles sorties de modèles. Chasser les noms divulgués est à l’opposé de ce workflow.

L’autre chose que je signalerais : si l’intérêt de votre équipe pour oai-2.1 concerne vraiment autre chose — frustration face aux capacités actuelles des modèles, anxiété à propos des concurrents qui avancent plus vite, pression pour montrer de la progression — chasser la rumeur ne résoudra pas ces problèmes. Cela ressemblera à du mouvement. Ce n’en est pas.

FAQ

oai-2.1 est-il un modèle OpenAI officiel ?

Non. Au moment de la rédaction de cet article, oai-2.1 n’apparaît pas dans le catalogue public des modèles d’OpenAI, la référence API, la page de tarification, ou le journal des modifications. La seule base pour le nom est une brève apparition dans un menu déroulant de sélection de modèle Codex vers le 22 avril 2026, qui a été ensuite supprimée.

Existe-t-il une API, une documentation ou une page de tarification pour celui-ci ?

Non. L’appel de l’API OpenAI avec la chaîne de modèle oai-2.1 n’est pas supporté par aucune route documentée. Il n’y a pas de page de documentation, pas d’entrée tarifaire, pas de fiche modèle, et aucun engagement de dépréciation ou de stabilité associé.

Pourquoi les noms de modèles divulgués se propagent-ils si vite ?

Pour plusieurs raisons. L’exposition au niveau de l’interface utilisateur semble plus proche de la production que les informations d’initiés, car elle implique que le modèle est câblé dans un système réel. Les schémas de nommage invitent à la spéculation — glacier-alpha versus arcanine ressemble à une histoire même quand ce n’en est pas une. Et il existe un public permanent de développeurs cherchant des signaux précoces sur les changements de capacité. Rien de tout cela ne change la qualité du signal sous-jacent, qui est faible.

Que doivent vérifier les équipes avant de planifier autour d’un modèle supposé ?

La liste de contrôle ci-dessus : documenté dans le catalogue officiel, tarifé, avec des capacités décrites, appelable via API, et publié dans le journal des modifications. Le guide des meilleures pratiques de production OpenAI arrive dans le même voisinage — la sélection de modèle est une question de stabilité, pas une question de date de sortie.

Conclusion

Voici où j’atterrirais, si je devais donner à mon équipe une réponse en une ligne à « qu’en est-il de oai-2.1 ». Il y a une chaîne qui est apparue dans un menu déroulant. Il n’y a pas de produit. Les deux ne sont pas la même chose. Planifiez en fonction du produit quand il existe.

Je ne sais pas si oai-2.1 deviendra un modèle public. Mieux que d’inventer quelque chose. Si c’est le cas, il apparaîtra sur la page du catalogue officiel, avec des tarifs et des affirmations de capacité, et à ce moment-là cela vaut une évaluation réelle. Jusque-là, la chose la plus coûteuse qu’une équipe puisse faire est de laisser un nom supposé changer une décision réelle.

À vérifier. Je reviendrai là-dessus quand quelque chose de concret apparaîtra.

Articles précédents :