Limitation hebdomadaire d’utilisation de Claude Code
(news.ycombinator.com)- Une limitation hebdomadaire d’utilisation est introduite pour le service Claude Code d’Anthropic
- Elle s’applique aux utilisateurs gratuits comme payants
- Les utilisateurs sont soumis à une limite hebdomadaire sur le nombre maximal de requêtes ou le volume de tokens traités
- Cette mesure vise à prévenir les abus du service et à garantir la stabilité des ressources système
- Les développeurs et les startups doivent faire preuve d’une vigilance accrue en matière de gestion des ressources lors de l’utilisation de l’API
Aperçu de l’introduction de la limitation hebdomadaire d’utilisation de Claude Code
Anthropic applique une nouvelle politique de limitation hebdomadaire d’utilisation au service Claude Code
- Une limite sur un certain volume de requêtes ou d’utilisation de tokens est définie pour l’ensemble des utilisateurs (gratuits comme payants)
- Cette limite est introduite afin de prévenir les abus, d’assurer une fourniture équitable du service et de garantir la stabilité des ressources d’infrastructure
- Le quota est réinitialisé chaque semaine, et en cas de dépassement, toute utilisation supplémentaire est impossible pour le reste de la semaine
Principaux impacts pour les développeurs et les startups
- Le recours à Claude Code dans le développement produit nécessite davantage de planification de l’usage
- Les services intégrés via API doivent mettre en place une logique de gestion automatisée ou d’alerte en cas de dépassement de limite
- En cas de génération de code à grande échelle, d’analyse ou d’appels répétés, l’importance de l’optimisation de l’utilisation des ressources augmente
Conclusion
- L’introduction de la politique de limitation hebdomadaire de Claude Code vise à améliorer la durabilité et la qualité du service
- Les startups et les professionnels de l’IT doivent vérifier ces limites hebdomadaires et planifier leur usage lors de l’intégration à leurs systèmes existants et de la conception de leurs services
1 commentaires
Avis Hacker News
Je pense que je n’atteindrai probablement pas la limite hebdomadaire, mais le fait que ce soit une limite à la semaine plutôt qu’une fenêtre de 36 heures, par exemple, me met mal à l’aise
Si on atteint la limite, on ne peut plus l’utiliser pendant le reste de la semaine
C’est pénible de ne pas pouvoir utiliser aussi longtemps un outil auquel on s’est habitué
Quelqu’un dira peut-être que je dépends trop de Claude, mais c’est pareil avec d’autres outils comme ripgrep
Ne pas pouvoir l’utiliser pendant quelques jours, ça va, mais une semaine, c’est trop long
Et le fait qu’ils aient dit que « moins de 5 % des utilisateurs » seulement seraient concernés saute aussi aux yeux
D’habitude, ce genre d’annonce dit que cela touche moins de 1 %, mais Anthropic dit qu’1 personne sur 20 dépassera la limite
C’est exactement la même sensation que la limite de 100 utilisations/semaine de o3 sur l’offre ChatGPT Plus
On ne peut même pas savoir combien on en a utilisé, donc comme c’est une ressource importante, on a instinctivement tendance à l’économiser
Au final, on n’exploite pas vraiment l’abonnement et on bascule vers des modèles comme o4-mini
Je préférerais une limite quotidienne
Mais peut-être que le but d’une limite hebdomadaire est justement de pousser les gens à se restreindre même en restant sous la limite
C’est triste de voir les développeurs devenir dépendants de services en ligne propriétaires
Avant, on pouvait tout faire avec des outils FOSS, sans devoir payer un abonnement mensuel à une entreprise ou à un service précis et en devenir dépendant
Aujourd’hui, certains ressemblent à des agriculteurs Monsanto, à payer chaque mois pour utiliser des outils au point d’oublier comment travailler sans eux
Avec sonnet, j’atteins souvent la limite Pro trois fois par jour
Si j’utilise Claude code et claude en même temps, c’est fini en 30 minutes
Et ça m’arrive sans faire tourner du multi-agent 24/7 ni ouvrir plusieurs fenêtres
Je ne pense même pas faire partie des 5 % d’utilisateurs les plus intensifs, mais voir ma limite se terminer le mercredi ne me surprendrait pas
Je commençais justement à vouloir davantage utiliser Claude Chat, mais si je ne peux pas lui faire confiance pendant plusieurs jours, ça ne sert à rien
Anthropic a dit qu’1 personne sur 20 tomberait sur la limite, mais je doute qu’il y ait tant que ça d’utilisateurs qui partagent leur compte ou fassent de l’automatisation 24/7
Si vous atteignez la limite, vous ne perdez pas l’accès pour toute la semaine, seulement pour le temps restant
Puisque vous dites vous-même que vous ne l’atteindrez probablement pas, si cela arrive, ce sera sans doute plutôt dans les 36 dernières heures de la semaine
Il y a aussi la possibilité de payer l’API
À long terme, je ne sais pas comment ça évoluera, mais je n’aime pas avoir l’impression que les LLM sont une ressource limitée chaque fois que je les utilise
Les gens se sont habitués aux offres illimitées
Le modèle tarifaire actuel donne une impression artificielle et inconfortable
L’illimité fonctionne bien pour tous les services « assez bon marché pour ne pas avoir besoin d’être mesurés »
Internet, les SMS, etc. peuvent se le permettre parce que leur coût direct est très faible
Mais les LLM ont encore un coût direct assez élevé à chaque exécution
Je ne suis pas d’accord avec l’idée qu’on devrait répartir son usage régulièrement sur tout le mois
En général, j’utilise peu pendant un mois entier, puis il m’arrive de concentrer l’usage sur quelques jours à raison de 11 heures par jour, et c’est là que je risque le plus de me heurter aux limites
C’est pour ça qu’utiliser directement l’API me paraît mieux, car la seule limite devient la profondeur de mon portefeuille
Avec quelque chose comme OpenRouter, on peut aussi éviter les contraintes du modèle par abonnement
En ce moment, Gemini 2.5 Pro me convient mieux que Claude pour le code
Je me demande aussi quelles autres options compétitives existent en termes de coût
https://docs.anthropic.com/en/api/rate-limits#rate-limits
À mon avis, il faudrait supprimer complètement ces outils qui donnent accès à une quantité limitée pour « 20 $ par mois », « 200 $ par mois », etc., avec des limites difficiles à calculer
Il faudrait passer entièrement à la facturation à l’usage pour être vraiment orienté utilisateur
On pourrait proposer un free tier du type 20 essais gratuits, puis une tarification par paliers pour augmenter progressivement le ratio, et faire payer les utilisateurs extrêmes au plus près du coût réel
Les utilisateurs à faible volume paieraient moins cher, tout en permettant de gagner des parts de marché
Si le prix est meilleur que chez OpenRouter, les gens resteront dans cet écosystème au lieu d’utiliser des outils tiers
Si l’outil est vraiment bon, les utilisateurs resteront même avec une tarification à l’usage
Le problème, c’est que les fournisseurs veulent à la fois subventionner les utilisateurs pour gagner des parts de marché, tout en empêchant les abus et les usages extrêmes
La solution à 100 %, c’est une facturation entièrement à l’usage, sans droit d’entrée
Mais dans ce cas, les commerciaux risquent de s’y opposer, car les gens qui s’abonnent mais utilisent peu y perdraient
Et cela rendrait aussi beaucoup plus facile de comparer et de passer d’une offre à l’autre, sans cette sensation d’être lié pour un ou deux mois
À long terme, je pense que les LLM locaux finiront par dépasser les meilleurs LLM cloud de 2025, de sorte que 99 % des tâches du quotidien seront traitées en illimité en local
Et qu’on ne se connectera au cloud que pour les vrais problèmes complexes
Les LLM vont continuer à progresser en efficacité, tandis que le coût des GPU, de la mémoire et du stockage va baisser et devenir plus accessible
Si cela paraît encore inconfortable aujourd’hui, c’est juste parce qu’on est dans une phase de transition
Même si c’est une ressource limitée, ça me conviendrait si je pouvais au moins savoir combien j’ai utilisé
Le fait de ne pas pouvoir suivre la progression est gênant
Je suis perdu sur la différence entre Max 5x et Max 20x
Dans mon e-mail, il est écrit que « la plupart des utilisateurs Max 20x peuvent utiliser Sonnet 4 entre 240 et 480 heures par semaine, et Opus 4 entre 24 et 40 heures »
Dans l’annonce officielle, il est dit que « la plupart des utilisateurs Max 5x peuvent utiliser Sonnet 4 entre 140 et 280 heures par semaine, et Opus 4 entre 15 et 35 heures »
J’aurais préféré que les limites soient au moins plus du double, en proportion du prix, mais pour Opus 4, l’écart n’est que de 5 à 9 heures
Ça ne devrait pas être au minimum le double ? On paie le double
Si c’est vraiment comme ça, je vais immédiatement redescendre du Max 20x vers un abonnement inférieur
En Australie, je paie 350 $ par mois
J’ai pris l’upgrade vers 20x parce que je tombais sans arrêt sur la limite d’Opus, mais maintenant je vois que la différence entre 20x et 5x est presque inexistante
C’est pour ça que j’ai arrêté MAX et que je suis redescendu à Pro, tout en utilisant o3 et d’autres modèles via l’API
Au départ, je n’avais pas besoin d’autant de temps, donc pour environ 10 $ par projet, je peux utiliser o3, Gemini et Opus
Comme de nouveaux modèles sortent tous les quelques jours, je ne veux pas être enfermé chez un seul fournisseur
En pratique, ce n’est pas que l’usage soit doublé, c’est surtout une priorité plus élevée quand il y a du trafic
Si le marketing ne correspond pas à la réalité, j’aimerais bien que quelqu’un fasse une vraie enquête avec des données et lance un recours collectif
Je comprends qu’à 200 $ par mois, ce ne soit toujours pas suffisant
Mais dans ce cas, il faut aussi proposer une offre suffisamment large pour qu’on puisse l’utiliser sans se soucier des limites
Il n’y a rien de pire qu’un message du type « temps écoulé ! » qui casse le flux de travail
À la rigueur, avec un système de crédits, on pourrait voir combien on a consommé et repayer si besoin
Mais l’idée d’« attendre pendant qu’on laisse refroidir les GPU » n’aide pas à la productivité
Si on fait tourner plusieurs agents, « 35 heures » est largement insuffisant
Et c’est étrange que l’outil lui-même soit conçu pour encourager ce type d’usage
Pour passer à une offre qui soit suffisante pour tout le monde tout en restant rentable, ils risquent au contraire de voir tout le monde partir chez la concurrence
Il est peut-être plus stratégique de rendre les utilisateurs dépendants de l’outil puis d’augmenter progressivement les prix
Je ne pense pas que « faire tourner plusieurs agents » soit un cas d’usage normal pour une offre individuelle
Dans ce genre de cas, il a toujours fallu payer l’usage directement via l’API
Le fait que l’offre fixe l’ait permis relevait déjà d’une certaine générosité, et le service a toujours parlé de « limites plus élevées », pas d’« illimité »
L’API offre des limites bien plus souples, pratiquement sans restriction en pratique
Claude est aussi disponible sur Aws et gcp, avec des limites, des crédits et des tarifs différents selon les plateformes
Il faut optimiser la politique pour les « bons utilisateurs », pas pour les « mauvais utilisateurs »
Il suffit d’utiliser l’API
Globalement, je pense que c’est une évolution positive qui protège le système lorsque certains utilisateurs font tourner de nombreux agents 24/7
Cela permet à un plus grand nombre d’utilisateurs de continuer à s’en servir de manière stable
En revanche, le fait de ne pas afficher « combien d’usage il reste » est gênant
Je ne sais pas à quel pourcentage j’en suis, mais avoir au moins des alertes intermédiaires, par exemple à mi-parcours, aiderait à mieux planifier
Le fait qu’ils ne fournissent pas cela donne l’impression qu’« ils ne veulent pas qu’on puisse mesurer »
Je ne veux pas suivre ça au millimètre, juste savoir approximativement où j’en suis
D’après le compte Reddit d’Anthropic
un utilisateur a consommé pour plusieurs dizaines de milliers de dollars de LLM avec une offre à 200 $
L’entreprise développe une solution distincte pour les utilisateurs avancés
Mais les nouvelles limites visent désormais à offrir une expérience plus équitable et à empêcher le partage de compte et la revente
C’est pour ça qu’on ne peut pas avoir de « bon service »
La startup où je travaillais proposait autrefois une option illimitée
Au début, on pensait que personne ne pourrait vraiment autant l’utiliser, mais en pratique il y avait énormément d’utilisateurs très créatifs pour pousser le service dans ses retranchements
Certains comptes restaient branchés 24/7 au service et envoyaient des requêtes en permanence jusqu’à 95 % des limites autorisées
Ils utilisaient aussi différentes IP, avec des schémas qui ne ressemblaient pas à un usage humain
Au début, on a pris ça pour quelques valeurs aberrantes, mais quand ce type de comptes a augmenté de façon exponentielle, on s’est rendu compte qu’il s’agissait en fait de plusieurs entreprises qui créaient de multiples comptes pour faire du load balancing
Quand on regarde les graphiques moyens profit/perte par utilisateur, ces comptes ne faisaient qu’accumuler des pertes énormes tout en consommant les ressources au maximum, ce qui a fini par provoquer un changement de politique
On perd ce genre de « clients », mais la plupart des utilisateurs ordinaires ne sont pas affectés
Au contraire, l’ensemble du service devient plus fluide
C’est une expérience que toutes les startups à fort volume finissent par connaître
Il est possible qu’en réalité l’entreprise vende le service à perte
Les limites actuelles ne suffisent-elles pas déjà à bloquer ce type d’abus ? J’ai du mal à comprendre
Quelqu’un s’en vantait hier sur Twitter
Il disait avoir consommé 13 200 $ avec un compte à 200 $, en faisant tourner 4 à 5 agents dédiés à Opus 24/7 avec des appels récursifs entre eux
Ça, c’est clairement de l’abus, et ça mérite d’être ciblé
Mais je ne vois pas très bien comment un fournisseur d’inférence est censé empêcher ça
Cursor applique déjà une prime tarifaire plus forte qu’Anthropc/OpenAI, ce qui rend la situation encore plus difficile
Anthropic est dans une situation similaire, mais sans option premium ici
Si on autorise 20 $ par mois jusqu’à 500 $ de coût réel, cela revient à offrir 95 % de remise, et une telle structure ne peut jamais tenir
À force de subventionner de cette manière, on renforce dans la communauté un sentiment de « droit acquis »
On a l’impression qu’on nous retire quelque chose auquel on s’était habitué, mais en réalité, rien qu’avec les capex/opex, c’est déjà intenable, sans même compter les coûts de R&D, donc le maintien du modèle lui-même devient difficile
Au final, concrètement, il ne reste plus qu’à « continuer à modifier la structure tarifaire et laisser les utilisateurs partir vers l’entreprise qui les subventionnera davantage la prochaine fois »
Ils auraient mieux fait de présenter dès le départ ce type de politique comme un essai, en expliquant de façon transparente le niveau de subvention engagé
Les gens auraient pu tester le modèle, certains seraient restés, et même s’il y avait eu un peu de churn, il y aurait eu moins de mécontentement
S’ils publiaient vraiment de manière transparente la structure capex/exploitation/développement
les gens comprendraient sans doute que cela revient grosso modo au coût d’un senior engineer infatigable
Cet e-mail aurait été bien plus utile s’il avait indiqué, mois par mois, « à quels moments la limite a été atteinte » (août 2024, janvier 2025, mai 2025, etc.)
Je n’ai aucune idée de savoir si je fais partie des 5 % du haut
En réalité, je peux comprendre une limite à 1 %, mais dans le SaaS, 5 %, c’est déjà une grande partie des vrais utilisateurs
Ce type de service a besoin d’une tarification au compteur
Toutes les entreprises d’IA se heurtent au même problème
La souscription à prix fixe repose sur l’idée que l’utilisateur ne fasse pas attention aux coûts
Mais une toute petite minorité de power users pousse les limites de l’abonnement à l’extrême
Des services comme Terragon ont même été développés séparément pour optimiser cet usage
Du coup, les entreprises abaissent continuellement les limites, et les utilisateurs se mettent au contraire à surveiller encore plus leurs coûts
Cursor a déjà ajusté ses limites plusieurs fois, et Anthropic suit maintenant la même voie
Au final, ils ne veulent simplement plus subventionner les 10 % d’utilisateurs les plus extrêmes
J’aimerais qu’il existe une offre web à tarification au compteur directement utilisable depuis l’interface
L’API existe déjà, donc on peut générer soi-même des tokens et utiliser directement Claude Code sans abonnement séparé
Ça me rappelle l’époque de l’hébergement mutualisé des années 1990
Proposer une offre web à l’usage obligerait à révéler à quel point le support de l’inférence coûte réellement cher
Faire tourner de l’IA aujourd’hui à un niveau de productivité réel reste encore extrêmement coûteux
C’est à cause de « l’usage avancé qui consiste à faire tourner Claude 24/7 en arrière-plan » qu’on ne peut pas avoir un bon service
Les services d’IA font pourtant leur publicité en disant que « l’IA fait le travail toute seule ; le développeur peut aller boire un café ou dormir pendant qu’elle avance » ; il y a donc des développeurs qui ont simplement utilisé le service comme il était vendu
Leur reprocher ensuite ce comportement, c’est étrange
Ce passage m’a fait rire
On dirait une sorte de « destructeur du monde bien intentionné » essayant d’accélérer encore davantage la mort thermique de l’univers
Je pense que ce problème était parfaitement prévisible
Il a forcément été pris en compte dès la définition initiale des tarifs
Ils ne voulaient simplement pas retarder le lancement, donc la mise en place a été repoussée, et maintenant ils l’appliquent en se confrontant au réel
Quelle que soit la manière dont on fixe le prix d’un abonnement, les utilisateurs essaieront d’en tirer 100 %
Je suis moi-même abonné Max et je tombe souvent sur la limite
Le simple fait qu’une limite s’applique alors que je ne fais qu’utiliser ce que j’ai payé me semble déjà étrange
C’est exactement le fonctionnement d’une expérience de pricing
Tant que les garde-fous sont faibles, des utilisateurs extrêmes finissent toujours par apparaître, et l’entreprise présente comme soutenable quelque chose qui ne l’est pas, avant de retirer plus tard les bonus qu’elle avait accordés
C’est peut-être une idée à côté de la plaque, mais je me demandais ce qu’on pourrait faire avec des limites adaptatives
Option 1 : permettre au départ des pics d’usage très intenses sur de courtes périodes, puis ralentir progressivement, avant d’autoriser à nouveau un pic après un cooldown
Cela permettrait à l’utilisateur de maximiser brièvement sa productivité tout en laissant aussi le temps aux serveurs de respirer
Option 2 : comme avec les données mobiles, un volume de requêtes utilisable à pleine vitesse, puis un throttling, avec la possibilité d’acheter davantage si besoin
Ce serait aussi un modèle qui génère du revenu supplémentaire
Option 3 : une allocation adaptative des ressources au niveau de l’infrastructure et du réseau
Les tâches qui ne mobilisent pas de GPU pourraient être dépriorisées, les requêtes réseau traitées plus lentement, ou réparties sur différents serveurs en fonction de l’usage via k8s, etc.
Et au-delà de la discussion sur les limites, il faudrait aussi tracer quelles requêtes coûtent réellement le plus cher, puis corriger les chemins de code ou les structures d’infrastructure inefficaces, ce qui pourrait redonner de la marge
Je souligne qu’une petite optimisation de code peut déjà apporter une grande respiration à l’ensemble du système