I modelli locali di Google Antigravity SDK portano gli agenti offline, ma l'hardware definisce il limite

Google ha aggiunto i modelli locali di Antigravity SDK, consentendo agli sviluppatori di eseguire workflow agentici senza una chiave API o una connessione Internet per la prima volta.

Il primo percorso ottimizzato combina Gemma 4 26B A4B con il runtime LiteRT di Google AI Edge. Google raccomanda almeno 24 GB di VRAM o memoria unificata. Questo requisito pone l'esperienza completa fuori dalla portata di molti laptop comuni, nonostante la promessa dell'esecuzione locale.

Questa release sposta un confine importante. Gli sviluppatori non devono più inviare ogni prompt, file sorgente o risultato di uno strumento attraverso un modello ospitato. Tuttavia, gli agenti cloud offrono ancora un deployment più semplice, una maggiore capacità del modello e meno vincoli hardware.

Google sta quindi mettendo in discussione il modello di agenti esclusivamente cloud senza abbandonarlo. La sua stessa dimostrazione usa un pianificatore Gemini nel cloud insieme a diversi worker Gemma locali. La storia più importante non è la sostituzione totale del cloud, ma il controllo su dove venga eseguita ogni parte di un agente.

I modelli locali di Antigravity SDK spostano il ciclo dell'agente sul dispositivo

Google ha trasferito le chiamate al modello dell'agente, il ciclo degli strumenti e il contesto di lavoro su hardware controllato dallo sviluppatore.

Google ha annunciato il supporto per i modelli locali il 23 settembre 2026. L'azienda afferma che Antigravity SDK ora supporta workflow locali su più modelli e opzioni di esecuzione.

L'SDK espone tramite Python le capacità agentiche alla base di Google Antigravity. Queste capacità includono interazione con il modello, strumenti, policy, workspace, hook e subagenti.

In precedenza, gli sviluppatori associavano questi workflow all'inferenza remota. La nuova configurazione consente a un agente di operare con un checkpoint del modello archiviato ed eseguito sulla stessa macchina.

La release dei modelli locali di Google evidenzia Gemma 4 26B A4B come primo modello ottimizzato. LiteRT gestisce l'inferenza attraverso l'hardware di accelerazione disponibile sul dispositivo.

Il percorso supportato usa LiteRTAgentConfig, che indirizza l'agente verso un checkpoint .litertlm. L'SDK avvia un server loopback, ossia un servizio disponibile solo tramite l'interfaccia di rete della macchina locale.

Questo servizio locale si colloca tra l'agente Antigravity e il runtime del modello. Permette al framework agentico più ampio di comunicare con il checkpoint senza chiamare un endpoint pubblico del modello.

Secondo Google, il workflow risultante può essere eseguito senza una chiave API o una connessione Internet. Si tratta di una distinzione significativa rispetto ai prodotti che memorizzano localmente soltanto file selezionati.

Un'esecuzione completamente offline significa che gli input del modello, i token generati e le interazioni con gli strumenti possono rimanere sul dispositivo. L'esito preciso in termini di privacy dipende comunque dagli strumenti e dalle integrazioni abilitati dallo sviluppatore.

Un agente che chiama un servizio di ricerca web non è completamente offline. Lo stesso vale per un agente connesso a database remoti, sistemi di analisi o server Model Context Protocol ospitati.

L'SDK supporta anche server locali esterni tramite LocalOpenAIAgentConfig. Questo percorso si collega a software che espone un'API compatibile con OpenAI sulla macchina dello sviluppatore o su una rete privata.

Google cita Ollama, LM Studio e vLLM come esempi. Questa compatibilità è rilevante perché gli utenti dell'IA locale organizzano già modelli e automazione attorno a questi server.

I due percorsi rispondono a esigenze diverse. LiteRT offre un percorso gestito da Google e ottimizzato attorno al suo runtime, mentre i server compatibili danno ai team un maggiore controllo sull'hosting del modello.

La guida all'esecuzione locale di Google documenta entrambe le configurazioni. Conferma inoltre il supporto per Apple Silicon Metal, Nvidia CUDA e backend di accelerazione rilevati automaticamente.

Non si tratta solo di un altro selettore di modelli all'interno di un editor. L'SDK consente agli sviluppatori di inserire l'inferenza locale nei propri script, servizi, sistemi di valutazione e workflow agentici specializzati.

Questa programmabilità crea la tensione centrale dell'articolo. Spostare l'inferenza sul dispositivo migliora il controllo, ma trasferisce anche la responsabilità dell'infrastruttura da Google all'utente.

