Selected model is at capacity : dépannage de Codex et limites d'utilisation

« Selected model is at capacity » est une erreur que Codex classe comme une surcharge du serveur. Nous avons vérifié la correspondance du message avec le code public d'OpenAI et retrouvé le même message complet accompagné de serverOverloaded dans l'historique d'exécution de cet ordinateur. Il faut le distinguer de l'épuisement du quota d'utilisation ou d'une panne du PC. Toutefois, ni les informations publiques ni les traces de l'ordinateur n'ont permis d'établir la cause de la surcharge.

Selected model is at capacity. Please try a different model.

Que se passe-t-il ? Ce que montrent les incidents officiels

Le message indique que le modèle sélectionné a atteint sa capacité et demande d'essayer un autre modèle. Rien ne permet d'interpréter « capacity » comme la mémoire ou l'espace disque de votre PC. La page officielle de statut d'OpenAI recense des incidents du service ayant affiché ce message.

Ces deux fiches établissent que le même message peut apparaître pendant un incident du service et que changer de modèle n'aide pas toujours. Le nombre d'incidents publiés ne permet pas de déterminer la fréquence de l'erreur ni de conclure que votre erreur avait la même cause qu'un incident antérieur. Les dates suivent les pages officielles ; nous n'avons pas converti leurs horaires en heure standard du Japon.

Aucune de ces fiches ne publie de cause profonde, telle qu'une pénurie précise de matériel ou un bug de changement de compte. Affirmer « il n'y a pas assez de GPU » ou « l'authentification Pro est défaillante » va au-delà des informations vérifiées. Nous avons consulté les sources officielles originales le 1er octobre 2026 et distinguons les faits établis de nos recommandations.

Différences avec les limites d'utilisation, 401 et thread not found

Tous ces problèmes peuvent donner l'impression que le travail est bloqué, mais ils nécessitent des vérifications différentes. En cas d'erreur de capacité, commencez par examiner à la fois le message complet à l'écran et votre état d'utilisation. Plusieurs types de problèmes peuvent survenir sur un même compte.

Consultez le quota restant sur l'écran d'utilisation dédié

Le guide des tarifs et de l'utilisation d'OpenAI renvoie au tableau de bord d'utilisation pour consulter les limites actuelles. Pendant une session Codex CLI, vous pouvez aussi utiliser /status. Le consulter juste après l'erreur facilite la comparaison avec le quota restant à ce moment-là.

Le guide officiel explique également qu'un travail déjà en cours peut continuer sous les restrictions d'usage raisonnable même si une limite est atteinte pendant le traitement. Ainsi, une erreur suivie d'un compte rendu de fin de tâche ne permet pas, à elle seule, de déterminer si une limite a été atteinte. À l'inverse, un incident du service peut survenir avec un quota largement disponible. Consultez notre comparatif des abonnements ChatGPT Pro pour les quotas inclus et les crédits supplémentaires.

En cas d'erreur 401, vérifiez d'abord votre méthode de connexion

Le guide d'authentification de Codex distingue la connexion avec ChatGPT de celle avec une clé API. Dans l'application de bureau, le menu du profil affiche le compte actif ou l'état de la clé API. Dans la CLI, utilisez codex login status.

Même si « Incorrect API key » apparaît alors que vous êtes connecté avec ChatGPT, cet écran seul ne prouve pas que vous avez configuré une clé incorrecte. Identifier les identifiants rejetés nécessite une investigation supplémentaire. Une erreur de capacité ne justifie pas de se déconnecter immédiatement ou de supprimer les fichiers d'authentification. L'utilisation d'une clé API entraîne la facturation normale de l'API, séparément de votre abonnement ChatGPT.

Si le message est thread not found, consultez notre enquête et guide de résolution de l'erreur « thread not found » de Codex. Des erreurs antérieures d'authentification ou de chat sur le même PC ne démontrent pas de lien causal avec l'erreur de capacité actuelle.

Distinguez les erreurs HTTP 503 de l'API du message de l'application

