Les modèles locaux de Google Antigravity SDK rendent les agents utilisables hors ligne, mais le matériel en fixe les limites

Google a ajouté des modèles locaux à Antigravity SDK, permettant pour la première fois aux développeurs d’exécuter des workflows agentiques sans clé API ni connexion Internet.

Le premier parcours optimisé associe Gemma 4 26B A4B au runtime LiteRT de Google AI Edge. Google recommande au moins 24 Go de VRAM ou de mémoire unifiée. Cette exigence place l’expérience complète hors de portée de nombreux ordinateurs portables ordinaires, malgré la promesse d’une exécution locale.

Cette version déplace une frontière importante. Les développeurs n’ont plus besoin d’envoyer chaque prompt, fichier source ou résultat d’outil vers un modèle hébergé. Les agents cloud offrent toutefois toujours un déploiement plus simple, une plus grande capacité de modèles et moins de contraintes matérielles.

Google remet donc en cause le modèle d’agents exclusivement cloud sans l’abandonner. Sa propre démonstration utilise un planificateur Gemini dans le cloud aux côtés de plusieurs workers Gemma locaux. L’enjeu principal n’est pas le remplacement total du cloud, mais la maîtrise du lieu d’exécution de chaque composant d’un agent.

Les modèles locaux d’Antigravity SDK déplacent la boucle de l’agent sur l’appareil

Google a transféré les appels de modèle, la boucle d’outils et le contexte de travail de l’agent sur un matériel contrôlé par le développeur.

Google a annoncé la prise en charge des modèles locaux le 23 septembre 2026. L’entreprise indique qu’Antigravity SDK prend désormais en charge des workflows locaux avec plusieurs modèles et options d’exécution.

Le SDK expose, via Python, les capacités agentiques qui sous-tendent Google Antigravity. Elles comprennent l’interaction avec les modèles, les outils, les politiques, les espaces de travail, les hooks et les sous-agents.

Les développeurs associaient auparavant ces workflows à de l’inférence distante. La nouvelle configuration permet à un agent d’utiliser un checkpoint de modèle stocké et exécuté sur la même machine.

La publication de Google sur les modèles locaux présente Gemma 4 26B A4B comme premier modèle optimisé. LiteRT gère l’inférence à l’aide de l’accélération matérielle disponible sur l’appareil.

Le parcours pris en charge utilise LiteRTAgentConfig, qui oriente l’agent vers un checkpoint .litertlm. Le SDK lance un serveur loopback, c’est-à-dire un service accessible uniquement via l’interface réseau de la machine locale.

Ce service local se situe entre l’agent Antigravity et le runtime du modèle. Il permet au framework agentique plus large de communiquer avec le checkpoint sans appeler un endpoint de modèle public.

Selon Google, le workflow obtenu peut fonctionner sans clé API ni connexion Internet. Il s’agit d’une distinction importante avec les produits qui ne stockent localement que certains fichiers.

Une exécution entièrement hors ligne signifie que les entrées du modèle, les tokens générés et les interactions avec les outils peuvent rester sur l’appareil. Le résultat précis en matière de confidentialité dépend toutefois des outils et intégrations activés par le développeur.

Un agent qui appelle un service de recherche web n’est pas complètement hors ligne. Il en va de même d’un agent connecté à des bases de données distantes, des systèmes d’analytique ou des serveurs Model Context Protocol hébergés.

Le SDK prend également en charge des serveurs locaux externes via LocalOpenAIAgentConfig. Cette voie se connecte à des logiciels qui exposent une API compatible OpenAI sur la machine du développeur ou sur son réseau privé.

Google cite Ollama, LM Studio et vLLM comme exemples. Cette compatibilité compte, car les utilisateurs d’IA locale organisent déjà leurs modèles et automatisations autour de ces serveurs.

