Google Antigravity passe du gratuit à 275 € par mois

En novembre 2025, Google Antigravity débarquait avec une promesse simple : un IDE “agent-first” pour déléguer des tâches à des agents autonomes. Trois mois plus tard, dans la communauté, l’enthousiasme a laissé place à une colère très concrète : des quotas réduits, puis des lockouts de 7 jours, et enfin des tarifs qui grimpent jusqu’à 275 € par mois pour un accès “haut volume”. Ce basculement fait passer un outil présenté comme pratique à un sujet de stratégie budgétaire et de sécurité de facturation cloud.

À retenir

• Google Antigravity a été lancé en novembre 2025 en Public Preview
• Le plan AI Pro a mené à un “Bait and Switch” : quotas réduits et lockout de 7 jours
• L’accès “constant et à haut volume” passe par l’AI Ultra Plan à 249,99 $ HT
• Les Crédits AI et la facturation à l’usage rendent la dépense plus difficile à prévoir
• Des développeurs se tournent vers des alternatives et des garde-fous comme le Model Context Protocol (MCP)

Pourquoi maintenant : l’effet “appâter puis réduire” autour de Google Antigravity rebat les cartes de l’IDE agentique pour les développeurs. Les changements, d’abord discrets, ont abouti à des projets bloqués et à une hausse nette des coûts d’accès “pro”. L’enjeu concerne surtout ceux qui automatisent en continu et veulent éviter une facturation cloud imprévue, bien plus que l’utilisateur occasionnel.

De la public preview généreuse au plan pro “suffisant”… puis trop juste

Le lancement de Google Antigravity a démarré sur un tempo rassurant : en novembre 2025, la plateforme “agent-first” a été proposée en Public Preview gratuite, avec des quotas décrits comme généreux. Pour beaucoup de développeurs, c’était l’occasion de tester un nouvel IDE sans se soucier immédiatement de la ligne de facture.

Gemini 3 intégré nativement : l’accélérateur qui a attiré les développeurs

À ce stade, la promesse tenait en trois éléments : un IDE orienté “agents”, des quotas jugés confortables et une intégration native de Gemini 3. Dans cette phase d’adoption, les développeurs ont surtout vu un gain de confort : déléguer des tâches complexes sans bricolage d’outils externes. Le produit se positionnait clairement pour ceux qui codent vite et préfèrent orchestrer la délégation plutôt que tout faire “à la main”.

Le cap tarifaire à 22 € / mois : “pour les développeurs quotidiens”

Ensuite, Google a introduit un plan AI Pro situé autour de 22 € à 29 € par mois. Le message était direct : cette formule devait suffire pour un usage “quotidien” de la délégation. Dans le même temps, les limites étaient annoncées comme gérées avec un rafraîchissement toutes les 5 heures. Sur le papier, cela rendait la gestion des quotas de jetons plus prévisible pour un flux de travail en journée.

Le mécanisme du Bait and Switch : quotas réduits et lockout de 7 jours

Le basculement commence quand les utilisateurs constatent un changement de règles sans véritable période de transition. C’est à ce moment que l’expression “Bait and Switch” apparaît dans les discussions entre développeurs.

Des quotas de jetons réduits “silencieusement”

Selon des retours relayés par la communauté, notamment via des discussions sur les forums de Google et sur Reddit (r/google_antigravity), les utilisateurs du plan Pro auraient vu leurs quotas, auparavant jugés suffisants, être fortement réduits. Le grief principal ne porte pas seulement sur la baisse elle-même, mais sur le fait que la modification serait arrivée sans prévenir. Pour les développeurs, cela revient à perdre la calibration initiale du temps et des cycles d’agent, donc à toucher directement la productivité.

Le verrouillage : une punition après épuisement

Le point le plus dur concerne la suite : une fois la limite atteinte, les utilisateurs subiraient un verrouillage de 7 jours. Concrètement, l’outil deviendrait inutilisable pour le reste de la semaine de travail, sauf à payer davantage. Ce mécanisme déplace l’enjeu de “consommation” vers un risque opérationnel : rater une échéance parce que le système de quotas impose une indisponibilité temporaire.

« Au lieu d’ajuster, ils ont changé les quotas et laissé tomber les explications. »
Un développeur sur les forums communautaires, après les changements de quotas.

Quand le “pro” devient ultra : montée en gamme, AI Ultra Plan et crédits