Gli agenti offline mettono sotto pressione i workflow esclusivamente cloud

La release mette sotto pressione le piattaforme agentiche esclusivamente cloud, rendendo la località dei dati una scelta architetturale anziché una limitazione del prodotto.

L'inferenza cloud rimane l'impostazione predefinita per la maggior parte degli agenti di coding. Offre agli utenti accesso immediato a modelli di grandi dimensioni senza richiedere una GPU da workstation o lunghi download dei modelli.

Questa comodità ha un costo che va oltre le tariffe di utilizzo. Codice sorgente, prompt, documenti recuperati e output degli strumenti devono entrare in un ambiente di elaborazione remoto.

Le policy dei provider possono limitare la conservazione e l'uso per l'addestramento. Gli accordi aziendali possono aggiungere controlli più rigorosi. Ciononostante, alcune organizzazioni non possono inviare materiale sensibile al di fuori di una macchina o rete approvata.

Gli ambienti di sviluppo air-gapped rappresentano il caso più evidente. Questi sistemi sono intenzionalmente privi di accesso diretto a Internet perché contengono informazioni regolamentate, classificate o commercialmente sensibili.

Un agente esclusivamente cloud non può operare normalmente in questo contesto. Un agente Antigravity offline può farlo, a condizione che il modello e le dipendenze software arrivino tramite un processo di trasferimento approvato.

Lo stesso vantaggio vale per gli sviluppatori che lavorano con prodotti non ancora rilasciati, report di sicurezza, documenti legali e algoritmi proprietari. L'esecuzione locale riduce il numero di sistemi che ricevono il loro contesto.

Cambia anche la disponibilità del servizio. Un workflow locale non si interrompe perché un provider di modelli subisce un disservizio, modifica una quota o ritira un endpoint.

Questa indipendenza può essere importante durante attività di lunga durata. Un agente che effettua l'audit di un repository può eseguire molti turni del modello mentre legge file, pianifica modifiche, esegue test e analizza errori.

Anche la latenza si comporta diversamente. L'inferenza locale evita i ritardi della rete geografica, ma la generazione dei token dipende interamente dall'hardware disponibile e dall'ottimizzazione del runtime.

Una workstation ben equipaggiata può offrire tempi di risposta prevedibili. Una macchina vicina alla raccomandazione minima di memoria può fornire un'esperienza molto più lenta, specialmente con carichi di lavoro concorrenti.

Le piattaforme cloud mantengono vantaggi evidenti. Possono offrire modelli più grandi, capacità elastica, monitoraggio centralizzato e aggiornamenti gestiti senza consumare memoria locale.

Consentono inoltre ai team di standardizzare le prestazioni tra dipendenti che usano computer diversi. Un approccio local-first rende le specifiche del dispositivo parte del piano di deployment.

Questa release non stabilisce quindi una semplice competizione tra IA locale e cloud. Mette sotto pressione le piattaforme che non offrono una scelta significativa tra questi ambienti di esecuzione.

Il vantaggio strategico appartiene ai framework in grado di instradare il lavoro in base a sensibilità, complessità e capacità di calcolo disponibile. L'SDK di Google ora supporta questo modello più ampio.

Per le aziende, la decisione diventa più granulare. Un team può riservare i modelli ospitati alla pianificazione più impegnativa, mantenendo al contempo l'analisi ripetitiva dei file su hardware controllato.

Gli sviluppatori individuali ottengono un'altra forma di leva. Possono continuare a usare un workflow agentico anche quando non vogliono che ogni attività dipenda dall'autenticazione remota o da limiti di consumo.

Il limite è l'accesso a hardware adeguato. Google raccomanda almeno 24 GB di VRAM o memoria unificata per il checkpoint Gemma in evidenza.

Molti computer mainstream restano sotto questa soglia. Alcune macchine la soddisfano tecnicamente, ma devono condividere quella memoria con il sistema operativo, l'editor, il browser e gli strumenti di build.

I provider esclusivamente cloud possono ragionevolmente sostenere che l'inferenza gestita rimane il percorso più accessibile. Gli agenti locali migliorano l'autonomia, ma non eliminano i costi di calcolo.

La pressione è quindi più forte nei team attenti alla sicurezza e tecnicamente maturi. Questi acquirenti possono attribuire al controllo locale un valore sufficiente da accettare il lavoro di configurazione e i requisiti hardware.

LiteRT e Gemma 4 spiegano come funziona il workflow offline

