Il 1 giugno 2026 xAI ha aperto Grok Build 0.1 sulla sua API: niente lista d'attesa, niente abbonamento SuperGrok o X Premium, 25dicreditiquandotiregistrisuconsole.x.ai[1][2].EˋlostessomodellochealimentalaCLIGrokBuild,orarichiamabileconunaAPIkey.Inumerichecontanosonoquellinoiosi:1 per milione di token in input, 2permilioneinoutput,0,20 per milione su input in cache, servito a oltre 100 token al secondo, con una finestra di contesto da 256K e supporto nativo al Model Context Protocol [1].
Non è l'annuncio di un modello di frontiera, ed è esattamente per questo che conta. La gara dei titoli riguarda chi è in cima a SWE-Bench questo mese. La cosa che cambia davvero come lavora un solo dev è più silenziosa: il tier economico e veloce dei modelli di coding ha appena superato la linea tra "va bene per i giocattoli" e "abbastanza buono per fare lavoro agentico vero", e ora l'economia spinge a ribaltare il tuo default. Parti dal modello economico e veloce, ed escala a quello costoso solo per il 10% difficile.
Voglio renderlo concreto, perché "usa il modello economico" suona come un consiglio per risparmiare ed è in realtà una decisione di architettura.
Cosa è uscito
Togli la prosa del lancio ed ecco il nucleo rilevante per chi sviluppa [1][2]:
È sull'API aperta. Grok Build 0.1, il modello dietro la CLI Grok Build di xAI, ora è richiamabile direttamente. Ti registri, ottieni 25$ di crediti, mandi le richieste. Nessun cancello a forma di abbonamento consumer.
Ha un prezzo da loop. 1/Mininput,2/M in output, e soprattutto 0,20$/M sull'input in cache, circa l'85% in meno rispetto alla tariffa cache-miss. Il contesto ripetuto (il tuo system prompt, la mappa del repo) costa pochissimo da rimandare a ogni giro.
È veloce. Oltre 100 token al secondo. La velocità non è una metrica di vanità in un loop agentico: è la differenza tra uno strumento che aspetti e uno con cui iteri.
È nativo MCP. Dichiari i server MCP direttamente nell'array dei tool con "type": "mcp", quindi collegare le tue knowledge base e le tue API interne è una funzione di prima classe, non un'aggiunta posticcia.
È pensato per il coding agentico. Sviluppo web, debugging, task di coding multi-step, il lavoro dove il modello gira in un loop invece di rispondere una volta sola.
Nessuna di queste cifre è inventata da me: vengono dall'annuncio di xAI e dalle notizie che lo hanno seguito, e qui non cito alcun dato di KMP.
Default in basso, escala in alto: instrada il grosso del tuo volume di coding al modello economico e veloce Grok Build 0.1 (1/2 per milione di token, oltre 100 token al secondo, nativo MCP, contesto 256K), e tieni il modello di frontiera costoso per il 10% difficile, lasciando che siano i tuoi test a tracciare la linea
Vuoi sapere quanto sono efficaci i tuoi prompt? Prompt Score li analizza su 6 criteri.
La vera storia è prezzo per velocità, non la classifica
Ecco lo spostamento che la gente si perde perché fissa le tabelle dei benchmark. Quando un modello di coding capace costa 1/2 e gira a oltre 100 token al secondo, puoi permetterti di farlo girare in un loop stretto: genera una modifica, lancia i test, leggi il fallimento, correggi, riprova, tre o cinque volte, e paghi comunque meno di una singola chiamata accurata a un modello di frontiera. Economico e veloce non è una versione peggiore di costoso e lento. In un loop agentico è una forma diversa, e spesso migliore, perché è il loop, non la singola risposta, a produrre codice funzionante.
I costosi modelli di frontiera sono straordinari nel ragionamento difficile one-shot, e sono dolorosi da mettere in loop, sia per la latenza sia per la bolletta. Il tier economico ribalta la cosa. Quindi la domanda smette di essere "quale modello è più intelligente" e diventa "quale modello è abbastanza intelligente da valere un loop su questo task", e per una larga fetta del coding quotidiano la risposta ora è quello economico.
È anche per questo che il prezzo dell'input in cache conta più di quanto sembri. In un loop agentico rimandi lo stesso contesto, il system prompt, la struttura del repo, le convenzioni, a ogni turno. A 0,20$/M quella ripetizione è quasi gratis, il che significa che l'architettura a loop per cui xAI ha messo il prezzo è proprio quella che si aspetta tu usi davvero. Hanno costruito il listino per gli agenti, non per la chat.
La fregatura: economico non vuol dire buono sul tuo codice
La tentazione è leggere "modello da 1$, 70,8% su SWE-Bench" e instradargli tutto. Frena. Quel 70,8% è auto-dichiarato sul harness interno di xAI [1], il che lo rende un'ipotesi di partenza, non un verdetto, e SWE-Bench non è il tuo codice a prescindere da chi l'ha misurato. Un modello eccellente sui task Python pubblici può essere mediocre sul tuo stack specifico, sulle tue convenzioni, sul tuo strano modulo legacy.
Quindi la strategia del default economico funziona solo se sai dove il modello economico si rompe. È un problema di valutazione, ed è la parte che la maggior parte delle persone salta. Prima di instradare una classe di lavoro a Grok Build, fai passare i tuoi task rappresentativi e controlla l'output come controlleresti quello di un junior: passa i test, rispetta le convenzioni, regge sui casi spinosi, non solo su quelli puliti? Lascia che a giudicare sia la tua suite di test, la stessa disciplina che ho sostenuto nel pezzo sull'harness: il guardrail più economico e affidabile che hai è il compilatore con i test, e a loro non importa quale modello ha scritto il codice.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
Trova la linea. Sopra, il modello economico è abbastanza buono e ti tieni il risparmio. Sotto, escali.
La mossa del solo dev: default in basso, escala in alto
Instrada per task, non per classifica: manda boilerplate, scaffolding, refactor con specifica, generazione di test e lavoro a loop al modello economico e veloce Grok Build 0.1; tieni il modello di frontiera per scelte di architettura, bug sottili e il 10% davvero difficile, con la suite di test a tracciare la linea
In concreto, ecco l'instradamento che imposterei la settimana in cui esce un modello così:
Manda il lavoro di massa e meccanico al tier economico. Boilerplate, refactor con una specifica chiara, scaffolding di test, collante web, conversioni di formato, i task ad alto volume e bassa ambiguità. È qui che prezzo per velocità rende, ed è qui che un modello di classe 70% di solito basta e avanza.
Tieni il modello di frontiera per il 10% difficile. Le vere scelte di architettura, il bug di concorrenza sottile, il task dove sbagliare costa caro e una sola risposta costosa e accurata batte cinque risposte economiche e sbagliate. Paga per l'intelligenza esattamente dove l'intelligenza è il collo di bottiglia.
Metti in cache il contesto ripetuto. Piazza il tuo system prompt stabile e il contesto del repo dove vale la tariffa cache da 0,20$, così il loop è economico quanto il listino consente.
Tieni il prompt stesso indipendente dal modello. Ora stai instradando su almeno due modelli per scelta, quindi scrivi intento e vincoli, e tieni l'impalcatura specifica del modello in uno strato che puoi sostituire. Un modello economico e uno di frontiera vogliono un accompagnamento leggermente diverso.
Ri-testa a ogni bump di versione. Questa è la 0.1, una beta esplicita. Il comportamento si muoverà. Qualunque cosa tu abbia validato questa settimana, rivalidala quando cambia il numero dopo il punto.
Il punto non è "Grok Build è il modello migliore". Quasi certamente non lo è, sulla capacità grezza. Il punto è che per la maggior parte del volume reale di coding di un solo dev non stai comprando il migliore, stai comprando l'abbastanza-buono-economico-e-veloce, e quel tier è appena diventato reale.
È lo stesso istinto che i bravi ingegneri hanno già sul calcolo: non lanci ogni job sull'istanza più grande, abbini la macchina al task e tieni l'hardware costoso per il lavoro che lo richiede. I modelli stanno diventando lo stesso tipo di risorsa. Trattare il modello di frontiera come default per tutto comincia a sembrare come far girare uno script batch su un cluster di GPU perché era la macchina che ti era capitato di avere aperta.
Un altro segnale: MCP alla versione 0.1
Vale la pena notare cosa xAI ha scelto di mettere in una 0.1. Supporto nativo a MCP, dichiarato nell'array dei tool, spedito al primo giorno dell'API pubblica [1]. Un anno fa il supporto a tool e protocolli era la cosa che aspettavi per diverse versioni. Ora è un requisito minimo, presente nella prima build pubblica di un modello di coding economico. L'idraulica agentica si è standardizzata in fretta.
Questo è un bene per chi costruisce, e si porta dietro il solito avvertimento: nel momento in cui il tuo modello di coding economico è collegato via MCP a knowledge base interne e API proprietarie, eredita la superficie di prompt injection agentica di cui ho scritto. Economico da chiamare non vuol dire economico da mettere in sicurezza. Collegalo con la stessa cura che daresti a quello costoso.
Il segnale
La gara di frontiera continuerà a prendersi i titoli, e va bene così: quei modelli fanno cose che niente altro fa. Ma per un solo dev che decide dove va il prossimo mese di spesa API, l'evento più consequenziale dell'inizio di giugno non era in cima al benchmark. Era un modello di coding da 1,veloce,nativoMCP,cheatterrasuun′APIapertacon25 di crediti allegati.
Parti dal tier economico e veloce per il lavoro di volume, escala al modello di frontiera per la minoranza difficile, e lascia che siano i tuoi test a tracciare la linea tra i due. Il modello costoso è per i problemi che sono davvero difficili. La maggior parte del tuo coding non lo è, e non devi più pagare come se lo fosse.
Keep My Prompts ti permette di tenere una sola versione di ogni prompt, fargli scoring su sei criteri di qualità, e confrontare come un modello economico e uno di frontiera gestiscono lo stesso task sui tuoi input, così instradi in base alle prove invece che al benchmark. Gratis per iniziare, senza carta di credito.