Les deux voies répondent à des besoins différents. LiteRT offre un parcours géré par Google et optimisé autour de son runtime, tandis que les serveurs compatibles donnent aux équipes davantage de contrôle sur l’hébergement des modèles.

Le guide d’exécution locale de Google documente les deux configurations. Il confirme aussi la prise en charge de Metal sur Apple Silicon, de Nvidia CUDA et de backends d’accélération détectés automatiquement.

Il ne s’agit pas simplement d’un sélecteur de modèles supplémentaire dans un éditeur. Le SDK permet aux développeurs d’intégrer l’inférence locale dans leurs propres scripts, services, systèmes d’évaluation et workflows agentiques spécialisés.

Cette programmabilité crée la tension centrale de l’article. Déplacer l’inférence sur l’appareil améliore le contrôle, mais transfère aussi la responsabilité de l’infrastructure de Google vers l’utilisateur.

Les agents hors ligne mettent les workflows exclusivement cloud sous pression

Cette version met les plateformes d’agents exclusivement cloud sous pression en faisant de la localité des données un choix d’architecture plutôt qu’une limitation produit.

L’inférence cloud reste l’option par défaut pour la plupart des agents de programmation. Elle donne aux utilisateurs un accès immédiat à de grands modèles sans exiger de GPU de station de travail ni de longs téléchargements de modèles.

Cette commodité a un coût qui dépasse les frais d’utilisation. Le code source, les prompts, les documents récupérés et les sorties d’outils doivent entrer dans un environnement de traitement distant.

Les politiques des fournisseurs peuvent limiter la conservation et l’usage à des fins d’entraînement. Les contrats d’entreprise peuvent ajouter des contrôles plus stricts. Malgré cela, certaines organisations ne peuvent pas envoyer de contenus sensibles hors d’une machine ou d’un réseau approuvé.

Les environnements de développement isolés du réseau présentent le cas le plus clair. Ces systèmes n’ont délibérément pas d’accès direct à Internet parce qu’ils contiennent des informations réglementées, classifiées ou commercialement sensibles.

Un agent exclusivement cloud ne peut pas fonctionner normalement dans cet environnement. Un agent Antigravity hors ligne le peut, à condition que son modèle et ses dépendances logicielles soient fournis via un processus de transfert approuvé.

Le même avantage vaut pour les développeurs travaillant sur des produits non annoncés, des rapports de sécurité, des documents juridiques et des algorithmes propriétaires. L’exécution locale réduit le nombre de systèmes qui reçoivent leur contexte.

Elle modifie aussi la disponibilité du service. Un workflow local ne s’arrête pas parce qu’un fournisseur de modèles subit une panne, modifie un quota ou retire un endpoint.

Cette indépendance peut compter lors de tâches de longue durée. Un agent qui audite un dépôt peut effectuer de nombreux tours de modèle en lisant des fichiers, en planifiant des modifications, en exécutant des tests et en examinant des erreurs.

La latence se comporte également différemment. L’inférence locale évite les délais des réseaux étendus, mais la génération de tokens dépend entièrement du matériel disponible et de l’optimisation du runtime.

Une station de travail bien équipée peut offrir des temps de réponse prévisibles. Une machine proche de la recommandation minimale de mémoire peut fournir une expérience bien plus lente, surtout sous des charges de travail simultanées.

Les plateformes cloud conservent des avantages évidents. Elles peuvent fournir de plus grands modèles, une capacité élastique, une supervision centralisée et des mises à jour gérées sans consommer de mémoire locale.

Elles permettent aussi aux équipes de standardiser les performances entre des employés utilisant des ordinateurs différents. Une approche privilégiant le local fait des spécifications des appareils un élément du plan de déploiement.

Cette version n’établit donc pas une simple compétition entre IA locale et cloud. Elle exerce une pression sur les plateformes qui n’offrent aucun choix significatif entre ces environnements d’exécution.

L’avantage stratégique revient aux frameworks capables d’orienter le travail selon la sensibilité, la complexité et les ressources de calcul disponibles. Le SDK de Google prend désormais en charge ce modèle plus large.