Il meccanismo dipende da un modello Gemma sparse, da un runtime di inferenza locale e da un framework agentico in grado di mantenere vicino il proprio ciclo di controllo.

Gemma 4 26B A4B utilizza un'architettura mixture-of-experts. Questo design instrada ogni token attraverso solo una parte del modello anziché attivare ogni parametro.

Google indica 25,2 miliardi di parametri totali e 3,8 miliardi di parametri attivi per il modello. L'etichetta A4B si riferisce a circa quattro miliardi di parametri attivi durante l'inferenza.

Questa distinzione è importante per l'esecuzione locale. Il modello può attingere da un pool di parametri più ampio senza richiedere calcolo denso su tutti i 25,2 miliardi di parametri per ogni token.

Non significa che il checkpoint occupi soltanto quattro miliardi di parametri in archiviazione o memoria. L'intera raccolta di esperti deve rimanere disponibile per l'instradamento.

Google afferma che il checkpoint in formato LiteRT richiede un download di circa 16,8 GB. Il livello di memoria raccomandato di 24 GB lascia capacità aggiuntiva per lo stato dell'inferenza e altri processi.

La model card di Gemma 4 indica una finestra di contesto fino a 256.000 token per il modello 26B A4B. Supporta inoltre input di testo e immagini.

Un'ampia finestra di contesto dichiarata non garantisce che ogni macchina locale possa usarla comodamente. Contesti più lunghi aumentano i requisiti di memoria e il tempo di elaborazione nei carichi di lavoro reali.

Gemma 4 include anche il function calling nativo. Il function calling consente a un modello di richiedere un'azione strutturata, come leggere un file o invocare uno strumento definito dallo sviluppatore.

Questa capacità è essenziale per un agente. Un chatbot convenzionale produce soltanto risposte, mentre un agente alterna ragionamento, azioni, osservazioni e decisioni riviste.

Antigravity fornisce il sistema di controllo circostante. Gestisce il workspace, gli strumenti disponibili, le policy di esecuzione e la comunicazione con il modello locale.

LiteRT fornisce il livello di inferenza. Google ha progettato il runtime per il machine learning sul dispositivo attraverso backend hardware supportati.

La guida ai modelli LiteRT descrive varianti Gemma destinate a dispositivi che vanno dai telefoni alle GPU consumer e alle workstation. Gli obiettivi hardware variano considerevolmente nell'intera famiglia.

Per l'integrazione con Antigravity, gli sviluppatori installano l'SDK e il pacchetto litert-lm. Quindi importano il modello nel formato checkpoint di LiteRT.

L'agente riceve il percorso del modello tramite la propria configurazione. Quando il programma si avvia, l'SDK crea il servizio del modello locale e trasmette in streaming i token generati all'applicazione.

Questa architettura mantiene l'integrazione relativamente familiare. Gli sviluppatori continuano a istanziare un agente e a inviargli un'attività, anziché costruire indipendentemente un server di inferenza e un ciclo degli strumenti.

La configurazione alternativa compatibile con OpenAI amplia le opzioni di modello. Un team può indirizzare Antigravity verso un deployment esistente di Ollama, LM Studio o vLLM.

Un'interfaccia compatibile con OpenAI standardizza i formati comuni di richiesta e risposta. Non implica che il modello sottostante provenga da OpenAI.

Questa distinzione consente ad Antigravity di collocarsi sopra diversi stack di inferenza. Il framework agentico può rimanere stabile mentre cambiano il server locale o il modello selezionato.

La compatibilità riduce anche il lock-in a livello di runtime. I team che già usano vLLM su un server interno non devono adottare LiteRT per ogni workflow.

LiteRT riceve comunque particolare attenzione perché Google ha ottimizzato attorno a esso il percorso iniziale di Gemma 4. Questo abbinamento offre a Google il controllo sia sul formato del modello sia sul runtime di esecuzione.

L’architettura supporta più della sola operatività completamente locale. Consente anche un’orchestrazione ibrida, in cui un modello cloud pianifica il lavoro e agenti locali svolgono attività circoscritte.

Questa opzione ibrida è la spiegazione più chiara della tempistica di Google. I modelli locali sono diventati sufficientemente capaci da gestire attività di programmazione utili senza sostituire i più potenti pianificatori ospitati nel cloud.

La demo ibrida di Google rivela la vera strategia

L’esempio di Google mostra che gli agenti locali stanno diventando un livello operativo, mentre i modelli cloud mantengono il ruolo di pianificazione.