Le guide des codes d'erreur de l'API OpenAI présente HTTP 503, service_unavailable_error et server_is_overloaded comme des indicateurs de surcharge temporaire du modèle. HTTP 429 comprend les erreurs de fréquence des requêtes ou de limites d'utilisation, tandis que HTTP 401 concerne l'authentification.

Les étapes pour reprendre le travail

Les recommandations suivantes s'appuient sur les incidents officiels, les guides d'utilisation et la documentation générale de dépannage. Elles ne sont pas publiées comme une solution garantie spécifiquement pour cette erreur.

1. Conservez votre demande et le dernier travail terminé

Si votre demande non envoyée reste visible, copiez-la et conservez le dernier compte rendu de fin de tâche ou l'état des fichiers modifiés. Avant de fermer ou de remplacer le chat, notez ce que vous avez demandé et ce qui a été terminé. Cela facilite la reprise.

Un message d'erreur seul ne prouve pas qu'aucun fichier n'a été modifié ou qu'aucune commande n'a été exécutée. Pour un développement avec Git, examinez les différences ou lancez git status avant de redemander la même modification. Pour une publication, un envoi de messages ou un achat, ne répétez pas l'instruction sans avoir d'abord vérifié son résultat.

2. Attendez un peu et consultez la page officielle de statut

Ouvrez OpenAI Status et recherchez les incidents touchant Codex ou la sélection de modèles. Comparez l'heure de votre erreur à la période de l'incident plutôt que de regarder seulement son statut actuel. Un incident passé portant le même nom ne signifie pas qu'il est encore en cours.

Pour une surcharge de l'API, les consignes officielles prévoient d'attendre au moins la durée indiquée par Retry-After, s'il est présent, ou d'espacer davantage les tentatives s'il est absent. Nous n'avons pas pu vérifier de nombre fixe de secondes à attendre dans l'application lorsqu'aucun délai n'est affiché. Nous recommandons d'attendre un peu avant de réessayer plutôt que d'envoyer rapidement des requêtes répétées. Pendant un incident recensé, consultez les mises à jour officielles sur le rétablissement.

La page de statut présente des informations agrégées. Elles peuvent ne pas refléter entièrement la situation d'un compte ou d'un modèle précis. L'absence d'incident recensé ne prouve pas que votre PC est en panne.

3. Vérifiez l'utilisation et envisagez un autre modèle si le travail est urgent

Consultez votre quota restant et l'heure de réinitialisation. Si une limite d'utilisation est explicitement signalée, tenez compte de cet avis pour décider de la suite. Ne considérez pas l'achat de crédits supplémentaires ou une réinitialisation payante comme une solution lorsque le seul message est l'erreur de capacité. Rétablir votre quota et savoir si le modèle peut accepter des requêtes sont deux questions distinctes.

Le guide officiel de sélection des modèles explique que les réglages du modèle et de l'effort de raisonnement de l'application de bureau se trouvent sous le champ de saisie. Dans la CLI interactive, utilisez /model. Les modèles disponibles varient selon le compte, le client et d'autres facteurs ; ne supposez pas qu'un modèle absent de votre interface est disponible.

Changer de modèle peut modifier la nature des réponses et la consommation du quota. Rien ne justifie de choisir systématiquement le modèle de gamme la plus élevée pour éviter les erreurs de capacité. Lors du transfert d'un travail complexe d'implémentation ou de conception, examinez le nouveau résultat au moyen des différences et des tests. Notre comparatif des générations de GPT Sol et guide de sélection apporte aussi du contexte.

4. Examinez séparément la réactivité de l'application si elle est bloquée

Distinguez une erreur de capacité d'un champ de saisie, d'un terminal ou d'une interface qui ne répond pas. Pour les chats semblant bloqués, les consignes officielles de dépannage recommandent de vérifier les autorisations en attente, de tester le terminal avec une commande simple et d'essayer une petite demande dans un nouveau chat.