Pour les entreprises, la décision devient plus granulaire. Une équipe peut réserver les modèles hébergés à la planification exigeante tout en conservant l’analyse répétitive de fichiers sur du matériel contrôlé.

Les développeurs individuels gagnent une autre forme de levier. Ils peuvent continuer à utiliser un workflow agentique même s’ils ne souhaitent pas que chaque tâche dépende d’une authentification distante ou de limites de consommation.

La limite reste l’accès à un matériel approprié. Google recommande au moins 24 Go de VRAM ou de mémoire unifiée pour le checkpoint Gemma mis en avant.

De nombreux ordinateurs grand public restent sous ce seuil. Certaines machines le respectent techniquement, mais doivent partager cette mémoire avec le système d’exploitation, l’éditeur, le navigateur et les outils de build.

Les fournisseurs exclusivement cloud peuvent raisonnablement soutenir que l’inférence gérée demeure la voie la plus accessible. Les agents locaux améliorent l’autonomie, mais n’éliminent pas les coûts de calcul.

La pression est donc la plus forte chez les équipes soucieuses de sécurité et techniquement matures. Ces acheteurs peuvent accorder suffisamment de valeur au contrôle local pour accepter le travail de configuration et les exigences matérielles.

LiteRT et Gemma 4 expliquent le fonctionnement du workflow hors ligne

Le mécanisme repose sur un modèle Gemma sparse, un runtime d’inférence local et un framework agentique capable de maintenir sa boucle de contrôle à proximité.

Gemma 4 26B A4B utilise une architecture de mélange d’experts. Cette conception oriente chaque token vers une partie seulement du modèle, au lieu d’activer chaque paramètre.

Google indique 25,2 milliards de paramètres totaux et 3,8 milliards de paramètres actifs pour le modèle. L’étiquette A4B renvoie à environ quatre milliards de paramètres actifs pendant l’inférence.

Cette distinction importe pour l’exécution locale. Le modèle peut puiser dans un plus grand ensemble de paramètres sans exiger un calcul dense sur les 25,2 milliards de paramètres pour chaque token.

Cela ne signifie pas que le checkpoint n’occupe que quatre milliards de paramètres en stockage ou en mémoire. L’ensemble complet des experts doit rester disponible pour le routage.

Google indique que le checkpoint au format LiteRT représente environ 16,8 Go au téléchargement. Le niveau de mémoire recommandé de 24 Go laisse une capacité supplémentaire pour l’état d’inférence et les autres processus.

La fiche du modèle Gemma 4 indique une fenêtre de contexte pouvant atteindre 256 000 tokens pour le modèle 26B A4B. Il prend aussi en charge les entrées texte et image.

Une grande fenêtre de contexte annoncée ne garantit pas que chaque machine locale puisse l’utiliser confortablement. Les contextes plus longs accroissent les besoins en mémoire et le temps de traitement dans les charges de travail réelles.

Gemma 4 comprend également l’appel de fonctions natif. L’appel de fonctions permet à un modèle de demander une action structurée, par exemple lire un fichier ou appeler un outil défini par le développeur.

Cette capacité est essentielle pour un agent. Un chatbot classique ne produit que des réponses, tandis qu’un agent alterne entre raisonnement, actions, observations et décisions révisées.

Antigravity fournit le système de contrôle environnant. Il gère l’espace de travail, les outils disponibles, les politiques d’exécution et la communication avec le modèle local.

LiteRT fournit la couche d’inférence. Google a conçu ce runtime pour l’apprentissage automatique sur appareil à travers les backends matériels pris en charge.

Le guide des modèles LiteRT décrit des variantes de Gemma destinées à des appareils allant des téléphones aux GPU grand public et aux stations de travail. Les cibles matérielles varient considérablement au sein de cette famille.