L’azienda ha dimostrato un modello Architect-Builder utilizzando Gemini 3.8 Flash come architetto cloud. Le istanze locali di Gemma 4 26B hanno agito da costruttori.

La dimostrazione ha assegnato al sistema tre moduli Python vulnerabili denominati auth.py, billing.py e database.py. I worker locali hanno gestito l’audit e l’applicazione delle patch sul dispositivo.

Il pianificatore cloud ha coordinato il processo più ampio. Questa divisione ha mantenuto locale gran parte del lavoro sul repository, preservando al contempo l’accesso a un modello ospitato più grande per l’orchestrazione.

È un approccio più credibile che sostenere che un singolo checkpoint locale possa eguagliare ogni modello cloud. Le diverse fasi di un’attività agentica hanno esigenze diverse in termini di accuratezza, privacy e calcolo.

La pianificazione beneficia spesso di un ragionamento più solido su un contesto ampio. L’ispezione, la modifica e la verifica ripetitive possono essere distribuite a worker più piccoli.

Il modello ricorda l’architettura informatica convenzionale. I sistemi centralizzati pianificano i job, mentre macchine specializzate eseguono attività vicino ai dati rilevanti.

Per i team software, un flusso di lavoro ibrido pratico potrebbe iniziare con un modello ospitato che scompone una migrazione. Gli agenti locali potrebbero quindi ispezionare singoli moduli e proporre modifiche.

Una revisione finale potrebbe tornare al pianificatore cloud dopo aver minimizzato i dettagli sensibili. In alternativa, un essere umano potrebbe esaminare gli output locali senza un’altra chiamata remota.

Il vantaggio in termini di privacy dipende da tale confine. Se il pianificatore cloud riceve file sorgente completi, i builder locali non impediscono l’esposizione remota dei dati.

Gli sviluppatori devono decidere quale contesto attraversa il confine, quali riepiloghi vengono condivisi e quali strumenti possono accedere a servizi esterni. L’SDK non può prendere automaticamente queste decisioni di policy.

Il sistema di policy di Google offre agli sviluppatori un punto in cui applicare limiti. Tuttavia, configurazioni di esempio permissive non dovrebbero diventare impostazioni predefinite di produzione senza revisione.

L’esempio base dell’azienda utilizza un agente locale per ispezionare i file nella directory corrente. Un esempio più avanzato consente all’agente di creare uno strumento di monitoraggio ed eseguire comandi.

Queste capacità rendono l’agente utile, ma aumentano anche il rischio. Un modello errato o manipolato può modificare file, invocare processi o esporre informazioni tramite strumenti connessi.

L’inferenza locale non rende innocuo un agente. Cambia il luogo in cui avviene il calcolo del modello, non la necessità di supervisionare le azioni generate.

L’esecuzione ibrida introduce anche complessità operative. I team devono monitorare sia le chiamate remote sia i runtime locali, comprendendo i guasti oltre il confine tra i due.

Un pianificatore cloud può produrre una scomposizione errata del compito. I builder locali possono poi eseguire quel piano con coerenza, diffondendo un singolo errore in più file.

La concorrenza crea un ulteriore vincolo. L’esecuzione di più istanze Gemma 4 può richiedere più memoria di quella fornita da una singola configurazione consigliata.

Google non ha pubblicato benchmark indipendenti e specifici per i carichi di lavoro dell’integrazione Antigravity. L’annuncio stabilisce quindi la disponibilità, non prestazioni universali.

La demo segnala comunque una direzione di prodotto chiara. Google sta posizionando i modelli locali come worker complementari all’interno di un sistema agentico più ampio.

Questa strategia spinge altri framework agentici a supportare un instradamento simile. I clienti chiederanno sempre più spesso se un’attività possa rimanere locale prima di accettare una risposta solo cloud.

Offre inoltre a Google un modo per coprire entrambi i mercati. I servizi Gemini rimangono rilevanti per l’orchestrazione più impegnativa, mentre Gemma e LiteRT coprono l’esecuzione privata o sensibile ai costi.

La raccomandazione da 24 GB è il primo controllo di realtà

L’operatività offline elimina la dipendenza da un endpoint remoto, ma sostituisce tale dipendenza con vincoli di hardware, manutenzione e qualità del modello.

Google raccomanda una macchina con almeno 24 GB di VRAM o memoria unificata per Gemma 4 26B A4B. La formulazione descrive una raccomandazione, non una garanzia universale.

