AIREITERCinquante millions de lignes de Lean 4 pour une seule preuve, 800 000 lignes de Rust sûr produites en deux semaines, des noyaux TPU 4,09 fois plus rapides : la mise à jour de recherche publiée par Google le 13 novembre donne une idée du potentiel d’Antigravity Teamwork. Mais dans la pratique, le mode ne devient intéressant que pour des projets structurés en jalons et capables de tourner pendant des heures, voire des jours. Une seule exécution peut en effet consommer une part importante du quota hebdomadaire.
Ce qu’est réellement Antigravity Teamwork
Antigravity Teamwork est le workflow d’orchestration multi-agents de Google pour les tâches volumineuses et fortement vérifiées dans Antigravity. La commande /teamwork lance une équipe coordonnée — Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor et Success Auditor — qui découpe le travail en jalons, opère dans un répertoire de projet dédié et soumet chaque étape à une vérification indépendante.
Le fonctionnement se déroule en deux temps. La première phase consiste en un entretien de cadrage : l’agent principal consigne les objectifs, les exigences, les méthodes de vérification, les critères d’acceptation et le répertoire du projet (par défaut ~/teamwork_projects/{PROJECT_NAME}). La seconde correspond à l’exécution autonome, pilotée par des artefacts structurés — demande, plan de projet et rapports d’avancement — avec une propriété exclusive des fichiers pour chaque Worker. Les rôles Critic, Challenger, Auditor et Success Auditor valident ensuite les étapes avant leur transmission (documentation Teamwork).
Le mode d’intégrité choisi pendant l’entretien détermine le niveau d’exigence :
development(par défaut) : itérations rapides ; la réutilisation de code et les frameworks sont autorisés, mais les résultats inventés et les implémentations de façade sont refusés.demo: présentation reproductible ; il est interdit de copier la logique centrale d’un projet open source, de sous-traiter le travail principal ou de consulter le code des tests pour trouver les réponses.benchmark: niveau de rigueur maximal ; l’implémentation doit être réalisée depuis zéro avec la bibliothèque standard du langage, puis évaluée indépendamment à partir d’une vérité de référence.
Les chemins d’exécution adaptent automatiquement la composition de l’équipe :
- General distributed coding (par défaut) : développement multi-fichier et refactorisation.
- Iterative coding : correction ciblée lorsque la consigne demande de « rester simple ».
- Document Review : analyse critique d’articles et de documents de conception sous plusieurs angles.
- Math / Proof et Math / Proof Large Team : raisonnement formel et campagnes de résolution de conjectures à grande échelle.
Sur les offres payantes, dans l’application et la CLI Antigravity, Teamwork vise généralement des travaux qui s’étendent sur plusieurs heures ou plusieurs jours (documentation Teamwork).
Teamwork, Swarm, Boost et les subagents : lequel choisir ?
Antigravity Teamwork n’a de sens que si la tâche exige des jalons, des points de contrôle et un répertoire dédié. Pour la majorité des besoins quotidiens, les options plus légères suffisent — et un mauvais choix peut faire partir du quota en fumée.
| Outil | À privilégier pour | Lancement | Espace de travail | Vérification | Durée typique | Offre |
|---|---|---|---|---|---|---|
| Subagents | Tâches annexes ciblées : étude d’un dépôt, vérifications dans le navigateur, exécution de tests | Automatique ou @subagent | Espace de travail courant | L’agent parent vérifie la réponse | De quelques secondes à quelques minutes | Toutes les offres |
Boost (/boost) | Problèmes difficiles mais circonscrits : conditions de course, bugs complexes, algorithmes | /boost <task>, démarrage immédiat | Espace de travail courant, contextes isolés | Les Workers se challengent et revérifient leur travail ; l’orchestrateur effectue des contrôles ponctuels | De quelques secondes à quelques heures | Offres payantes |
Swarm (/swarm) | Travail large qui se découpe proprement : fichiers, packages, suites de tests | /swarm <task>, démarrage immédiat | Espace de travail courant ou copies propres à chaque Worker | Un @verifier dédié examine les différences et lance les tests | De quelques minutes à quelques heures | Google AI Pro et Ultra |
Teamwork (/teamwork) | Projets à plusieurs jalons : migrations, simulations, preuves formelles | /teamwork <goal> + entretien de cadrage | ~/teamwork_projects/{PROJECT_NAME} dédié | Les rôles Critic, Challenger, Auditor et Success Auditor valident les étapes | De plusieurs heures à plusieurs jours | Offres payantes |
Teamwork convient par exemple à une migration REST vers Fastify répartie sur plusieurs dizaines de fichiers, avec couverture de tests complète, à un simulateur cycle-accurate validé par rapport à des timers matériels, ou à une preuve formelle vérifiée avec Lean 4. Pour ajouter une validation à trois gestionnaires d’API indépendants, mieux vaut Swarm : un Worker par fichier et un vérificateur qui exécute npm test. Boost sera plus adapté à une seule condition de course ou à une refactorisation couplée, lorsque la séquence challenge-correction-vérification est préférable au travail en parallèle. Quant aux subagents, ils sont parfaits pour effectuer des recherches en arrière-plan pendant que la conversation principale continue.
La confusion est compréhensible. Comme l’expliquait un utilisateur d’Antigravity :
« agy a désormais beaucoup trop de modes et, honnêtement, ça devient confus. Pour l’instant, on a ... /teamwork (projets longs structurés en jalons avec points de contrôle) ... et maintenant les workflows dynamiques... Pour être juste, on n’a vraiment pas besoin de tout ça. Moins de modes, c’est moins de confusion... »
— @Heamanth_alturi (X)
La règle simple : si la tâche a une seule définition du résultat attendu et se termine en une session, Teamwork est disproportionné. En revanche, si elle nécessite un artefact de planification, un artefact de suivi et la validation de chaque jalon par quelqu’un d’autre que son auteur, Teamwork est dans son élément.
Ce que la mise à jour de recherche de novembre a vraiment démontré
La mise à jour de Google Research du 13 novembre présente des résultats, pas une annonce de lancement. Teamwork existait déjà sous le nom de /teamwork-preview pour les offres payantes ; cette publication documente ce que des équipes organisées autour de jalons ont accompli avec Gemini 4 Argon, Carbon et Hydrogen. Les humains ont continué à définir les problèmes, les contraintes et les protocoles d’évaluation, tandis que de nouveaux agents jouaient le rôle de critiques depuis des contextes vierges.
| Domaine | Projet exemple | Échelle de l’équipe | Résultat rapporté |
|---|---|---|---|
| Mathématiques | Preuve de la conjecture de Courtade–Kumar (Google, CUHK, USC, CMU) | Approche adaptée aux preuves longues, formalisation en Lean 4 | Preuve complète en environ 50 millions de lignes de code Lean |
| Chimie | Structure moléculaire à partir de données RMN | 30 agents spécialisés + simulateur physique | 95 % de correspondance exacte dans le top 1, 100 % dans le top 3 |
| Systèmes | Réécriture de Zircon de C++ vers Rust | Campagne Argon menée sur deux semaines | Environ 800 000 lignes de Rust sûr, avec démarrage sur arm64 |
| Matériel ML | Optimisation de noyaux TPU (DuoDiscover) | Évaluateurs proxy (23 s contre 7 à 32 min) | Accélération moyenne de 4,09 fois sur 17 noyaux JAXBench |
Google a également ouvert les candidatures à 10 000 chercheurs universitaires, qui peuvent obtenir six mois d’accès haut de gamme. Certains workflows mentionnés dans l’article sont encore en cours de déploiement auprès des utilisateurs externes : considérez donc ce tableau comme une démonstration des capacités, et non comme la garantie que chaque projet reproduira ces gains.
Le coût en quota que les pages officielles ne montrent pas
La page tarifaire d’Antigravity présente l’offre Individual à 0 $/mois, avec des complétions Tab illimitées et des limites hebdomadaires de base, ainsi que les offres Pro et Ultra, qui proposent des limites plus élevées et un pool flexible de crédits IA. Le nombre exact de requêtes n’est pas publié. Les quotas Pro et Ultra sont renouvelés toutes les cinq heures jusqu’à atteindre le plafond hebdomadaire ; en cas de dépassement, des crédits achetés peuvent prendre le relais selon un réglage Never ou Always (documentation des offres). Teamwork et Boost nécessitent une offre payante ; Swarm exige Pro ou Ultra (documentation Swarm). Dans son propre article sur l’OS, Google avertissait que quelques tâches complexes en préversion pouvaient consommer un quota hebdomadaire entier (article sur l’OS Antigravity).
Les retours d’utilisateurs, qui restent anecdotiques et ne constituent pas un échantillon représentatif, vont d’une consommation raisonnable à une véritable hémorragie :
« nom de dieu, ça m’a vidé tout mon quota en à peine 5 minutes (3.5 Flash (high)) »
— u/Several_Bag_3665 (Reddit)
« très utilisable avec l’abonnement ultra, en fait. J’ai lancé une préversion de teamwork avec gemini flash medium pendant 50 minutes d’affilée et ça n’a pris qu’environ 20 % de mon quota de 5 heures, tout en réalisant correctement d’énormes refactorisations »
— u/ningkaiyang (Reddit)
Deux mécanismes expliquent cet écart. Pour /swarm, Antigravity précise que chaque Worker est un agent distinct, que les Workers en attente ne consomment aucun token et que ceux qui ont épuisé leur quota se mettent en pause au lieu de réessayer automatiquement, jusqu’à la publication d’un nouveau message sur le tableau, au changement de modèle ou à l’envoi d’un message direct (documentation Swarm). La documentation Teamwork ne publie pas la même règle de reprise : considérez donc ce comportement comme une caractéristique possible du fonctionnement multi-agent, à vérifier selon votre offre. Teamwork produit également de nombreux artefacts intermédiaires — demandes, plans, rapports d’avancement, notes de travail propres à chaque agent et journaux de vérification (documentation Teamwork) — qui correspondent à l’état du projet et ne traduisent pas nécessairement une progression réelle.
Lancer son premier Teamwork sans sacrifier une semaine de quota
Le lancement de Teamwork tient en une commande, mais c’est l’entretien de cadrage qui détermine la facture. Dans l’application, ouvrez une conversation de projet et saisissez /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation. Dans la CLI, exécutez /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests depuis le répertoire du projet. Le suivi se fait dans le panneau des subagents ou la barre d’état de la CLI ; utilisez Alt+J pour accéder aux validations et consultez les artefacts de planification et d’avancement en temps réel (documentation Teamwork).
La phase 1 doit servir de garde-fou budgétaire. Décrivez le résultat attendu, pas la méthode : objectif, public visé (démo, production ou benchmark), contraintes impératives et vérification objective pour chaque exigence, par exemple une suite de tests ou un script de mesure. Choisissez development pour itérer, et gardez demo ou benchmark pour les situations où la présentation ou la preuve d’une implémentation depuis zéro est réellement importante : une vérification plus stricte implique davantage de travail pour les agents. Avant de valider, confirmez le répertoire de projet dédié.
Pendant l’exécution, gardez la conduite du projet centralisée. Faites passer les changements de périmètre par le coordinateur, intégrez les modifications des Workers avant de les retirer et évaluez l’avancement à partir des validations de jalons et des preuves fournies par les tests, pas du nombre de fichiers. Dans les réglages, définissez le dépassement de crédits IA sur Never pour ce premier essai : lorsque le quota de base sera épuisé, le travail s’arrêtera au lieu de consommer silencieusement des crédits (documentation des offres). Lorsque la documentation de votre offre l’autorise, associez un planificateur plus puissant à une implémentation moins coûteuse : Ultra prend en charge Orchestrator (Carbon) et Orchestrator (Argon), qui planifient avec Gemini 4 Carbon ou Argon tandis que Gemini 4 Hydrogen implémente (page tarifaire). C’est le même compromis que l’on retrouve dans les comparaisons entre Carbon et Argon.
FAQ
Quelle différence entre /teamwork et /teamwork-preview ?
/teamwork-preview était l’ancien nom de la préversion de recherche. La documentation Teamwork actuelle utilise /teamwork avec les offres payantes ; Google n’a pas publié de communiqué distinct annonçant une disponibilité générale.
Peut-on mettre Teamwork en pause ou récupérer le travail après l’épuisement du quota ?
Le comportement documenté de /swarm est le suivant : les Workers dont le quota est épuisé se mettent en pause jusqu’à la publication d’un nouveau message sur le tableau, au changement de modèle ou à l’envoi d’un message direct (documentation Swarm). La documentation Teamwork ne confirme pas ce même mécanisme de reprise. Avant de relancer, vérifiez les artefacts de planification et d’avancement dans ~/teamwork_projects/{PROJECT_NAME}, car les jalons partiels restent enregistrés sous forme de fichiers.
Quels artefacts Teamwork va-t-il générer ?
Des artefacts de demande, de plan de projet et d’avancement, ainsi que des notes de travail propres à chaque agent, des scripts auxiliaires et des journaux de vérification (documentation Teamwork). Une grande quantité de Markdown est normale ; mesurez l’avancement à partir des validations de jalons et des preuves de test, pas du nombre de fichiers.
Teamwork peut-il être utilisé sans risque dans des dépôts de production ?
Teamwork isole le travail dans un répertoire dédié, avec une propriété exclusive des fichiers et des points de contrôle, ce qui réduit les risques de collision (documentation Teamwork). Une utilisation en production exige néanmoins une revue humaine des critères d’acceptation, des preuves de test et de la validation finale du Success Auditor avant toute fusion.
La checklist de 30 secondes avant de saisir /teamwork
Ne saisissez /teamwork que si les cinq conditions suivantes sont réunies : le travail comporte plusieurs jalons, chaque jalon possède une vérification objective, un répertoire dédié est utile, des audits indépendants sont importants et une exécution coûteuse en quota reste moins chère que plusieurs semaines de travail manuel. Dans le cas contraire, choisissez Swarm pour un travail parallélisable, Boost pour un bug difficile mais ciblé ou les subagents pour les tâches annexes en arrière-plan. Teamwork doit rester réservé au projet qui a réellement besoin d’une équipe.