Pour l’intégration Antigravity, les développeurs installent le SDK et le package litert-lm. Ils importent ensuite le modèle dans le format de checkpoint de LiteRT.

L’agent reçoit le chemin du modèle par sa configuration. Au démarrage du programme, le SDK crée le service de modèle local et transmet les tokens générés à l’application en streaming.

Cette architecture maintient une intégration relativement familière. Les développeurs instancient toujours un agent et lui envoient une tâche, plutôt que de construire indépendamment un serveur d’inférence et une boucle d’outils.

La configuration compatible OpenAI constitue une alternative qui élargit les options de modèles. Une équipe peut orienter Antigravity vers un déploiement Ollama, LM Studio ou vLLM existant.

Une interface compatible OpenAI standardise les formats courants de requête et de réponse. Elle n’implique pas que le modèle sous-jacent provienne d’OpenAI.

Cette distinction permet à Antigravity de se placer au-dessus de plusieurs piles d’inférence. Le framework agentique peut rester stable tandis que le serveur local ou le modèle sélectionné évolue.

La compatibilité réduit également le verrouillage au niveau du runtime. Les équipes utilisant déjà vLLM sur un serveur interne n’ont pas besoin d’adopter LiteRT pour chaque workflow.

LiteRT reçoit néanmoins une attention particulière, car Google a optimisé autour de lui le parcours initial de Gemma 4. Cet appariement donne à Google le contrôle à la fois du format du modèle et du runtime d’exécution.

L’architecture ne se limite pas à une utilisation entièrement locale. Elle permet également une orchestration hybride, dans laquelle un modèle cloud planifie le travail et des agents locaux exécutent des tâches délimitées.

Cette option hybride explique le plus clairement le calendrier de Google. Les modèles locaux sont désormais suffisamment capables pour prendre en charge des tâches de programmation utiles sans remplacer les planificateurs hébergés les plus puissants.

La démonstration hybride de Google révèle la véritable stratégie

L’exemple de Google montre que les agents locaux deviennent une couche de main-d’œuvre, tandis que les modèles cloud conservent le rôle de planification.

L’entreprise a présenté un schéma Architect-Builder utilisant Gemini 3.8 Flash comme architecte cloud. Des instances locales de Gemma 4 26B jouaient le rôle de builders.

La démonstration a confié au système trois modules Python vulnérables nommés auth.py, billing.py et database.py. Les workers locaux ont réalisé l’audit et les correctifs sur l’appareil.

Le planificateur cloud coordonnait le processus global. Cette répartition maintenait une grande partie du travail sur le dépôt en local tout en préservant l’accès à un modèle hébergé plus vaste pour l’orchestration.

Cette conception est plus crédible que d’affirmer qu’un seul checkpoint local peut égaler tous les modèles cloud. Les différentes étapes d’une tâche d’agent ont des besoins distincts en matière de précision, de confidentialité et de calcul.

La planification bénéficie souvent d’un raisonnement plus robuste sur un vaste contexte. L’inspection répétitive, l’édition et la vérification peuvent être distribuées à des workers plus petits.

Ce modèle s’apparente à l’architecture informatique traditionnelle. Des systèmes centralisés planifient les tâches, tandis que des machines spécialisées les exécutent au plus près des données concernées.

Pour les équipes logicielles, un workflow hybride pratique pourrait commencer par un modèle hébergé qui décompose une migration. Des agents locaux pourraient ensuite inspecter des modules individuels et proposer des modifications.

Une révision finale pourrait revenir au planificateur cloud après avoir minimisé les détails sensibles. À défaut, un humain pourrait examiner les résultats locaux sans nouvel appel distant.

Le bénéfice pour la confidentialité dépend de cette frontière. Si le planificateur cloud reçoit des fichiers source complets, les builders locaux n’empêchent pas l’exposition des données à distance.

Les développeurs doivent décider quel contexte franchit cette frontière, quels résumés sont partagés et quels outils peuvent accéder à des services externes. Le SDK ne peut pas prendre automatiquement ces décisions de politique.