La VRAM è memoria grafica dedicata utilizzata dalle GPU discrete. La memoria unificata è un pool condiviso utilizzato da processori e hardware grafico su sistemi come i Mac Apple Silicon.

Queste configurazioni si comportano in modo diverso sotto pressione. Una GPU discreta può offrire un elevato throughput di inferenza, mentre la memoria unificata può garantire flessibilità tra attività CPU e grafiche.

La capacità disponibile conta più del totale dichiarato. Una macchina da 24 GB che esegue container, browser, build e più agenti potrebbe avere poco spazio residuo.

Il download del checkpoint da 16,8 GB crea inoltre un onere di distribuzione. Le organizzazioni devono distribuire, verificare, aggiornare e archiviare quell’artefatto sulle macchine approvate.

La provenienza del modello diventa una preoccupazione operativa. I team dovrebbero confermare l’origine di un checkpoint, come è stato convertito e se la sua licenza consente l’uso previsto.

Secondo la documentazione di Google, Gemma 4 è distribuito con licenza Apache 2.0. Fine-tuning esterni e checkpoint convertiti possono introdurre termini separati o questioni di sicurezza.

La qualità del modello presenta un’incertezza maggiore. Google pubblica risultati di benchmark per Gemma 4, incluse valutazioni orientate alla programmazione e agli agenti.

Questi benchmark descrivono il modello sottostante in condizioni di test definite. Non stabiliscono con quale affidabilità Antigravity completi attività lunghe e guidate dagli strumenti sul repository di uno sviluppatore.

L’affidabilità degli agenti amplifica gli errori tra i vari passaggi. Una piccola incomprensione può influire sulla selezione dei file, sull’esecuzione dei comandi, sull’interpretazione dei test e sulla patch finale.

I modelli locali possono anche non includere gli ultimi miglioramenti dei sistemi ospitati. I provider cloud possono aggiornare centralmente i sistemi di inferenza, mentre le distribuzioni locali richiedono aggiornamenti intenzionali e test di regressione.

I team potrebbero preferire questa stabilità. Un checkpoint fisso produce un ambiente più controllato ed evita cambiamenti di comportamento inattesi dopo un aggiornamento di un modello remoto.

Tuttavia, fisso non significa deterministico. Le impostazioni di campionamento, i risultati degli strumenti, lo stato del workspace e la concorrenza possono comunque cambiare gli esiti.

I team di sicurezza devono inoltre esaminare il server locale. Un indirizzo loopback limita l’esposizione, ma una configurazione inadeguata può comunque aprire porte o concedere un accesso troppo ampio al filesystem.

I server compatibili con OpenAI richiedono un controllo analogo. La documentazione di serving vLLM mostra come endpoint locali o privati emulino API di modelli comuni.

La compatibilità migliora la portabilità, ma può nascondere differenze significative. I modelli variano nel formato delle chiamate agli strumenti, nella gestione del contesto, nel comportamento di sicurezza e nel supporto agli output strutturati.

Gli sviluppatori dovrebbero quindi testare l’intero ciclo dell’agente, non soltanto le risposte ai prompt. Un modello che scrive buon codice può comunque faticare a selezionare gli strumenti in modo affidabile.

La raccomandazione hardware di Google restringe il pubblico immediato. Workstation con GPU Nvidia ad alta memoria e sistemi Apple Silicon meglio equipaggiati sono i punti di partenza naturali.

Modelli Gemma più piccoli possono ampliare l’accesso, ma l’annuncio di Google concentra il suo flusso di lavoro ottimizzato sul checkpoint 26B A4B. È la versione a supporto della più forte affermazione di lancio.

Il divario tra “funziona localmente” e “funziona bene sulla mia macchina” resta irrisolto. Le prestazioni varieranno in base all’hardware, alla dimensione del contesto, all’uso degli strumenti e alla complessità del compito.

Non vi sono ancora prove che gli agenti Antigravity offline eguaglino i principali sistemi ospitati nell’intero spettro delle attività di ingegneria del software. Google non ha avanzato questa affermazione più ampia.

L’interpretazione responsabile è più circoscritta. Antigravity può ora eseguire localmente flussi di lavoro agentici significativi, con una configurazione documentata e una sostanziale raccomandazione di memoria.

Questa capacità è importante anche prima della parità di prestazioni. Offre ai team un’opzione distribuibile dove l’inferenza remota era in precedenza vietata o indesiderabile.

Tre segnali mostreranno se gli agenti locali diventeranno la norma