Après la séquence Pro, la logique tarifaire devient plus verticale : pour accéder à un usage “constant et à haut volume”, Google pousserait vers l’AI Ultra Plan et vers un modèle plus proche de la consommation à la demande. La promesse ne porte plus seulement sur l’IDE, mais sur l’accès prioritaire à des modèles considérés comme plus puissants.

De 22 € à 275 € : AI Ultra Plan à 249,99 $ HT

Le plan AI Ultra serait facturé 249,99 $ HT, soit environ 275 € TTC selon les régions, avec un objectif clair : servir les profils qui ont besoin de volume. Dans ce cadre, l’accès viserait des modèles plus complexes, cités dans les sources comme Gemini 3.1 Pro High et Claude Opus 4.6. Pour un développeur, l’écart de prix ne se limite pas à la ligne de facture : il redéfinit la capacité à exécuter des agents sur des sessions longues sans escalade brutale de coûts.

Crédits et facturation à l’usage : une facture moins lisible

Parallèlement, un système de Crédits AI aurait été instauré : selon la source, 25 $ pour 2 500 crédits. L’effet est celui d’une facturation à l’usage : au lieu d’un forfait stable, la dépense s’ajuste à la consommation réelle des jetons. Pour les équipes, cela change la planification : budgéter un projet devient plus complexe quand les coûts dépendent de l’intensité d’exécution des agents, y compris quand des limites se déclenchent en pleine semaine.

Conséquences sur le travail et réactions : transparence, notifications et alternatives

La facture n’est pas le seul problème mis en avant par les utilisateurs. Ce qui revient le plus dans les témoignages, c’est la rupture en plein milieu d’une session de codage, au moment où les agents sont les plus sollicités.

Projets bloqués en pleine session de codage

D’après les retours collectés sur des espaces de discussion (forums de Google et Reddit), des développeurs auraient été bloqués en pleine tâche, au moment où ils avaient besoin d’agents pour finaliser une partie critique. Le point sensible est temporel : si le rafraîchissement des quotas était décrit à toutes les 5 heures au départ, une attente d’une semaine serait devenue possible sans notification préalable. Dans un usage d’IDE agentique, un changement d’état “bloquant” transforme la planification technique en planification de risques.

Manque de transparence : justification et perception d’intention

Google aurait justifié ces variations par une “évolution des plans IA”. Mais, côté communauté, la lecture dominante parle de stratégie : forcer la montée en gamme financière en rendant l’usage du niveau intermédiaire plus coûteux ou plus instable. Cette perception en touche une autre, plus large que le simple prix : la confiance. Quand l’outil change de régime sans signal clair, les développeurs cessent de considérer la plateforme comme un service maîtrisable.

N’est-ce pas simplement un ajustement de coûts ?

Une objection légitime existe : l’augmentation du coût des modèles et l’ajout de capacités plus haut de gamme peuvent justifier des limites plus strictes, et Google peut considérer ces changements comme une normalisation. Mais, dans les retours relayés, le reproche central reste la combinaison “réduction + verrouillage + faible préavis”. Même en acceptant l’ajustement tarifaire, l’absence de transparence et de notifications rend l’impact opérationnel bien plus difficile à absorber.

Quelles options pour éviter les surprises de facturation cloud

Face à cette instabilité, certains développeurs changent de stratégie : remplacer l’outil ou réduire la dépendance au cloud sous-jacent. L’objectif est double : contrôler la dépense et éviter les blocages soudains en pleine semaine de production.

Cursor, Windsurf et Claude Code : chercher des limites plus prévisibles

Les sources indiquent que des développeurs se tournent vers des alternatives comme Cursor, Windsurf ou Claude Code (notamment via CLI). L’idée avancée est simple : trouver des modèles ou des environnements jugés plus transparents sur les limites de consommation. L’objectif n’est pas seulement d’économiser, mais de réduire l’incertitude sur la capacité à terminer une session de travail.

Mettre des garde-fous : kill switches et Model Context Protocol (MCP)

Côté pratiques, des développeurs recommandent de configurer des kill switches de facturation pour stopper en cas d’emballement des dépenses. Les sources évoquent aussi l’usage du Model Context Protocol (MCP) pour privilégier des modèles locaux, afin d’éviter que des factures cloud ne s’enclenchent de façon inattendue via les services sous-jacents. L’enjeu est de reprendre la maîtrise du “coût par session”, surtout lorsque des agents enchaînent des tâches en arrière-plan.

« Les utilisateurs ne veulent pas seulement moins payer, mais moins subir. »
Une lecture récurrente dans les échanges communautaires sur la maîtrise opérationnelle.