« Rate limit exceeded » après deux prompts sur Copilot Pro+ (ou un plan payé), c’est le genre de truc qui te fait perdre du temps pour de mauvaises raisons. Tu vas réduire ton contexte, réécrire tes prompts, soupçonner ton repo, ton VPN, ton extension… alors que parfois, c’est juste un throttling côté service ou un souci de compte.
L’objectif ici est simple et un peu “anti gaslighting” : te donner un protocole de preuve. Pas un débat. Une méthode pour isoler rapidement si tu es face à un quota réel, un bug d’account, un client (IDE) qui spam sans te le dire, ou un incident plus large. Et, surtout, comment continuer à bosser sans empirer le truc.
Le vrai problème : « rate limit exceeded » ne dit pas qui est coupable
Le message est traître parce qu’il mélange plusieurs réalités. Un rate limit peut être un vrai quota (mensuel, journalier, par modèle, par fonctionnalité), un limiteur anti-abus qui s’active sur des bursts, ou une dégradation du service qui finit par te renvoyer des 429 un peu partout. Et toi, côté dev, tu reçois une phrase identique quel que soit le scénario.
Ce que tu veux, ce n’est pas “une astuce pour que ça remarche chez toi par magie”. Tu veux une explication falsifiable. Un truc que tu peux reproduire proprement, comparer entre environnements, et utiliser pour ouvrir un ticket qui ne finira pas au cimetière des « have you tried turning it off and on again ».
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Reproduction propre : la preuve en 5 minutes (et sans ton gros repo)
Premier réflexe : enlever tout ce qui peut polluer. Un repo énorme, des dizaines de fichiers ouverts, un agent qui tourne, des suggestions inline qui partent toutes seules… ça brouille le diagnostic. Donc tu te fabriques une repro “stérile”.
Concrètement, je fais un dossier vide, un fichier vide, et je lance des prompts volontairement courts et identiques. Pas une discussion longue, pas une demande qui force l’analyse de 2000 lignes. Un truc du style « Donne une fonction TypeScript qui fait un debounce » ou « Explique ce message d’erreur en 2 phrases ». Si tu te fais throttle après 1–2 prompts sur ça, tu viens déjà de prouver que ce n’est probablement pas ton contexte projet.
Deuxième étape : tu changes une variable à la fois. Même compte GitHub, mais autre machine. Ou même machine, autre connexion (partage 4G). Ou même connexion, mais navigateur au lieu d’IDE. L’idée n’est pas de “tester plein de trucs”. L’idée est de produire un résultat binaire : ça suit ton environnement ou ça suit le service / ton compte.
Quota réel vs incident service : les signaux qui ne trompent pas (souvent)
Un quota réel, en général, a des caractéristiques stables. Tu te fais limiter de façon prévisible, après une certaine consommation. Tu peux attendre un peu, ça revient. Ou ça revient à la fenêtre suivante. C’est chiant, mais ça ressemble à une règle.
Un incident ou un throttling “service-wide”, ça ressemble plutôt à un mur. Tu es limité très tôt, parfois dès le premier échange. Le délai d’attente suggéré ne change rien. Tu peux switcher de modèle, de client, ça continue. Et surtout, tu vois des retours similaires dans la communauté au même moment. À ce stade, ton job n’est pas de trouver un hack. Ton job, c’est de capturer des preuves et de passer en mode dégradé.
Entre les deux, il y a le cas “bug de compte / entitlements”. Là, tu peux avoir un plan payé mais un accès effectif qui part en vrille. Typiquement, ça se manifeste par des comportements incohérents selon le client (Copilot web ok, IDE non, ou l’inverse), ou selon le type de requête (complétion ok, chat rate-limit instant).
Les tests qui isolent la cause : modèle, contexte, parallélisme, IDE vs web
Le piège moderne, c’est que Copilot n’est plus “une seule requête quand tu appuies sur Entrée”. Tu as des features qui parallélisent : suggestions inline en continu, chat, analyse de workspace, commandes “agent”, etc. Résultat : tu crois envoyer 2 prompts, mais en pratique ton poste en envoie 20. Et le rate limit tombe… logiquement.
Donc oui, tester “le même prompt” est utile, mais il faut aussi tester “le même prompt avec moins de bruit”. Désactive temporairement ce qui peut générer des requêtes en arrière-plan, ou mets-toi dans une situation où seule l’action explicite (ton prompt) déclenche l’appel.
Ensuite, compare IDE vs web. Si le web (Copilot Chat sur github.com, ou une interface officielle) fonctionne normalement mais que ton IDE rate-limit instant, tu n’es probablement pas sur un quota global “dur”. Tu es peut-être sur un souci de client, de session, de token, ou de plugin qui spam. À l’inverse, si tout rate-limit (IDE, web, autre machine), ça sent le problème côté service ou côté compte.
Dernier test simple : réduire brutalement le contexte. Ferme des fichiers, coupe l’indexation/scan si tu peux, et évite les prompts qui “embarquent le repo”. Si ça change tout, tu avais peut-être un scénario où l’IDE envoyait des payloads plus gros ou plus fréquents que tu ne l’imaginais. Si ça ne change rien, ça renforce la thèse du throttling externe.
Ce que je regarde côté IDE : logs, codes d’erreur, et “combien de requêtes je génère vraiment”
Quand ça rate-limit, tu veux deux choses : le message exact (pas ton souvenir), et un identifiant corrélable côté support (request id, trace id, timestamp). Sans ça, tu vas tourner en rond.
Dans VS Code, Copilot expose des logs. Je ne te dis pas de devenir SRE. Juste de prendre 2 minutes pour ouvrir les logs Copilot au moment où l’erreur arrive, et noter ce que tu vois. Si les logs montrent une rafale de requêtes rapprochées, ce n’est plus un débat : ton client envoie trop, ou le service est tellement tendu qu’il limite agressivement.
# Exemple bête mais efficace : chercher l’erreur dans les logs exportés
# (après avoir ouvert/collecté les logs depuis l’IDE)
grep -R "Rate limit" -n ./copilot-logs
Si tu es sur JetBrains, même idée : trouve le log Copilot / AI Assistant, capture l’heure, et surtout la répétition. Ce qui aide beaucoup, c’est de pouvoir dire : « à 14:12:03 j’envoie un prompt de 12 mots, réponse 429, retry-after ignoré, et ça se reproduit à l’identique sur une autre machine ». Là, tu n’es plus dans l’impression, tu es dans le factuel.
Mitigations pendant l’incident : continuer à livrer sans spammer (et sans te saboter)
Quand tu sens que le service est en train de te limiter, le pire truc à faire, c’est le réflexe humain classique : cliquer plus vite, relancer, réessayer, ouvrir un nouvel onglet, changer trois fois de modèle. Tu te fabriques toi-même un profil “abuse” et tu t’enfermes dans le throttling. Si tu veux retrouver un service utilisable, tu dois ralentir et serialiser ton usage.
Ce qui marche bien en mode dégradé, c’est le workflow “spec-first”. Tu écris une intention courte et stable (le comportement attendu, les cas limites), puis tu demandes des sorties plus petites. Moins de prompts “gros blocs” qui tentent de tout faire d’un coup. Plus de demandes ciblées. Tu peux même garder un fichier local avec tes prompts prêts, pour éviter le spam de reformulation.
Et si tu dois vraiment avancer, accepte l’idée que Copilot redevient un assistant ponctuel. Pour le reste, tu bascules sur tes réflexes de dev : tests, documentation, recherches ciblées, et un peu de discipline. Ce n’est pas glamour, mais ça te sauve la journée.
Ouvrir un ticket utile : ce qu’il faut capturer pour arrêter de “parler dans le vide”
Un ticket support “Copilot rate limit exceeded” sans contexte, c’est un ticket mort. Ce qui fait la différence, c’est la précision. Note l’heure et le fuseau. Note le client (VS Code version, extension Copilot version, JetBrains version). Note si tu es derrière un VPN ou un proxy. Note le modèle sélectionné si tu peux le voir. Copie le message exact. Et surtout, donne une repro minimale : « repo vide, prompt court X, rate-limit après N tentatives ». Si tu peux fournir un extrait de log avec un identifiant de requête, tu viens d’augmenter tes chances d’une réponse utile d’un facteur énorme.
Et oui, c’est frustrant d’avoir à faire ça sur un produit payé. Mais c’est aussi comme ça que tu évites de te faire balader avec des réponses génériques, parce que tu arrives avec un diagnostic déjà bien isolé.
Mon avis : traite Copilot comme un service externe, pas comme une extension “magique”
Copilot, surtout dans ses offres récentes, ressemble de plus en plus à une plateforme : plusieurs modèles, plusieurs surfaces (IDE, web), plusieurs features qui appellent en parallèle. Donc il faut le gérer comme un service externe. Quand ça casse, tu fais du triage. Tu isoles. Tu passes en mode dégradé. Tu loggues. Tu évites de spammer.
Le gain, c’est que tu reprends la main. Tu arrêtes de douter de ton code ou de ton cerveau, et tu sais dire clairement : « là, c’est le service », ou « là, c’est mon setup qui envoie trop ». Et rien que ça, ça te fait gagner une demi-journée à chaque incident.