Il prossimo test è capire se l’esecuzione locale diventerà abituale oltre gli esperimenti sensibili alla privacy e le workstation per sviluppatori con molta memoria.

Il primo segnale è un supporto più ampio per modelli e hardware. Gli sviluppatori hanno bisogno di scelte pratiche per macchine al di sotto della raccomandazione di 24 GB.

Varianti Gemma più piccole potrebbero rendere gli agenti offline accessibili a più laptop. Ulteriori checkpoint ottimizzati potrebbero anche consentire ai team di scambiare capacità con velocità e utilizzo della memoria.

Il supporto da solo non sarà sufficiente. Google deve pubblicare dati prestazionali chiari su Apple Silicon, GPU Nvidia e altri acceleratori supportati.

Misurazioni utili includono velocità di generazione, tempo al primo token, utilizzo massimo della memoria e completamento end-to-end delle attività. I benchmark agentici dovrebbero coprire strumenti e recupero in più passaggi.

Se questi risultati mostrano prestazioni accettabili su hardware comune, il percorso locale diventerà più di una funzionalità per specialisti. Risultati deboli rafforzerebbero l’inferenza cloud come impostazione predefinita.

Il secondo segnale è l’evidenza dalle distribuzioni in produzione. Le dimostrazioni iniziali provano che il software funziona, ma non rivelano l’affidabilità quotidiana.

I team dovranno riferire come gli agenti locali gestiscano repository grandi, sessioni lunghe, worker concorrenti e suite di valutazione ripetibili.

L’adozione incentrata sulla sicurezza merita particolare attenzione. Le organizzazioni isolate dalla rete hanno una forte ragione per accettare prestazioni più lente se il flusso di lavoro soddisfa i controlli interni.

Il feedback degli sviluppatori metterà inoltre in luce gli attriti pratici. Errori di installazione, problemi di conversione dei checkpoint, limiti termici ed errori nelle chiamate agli strumenti possono superare i vantaggi architetturali.

Il terzo segnale è la risposta competitiva. Altri framework agentici si collegano già a server di modelli locali, ma la profondità dell’integrazione varia notevolmente.

Il confronto importante non è se un prodotto elenchi Ollama come opzione. È se i modelli locali possano utilizzare gli stessi strumenti, policy, workspace e funzioni di orchestrazione.

I concorrenti potrebbero rispondere con un instradamento locale più solido, inferenza ospitata per le imprese o selezione automatica tra modelli remoti e on-device.

Una risposta rapida sosterrebbe il giudizio di fondo di Google secondo cui la posizione dell’esecuzione sta diventando un criterio d’acquisto. Una risposta limitata suggerirebbe che la domanda resti concentrata tra gli appassionati.

Anche il modello ibrido di Google merita attenzione. Può offrire un equilibrio pratico, ma solo se gli sviluppatori possono verificare quali informazioni raggiungano il pianificatore cloud.

Log chiari, controlli di policy e routing tracciabile conteranno quanto il supporto dei modelli. Le imprese hanno bisogno di prove che i confini dichiarati siano applicati durante ogni turno dell’agente.

Il rilascio dovrebbe inoltre incoraggiare una progettazione più disciplinata delle attività. Gli sviluppatori possono riservare gli agenti locali a lavori circoscritti invece di aspettarsi che un unico sistema gestisca autonomamente un intero progetto.

Gli esempi includono la classificazione di documenti privati, la revisione di un modulo delimitato, la generazione di test o il riepilogo di note tecniche locali. Ogni attività ha input e output misurabili.

Questo approccio si adatta a un più ampio flusso di lavoro AI in cui il contesto sensibile resta vicino all’utente. La revisione umana continua a governare le azioni conseguenti.

I modelli locali dell’SDK Antigravity rendono ora l’esecuzione offline degli agenti un flusso di lavoro Google documentato anziché una soluzione alternativa non ufficiale. Il lancio non risolve le questioni di qualità o accessibilità.

Cambia però ciò che gli sviluppatori possono richiedere a una piattaforma agentica. L’accesso al cloud non deve più essere il prezzo inevitabile dell’automazione.

Il passo successivo più utile è un test concreto. Scegliete un'attività privata e circoscritta, registrate l'utilizzo della memoria e la qualità del completamento, quindi confrontate le esecuzioni locali e quelle ospitate.

L'agente locale protegge il contesto che conta, completando al contempo abbastanza lavoro da giustificare l'hardware? La risposta determinerà se Google ha creato un'architettura predefinita o un'eccezione preziosa.