Le système de politiques de Google offre aux développeurs un moyen d’imposer des limites. Toutefois, des configurations d’exemple permissives ne devraient pas devenir des valeurs par défaut de production sans révision.

L’exemple de base de l’entreprise utilise un agent local pour inspecter les fichiers du répertoire actuel. Un exemple plus avancé permet à l’agent de créer un outil de supervision et d’exécuter des commandes.

Ces capacités rendent l’agent utile, mais elles accroissent également les risques. Un modèle erroné ou manipulé peut modifier des fichiers, lancer des processus ou exposer des informations via des outils connectés.

L’inférence locale ne rend pas un agent inoffensif. Elle change le lieu où le calcul du modèle est effectué, pas la nécessité de superviser les actions générées.

L’exécution hybride ajoute aussi de la complexité opérationnelle. Les équipes doivent surveiller à la fois les appels distants et les environnements d’exécution locaux, tout en comprenant les défaillances qui traversent cette frontière.

Un planificateur cloud peut produire une décomposition de tâche défaillante. Les builders locaux peuvent alors exécuter ce plan de manière cohérente, propageant une même erreur dans plusieurs fichiers.

La concurrence crée une autre contrainte. L’exécution de plusieurs instances de Gemma 4 peut exiger davantage de mémoire qu’une configuration unique recommandée ne peut en fournir.

Google n’a pas publié de benchmarks indépendants et spécifiques aux charges de travail pour l’intégration Antigravity. L’annonce établit donc la disponibilité, et non des performances universelles.

La démonstration indique néanmoins une direction produit claire. Google positionne les modèles locaux comme des workers complémentaires au sein d’un système d’agents plus large.

Cette stratégie pousse les autres frameworks d’agents à prendre en charge un routage similaire. Les clients demanderont de plus en plus si une tâche peut rester locale avant d’accepter une réponse exclusivement cloud.

Elle offre également à Google un moyen de couvrir les deux marchés. Les services Gemini restent pertinents pour une orchestration exigeante, tandis que Gemma et LiteRT couvrent une exécution privée ou sensible aux coûts.

La recommandation de 24 GB constitue le premier rappel à la réalité

Le fonctionnement hors ligne supprime la dépendance à un endpoint distant, mais la remplace par des contraintes de matériel, de maintenance et de qualité du modèle.

Google recommande une machine disposant d’au moins 24 GB de VRAM ou de mémoire unifiée pour Gemma 4 26B A4B. Cette formulation décrit une recommandation, et non une garantie universelle.

La VRAM est la mémoire graphique dédiée utilisée par les GPU discrets. La mémoire unifiée est un pool partagé utilisé par les processeurs et le matériel graphique sur des systèmes tels que les Mac Apple Silicon.

Ces configurations se comportent différemment sous pression. Un GPU discret peut offrir un débit d’inférence élevé, tandis que la mémoire unifiée peut apporter davantage de flexibilité entre les tâches CPU et graphiques.

La capacité disponible importe davantage que le total annoncé. Une machine de 24 GB exécutant des conteneurs, des navigateurs, des builds et plusieurs agents peut ne plus avoir que très peu de marge.

Le téléchargement du checkpoint de 16.8 GB crée également une charge de déploiement. Les organisations doivent distribuer, vérifier, mettre à jour et stocker cet artefact sur les machines approuvées.

La provenance du modèle devient une préoccupation opérationnelle. Les équipes devraient confirmer l’origine d’un checkpoint, la manière dont il a été converti et si sa licence autorise l’utilisation envisagée.

Gemma 4 est distribué sous licence Apache 2.0 selon la documentation de Google. Les fine-tunes externes et les checkpoints convertis peuvent introduire des conditions distinctes ou des questions de sécurité.

La qualité du modèle présente une incertitude plus importante. Google publie des résultats de benchmark pour Gemma 4, notamment des évaluations orientées programmation et agents.