Si le terminal reste bloqué, les consignes recommandent d'attendre la fin des chats actifs avant de redémarrer l'application. Cela concerne un état général d'absence de réponse ; elles ne disent pas que le redémarrage résout un manque de capacité côté serveur. Vérifiez d'abord l'état des autres chats encore en cours.

Si vous reprenez dans un nouveau chat, indiquez brièvement l'objectif, le dossier de travail, les modifications terminées et les tâches restantes. N'envoyez pas simplement « continue » en supposant que l'ensemble de la conversation précédente est disponible. Un nouveau chat utilise le même service et ne garantit donc pas d'éviter l'erreur de capacité.

Que noter si l'erreur revient

Si l'erreur se répète, conservez des éléments permettant une investigation ultérieure. Les relever avant de modifier sans cesse les réglages clarifie les conditions de l'échec.

Selon les traces disponibles, vous ne pourrez peut-être pas confirmer que le modèle choisi dans les réglages était celui réellement utilisé pour la requête ayant échoué. Si vous avez seulement relevé le réglage visible, décrivez uniquement cet élément. De même, un rétablissement juste après un changement de modèle ne prouve pas que ce changement a résolu le problème : le service peut avoir été rétabli au même moment.

Le guide officiel explique comment envoyer un retour en saisissant / dans le champ de message. Depuis un chat existant, vous pouvez choisir de partager ou non la conversation. Retirez les clés API, adresses e-mail, conversations privées et informations internes d'entreprise des journaux ou captures transmis. Il n'est pas nécessaire de publier les valeurs des clés ou les fichiers d'authentification eux-mêmes.

Un signalement précisant la date, le modèle, le message exact et le quota restant affiché est plus utile qu'un simple « ça n'arrête pas de tomber en panne ». Un code HTTP ou un identifiant de requête, s'il a été obtenu, peut aider le support, mais ne remplacez pas les données manquantes par des suppositions.

Ce que nous avons trouvé sur cet ordinateur et ce qui reste inconnu

Après le signalement d'erreurs répétées accompagné de captures, AI Arte a demandé à Codex sur cet ordinateur d'examiner en lecture seule l'utilisation et les journaux locaux le 1er octobre 2026. La version du paquet de l'application Windows était 26.928.3736.0. Nous n'avons pas vérifié que la même version était installée au moment des erreurs.

La recherche initiale n'a pas trouvé l'erreur dans 32 737 entrées de la base habituelle de journaux, 15 fichiers de journaux de l'application de bureau ou 143 fichiers de traces de session actualisés. Après qu'un lecteur a contesté les conclusions, nous avons examiné d'autres emplacements et retrouvé des échecs dans une base distincte d'historique d'exécution. Le périmètre initial de recherche était insuffisant.

Lors de l'investigation complémentaire, 35 des 6 781 tours de l'historique d'exécution étaient des échecs. Sur toute la période enregistrée, 13 contenaient le même message complet et codexErrorInfo: serverOverloaded. Parmi eux, 12 sont survenus dans cinq chats entre le 30 septembre 2026 à 22:10:01 et le 1er octobre à 00:24:55 (JST). Le chat où l'utilisateur avait joint les captures contenait également quatre échecs le 30 septembre, à 22:15:06, 22:57:58, 23:12:31 et 23:24:38, avec des messages et classifications correspondants. Ces horaires sont ceux de fin enregistrés des tours ayant échoué, pas ceux des captures. Ils décrivent les traces de cet ordinateur, pas un taux d'erreur pour tous les utilisateurs.

La Codex CLI fournie avec l'application était en version 0.159.2. Dans les définitions d'erreurs du tag public correspondant, le message complet correspond à ServerOverloaded, classé séparément de l'épuisement des quotas d'utilisation. Le code de traitement du flux convertit server_is_overloaded en erreur de surcharge, et le code de conversion pour l'affichage le relie au message complet du début de l'article. Il existe aussi un chemin convertissant les réponses HTTP 503 portant le même code d'erreur, mais des erreurs peuvent également arriver dans un flux. Le message affiché ne permet donc pas d'établir que la réponse était HTTP 503.

Nous avons établi que les échecs avaient été classés et enregistrés comme une surcharge du serveur. Les traces ne montrent pas s'il s'agissait d'une réelle pénurie de GPU, du routage des requêtes ou de problèmes de contrôle de capacité. Les détails supplémentaires des quatre échecs étaient vides et aucun code HTTP n'était enregistré. Lors de la recherche initiale, il restait 31 % du quota hebdomadaire et l'utilisation ordinaire était autorisée. Ce n'était pas le quota au moment des erreurs, et le modèle réellement utilisé pour les requêtes ayant échoué n'a pas non plus été établi.

Concernant les erreurs d'authentification, le rapport officiel de cause profonde d'un autre incident du 25 septembre explique qu'une détection erronée suivie de l'invalidation d'identifiants internes du service a provoqué des erreurs 401 et 502 dans Codex connecté via ChatGPT. Cela n'établit pas la cause des erreurs de surcharge étudiées ici. Ne confondez pas un incident interne d'authentification officiellement expliqué avec ces erreurs de surcharge.

Cette investigation n'a changé ni modèles ni abonnements, n'a utilisé aucune réinitialisation payante et n'a supprimé aucun identifiant. Nous n'avons pas non plus envoyé délibérément des requêtes rapides et répétées pour reproduire le problème : nous n'avons donc pas de comparaison expérimentale des actions rétablissant le service. Nous distinguons les exemples d'incidents officiellement vérifiés des observations sur ce seul ordinateur.

Résumé : identifiez l'erreur avant de réagir

Si « Selected model is at capacity » apparaît, conservez votre demande, attendez un peu et vérifiez les incidents et l'utilisation. Si le travail est urgent, vous pouvez envisager un autre modèle disponible, mais certains incidents en touchent plusieurs. L'erreur de capacité seule ne justifie pas de dépenser davantage, d'acheter une réinitialisation payante ou de supprimer des identifiants.

Vérifiez l'authentification pour un 401, l'état du chat pour thread not found et l'utilisation pour un avis de limite. Noter l'heure, le message complet, le modèle et le quota restant lorsque l'erreur revient aide davantage l'investigation suivante que modifier les réglages sans connaître la cause.

Questions fréquentes

Cela peut-il arriver avec un abonnement Pro ?

L'utilisateur de cet article a signalé le même message avec un abonnement Pro. Un seul signalement ne permet toutefois pas d'établir des taux d'incidents par abonnement. Les fiches officielles n'indiquent pas que Pro en soit exempté. Vérifiez séparément le quota restant de l'abonnement et la capacité du modèle à accepter du travail à cet instant.

Des crédits supplémentaires ou une réinitialisation payante peuvent-ils résoudre le problème ?

Nous n'avons trouvé aucune preuve officielle que ces actions résolvent cette erreur de capacité. Les crédits supplémentaires et mécanismes similaires concernent votre propre quota. Vérifiez d'abord si vous avez réellement atteint une limite et ne confondez pas le rétablissement du quota avec celui du service après une erreur de capacité.

Pourquoi l'erreur revient-elle après un changement de modèle ?

Les incidents officiels décrivent le même message touchant plusieurs modèles. Son apparition avec un autre modèle ne prouve pas, à elle seule, un dysfonctionnement du PC ou du compte. Consultez les incidents et votre quota restant, puis notez le résultat des tentatives. La documentation publique n'identifie aucun modèle garantissant d'éviter cette erreur.

Faut-il redémarrer l'application ou ouvrir un nouveau chat ?

Nous n'avons pas pu établir que l'une ou l'autre action soit nécessaire. Elles peuvent aider à examiner une application ou un terminal sans réponse, mais ne garantissent pas de résoudre un problème de capacité du service. Vérifiez les autres travaux en cours et conservez votre demande, vos modifications et vos tâches restantes avant de décider.