Ces benchmarks décrivent le modèle sous-jacent dans des conditions de test définies. Ils n’établissent pas avec quelle fiabilité Antigravity accomplit de longues tâches guidées par des outils sur le dépôt d’un développeur.

La fiabilité des agents cumule les erreurs à chaque étape. Un petit malentendu peut affecter la sélection des fichiers, l’exécution des commandes, l’interprétation des tests et le correctif final.

Les modèles locaux peuvent également ne pas bénéficier des dernières améliorations hébergées. Les fournisseurs cloud peuvent mettre à jour les systèmes d’inférence de manière centralisée, tandis que les déploiements locaux exigent des mises à niveau délibérées et des tests de régression.

Les équipes peuvent préférer cette stabilité. Un checkpoint fixe produit un environnement plus contrôlé et évite les changements de comportement inattendus après une mise à jour d’un modèle distant.

Cependant, fixe ne signifie pas déterministe. Les paramètres d’échantillonnage, les résultats des outils, l’état de l’espace de travail et la concurrence peuvent toujours modifier les résultats.

Les équipes de sécurité doivent également examiner le serveur local. Une adresse loopback limite l’exposition, mais une mauvaise configuration peut malgré tout ouvrir des ports ou accorder un accès trop étendu au système de fichiers.

Les serveurs compatibles OpenAI exigent un examen similaire. La documentation de service vLLM montre comment des endpoints locaux ou privés reproduisent les API de modèles courantes.

La compatibilité améliore la portabilité, mais elle peut masquer des différences importantes. Les modèles diffèrent dans le formatage des appels d’outils, la gestion du contexte, le comportement de sécurité et la prise en charge des sorties structurées.

Les développeurs devraient donc tester l’ensemble de la boucle d’agent, et pas seulement les réponses aux prompts. Un modèle qui écrit du bon code peut néanmoins avoir du mal à sélectionner les outils de manière fiable.

La recommandation matérielle de Google réduit l’audience immédiate. Les stations de travail équipées de GPU Nvidia à grande mémoire et les systèmes Apple Silicon mieux équipés constituent les points de départ naturels.

Les modèles Gemma plus petits peuvent élargir l’accès, mais l’annonce de Google concentre son workflow optimisé sur le checkpoint 26B A4B. C’est la version qui soutient l’affirmation de lancement la plus forte.

L’écart entre « s’exécute localement » et « fonctionne bien sur ma machine » reste non résolu. Les performances varieront selon le matériel, la taille du contexte, l’utilisation des outils et la complexité des tâches.

Il n’existe pas encore non plus de preuve que les agents Antigravity hors ligne égalent les principaux systèmes hébergés sur l’ensemble des tâches d’ingénierie logicielle. Google n’a pas formulé cette affirmation plus large.

L’interprétation responsable est plus restreinte. Antigravity peut désormais exécuter localement des workflows d’agents significatifs, avec une configuration documentée et une recommandation de mémoire substantielle.

Cette capacité est importante même avant la parité de performances. Elle donne aux équipes une option déployable là où l’inférence distante était auparavant interdite ou indésirable.

Trois signaux montreront si les agents locaux deviennent la norme

Le prochain test déterminera si l’exécution locale devient courante au-delà des expérimentations sensibles à la confidentialité et des stations de travail de développeurs à grande mémoire.

Le premier signal sera une prise en charge plus large des modèles et du matériel. Les développeurs ont besoin de choix pratiques pour les machines situées sous la recommandation de 24 GB.

Des variantes Gemma plus petites pourraient rendre les agents hors ligne accessibles à davantage d’ordinateurs portables. Des checkpoints optimisés supplémentaires pourraient aussi permettre aux équipes d’arbitrer entre capacité, vitesse et consommation mémoire.

La prise en charge seule ne suffira pas. Google doit publier des données de performances claires sur Apple Silicon, les GPU Nvidia et les autres accélérateurs pris en charge.

Les mesures utiles incluent la vitesse de génération, le délai avant le premier token, l’utilisation maximale de mémoire et l’accomplissement des tâches de bout en bout. Les benchmarks d’agents devraient couvrir les outils et la récupération en plusieurs étapes.

Si ces résultats montrent des performances acceptables sur du matériel courant, la voie locale deviendra davantage qu’une fonctionnalité de spécialiste. Des résultats faibles renforceraient l’inférence cloud comme choix par défaut.

Le deuxième signal sera la preuve issue de déploiements en production. Les premières démonstrations prouvent que le logiciel s’exécute, mais elles ne révèlent pas sa fiabilité quotidienne.

Les équipes devront indiquer comment les agents locaux gèrent les grands dépôts, les longues sessions, les workers concurrents et les suites d’évaluation reproductibles.

L’adoption axée sur la sécurité mérite une attention particulière. Les organisations isolées du réseau ont une forte raison d’accepter des performances plus lentes si le workflow satisfait les contrôles internes.

Les retours des développeurs révéleront également les frictions pratiques. Les échecs d’installation, les problèmes de conversion de checkpoints, les limites thermiques et les erreurs d’appel d’outils peuvent l’emporter sur les bénéfices architecturaux.

Le troisième signal sera la réponse concurrentielle. D’autres frameworks d’agents se connectent déjà à des serveurs de modèles locaux, mais la profondeur de leur intégration varie considérablement.

La comparaison importante n’est pas de savoir si un produit propose Ollama comme option. Il s’agit de savoir si les modèles locaux peuvent utiliser les mêmes outils, politiques, espaces de travail et fonctionnalités d’orchestration.

Les concurrents peuvent répondre par un routage local plus robuste, une inférence hébergée pour les entreprises ou une sélection automatique entre modèles distants et embarqués.

Une réponse rapide confirmerait le jugement sous-jacent de Google selon lequel le lieu d’exécution devient un critère d’achat. Une réponse limitée suggérerait que la demande reste concentrée parmi les enthousiastes.

Le modèle hybride de Google mérite également un examen attentif. Il peut offrir un équilibre pratique, mais seulement si les développeurs peuvent vérifier quelles informations atteignent le planificateur cloud.

Des journaux clairs, des contrôles de politique et un routage traçable compteront autant que la prise en charge des modèles. Les entreprises ont besoin de preuves que les frontières déclarées sont appliquées à chaque tour de l’agent.

Cette sortie devrait également encourager une conception des tâches plus disciplinée. Les développeurs peuvent réserver les agents locaux à des travaux contraints au lieu d’attendre d’un seul système qu’il gère un projet entier de manière autonome.

Par exemple : classer des documents privés, examiner un module délimité, générer des tests ou résumer des notes techniques locales. Chaque tâche possède des entrées et des sorties mesurables.

Cette approche s’inscrit dans un workflow d’IA plus large, dans lequel le contexte sensible reste proche de l’utilisateur. La révision humaine continue de régir les actions conséquentes.

Les modèles locaux Antigravity SDK font désormais de l’exécution hors ligne d’agents un workflow Google documenté plutôt qu’un contournement non officiel. Ce lancement ne résout pas les questions de qualité ou d’accessibilité.

Il change toutefois ce que les développeurs peuvent exiger d’une plateforme d’agents. L’accès au cloud ne doit plus être le prix inévitable de l’automatisation.

La prochaine étape la plus utile consiste à effectuer des tests concrets. Choisissez une tâche privée et circonscrite, mesurez l’utilisation mémoire et la qualité d’exécution, puis comparez les exécutions locales et hébergées.

L’agent local préserve-t-il le contexte qui compte tout en accomplissant suffisamment de travail pour justifier le matériel ? La réponse déterminera si Google a créé une architecture par défaut ou une exception précieuse.