Gli agenti di coding da terminale sono ormai una categoria affollata, e quasi tutti condividono lo stesso difetto di fondo. Sono applicazioni Node.js o Python che trascinano dietro di sé centinaia di megabyte di dipendenze, impiegano qualche secondo ad avviarsi e occupano memoria come un browser aperto su venti schede.
fx prende la strada opposta. È un agente scritto in Zig e compilato in un singolo binario nativo da 6,13 MiB, senza runtime da installare e senza node_modules. Nasce come strumento interno di Vercel Labs e il 17 agosto 2026 è diventato open source con licenza Apache-2.0, arrivando in pochi giorni alla versione 0.0.5.
I numeri di lancio sono due, entrambi rivendicati da Vercel. Un avvio a freddo misurato in 10 microsecondi e un consumo di memoria di base che resta a una sola cifra di megabyte. Il motivo è che il programma non compie alcun lavoro superfluo prima di accettare il primo input.
Il resto del progetto segue la stessa logica minimalista. L’interfaccia somiglia più a una shell Unix che a un editor dentro il terminale, la cronologia di scorrimento resta intatta, l’output è essenziale e il rendering grafico viene usato con parsimonia. Non c’è telemetria di prodotto, le sessioni restano sul disco locale e nulla lascia la macchina se non le richieste di inferenza.
Gira su macOS e Linux, sia su x86_64 sia su arm64, mentre su Windows serve passare da WSL. Chi lavora già con Aider o con altri agenti da riga di comando troverà molte cose familiari, ma il modo in cui fx le realizza merita uno sguardo attento.
fx: perché scriverlo in Zig e non in TypeScript
La scelta del linguaggio non è un vezzo da programmatori di sistema. Zig compila in anticipo verso codice nativo, quindi il binario contiene tutto ciò che serve e non deve avviare alcun interprete. Non esiste una fase di caricamento dei moduli, non esiste un garbage collector che si sveglia a metà di una richiesta, non esiste una cartella di dipendenze da aggiornare.
Il confronto con la concorrenza è immediato. Un agente in Node parte in un paio di secondi nel migliore dei casi, mentre fx è già pronto prima che il terminale abbia finito di disegnare il prompt. Su una singola sessione la differenza sembra trascurabile, ma cambia natura quando l’agente viene invocato decine di volte al giorno dentro script, hook di Git o pipeline di integrazione continua.
Lo stesso codice compilato serve tre scenari diversi, e questa è la parte architetturalmente interessante.
- CLI nativa. Il comando
fxavvia la sessione interattiva nel terminale, con la cartella corrente come area di lavoro principale. - Server ACP. Con
fx acpl’agente parla l’Agent Client Protocol su standard input e output, così un editor compatibile può pilotarlo senza sapere nulla della sua interfaccia. - Build WebAssembly. Lo stesso toolchain produce
fx-core.wasmefx-term.wasm, caricabili da JavaScript concreateFxAgent()ocreateFxTerminal()per costruirci sopra un’interfaccia web. La pagina di prova sufx.sh/trygira proprio così, dentro il browser.
Un solo motore richiamabile in tre modi. Dentro ci sono il supporto WebAssembly, la gestione del protocollo ACP e un motore di rendering per il terminale.
Installazione, autenticazione e primo giro nel progetto
L’installazione passa da uno script. La documentazione di fx spiega passo per passo cosa fa lo script, invitando a leggerlo prima di eseguirlo.
# Installazione rapida (macOS e Linux, x86_64 e arm64)
curl -fsSL https://fx.sh/setup.sh | bash
# Oppure scarica, leggi ed esegui la copia che hai letto
curl -fsSL https://fx.sh/setup.sh -o setup.sh
less setup.sh
bash setup.sh
# In automazione conviene fissare una versione
curl -fsSL https://fx.sh/setup.sh | bash -s -- 0.0.5
Il binario finisce in ~/.local/bin e lo script aggiunge la cartella al PATH modificando il profilo della shell, che sia ~/.zshrc, ~/.bashrc o la configurazione di fish. Un dettaglio da tenere presente è che gli archivi vengono scaricati senza verifica di firma o checksum pubblicato, quindi in un contesto aziendale serve un controllo proprio.
Chi preferisce compilare da sé ha bisogno di Zig 0.16 o successivo, e in tre comandi ottiene lo stesso risultato.
git clone https://github.com/vercel-labs/fx.git
cd fx
zig build -Doptimize=ReleaseSafe
./zig-out/bin/fx --version
Sull’autenticazione fx offre più strade. Il percorso principale è fx login, che apre il flusso di autorizzazione Vercel e salva la sessione in ~/.fx/auth.json. In alternativa fx setup accetta una chiave API dell’AI Gateway, conservata nel Keychain su macOS e in ~/.fx/api-key con permessi 0600 su Linux.
La novità della 0.0.5 interessa chi paga già un abbonamento altrove, perché fx login codex e fx login grok permettono di usare le sottoscrizioni Codex e Grok invece dei crediti Gateway. Il modello predefinito è GLM 5.2 di Z.ai, sostituibile con /models o con la variabile FX_MODEL per un singolo processo.
cd ~/progetti/mio-repo
fx
# Verifica la configurazione attiva
fx status
fx doctor
# Riprendi l'ultima sessione di questa cartella
fx resume last
Dentro la sessione, / apre l’elenco dei comandi, @ cerca un file, $ cerca una skill e ctrl+o mostra la revisione completa delle modifiche. Il resto si impara scrivendo richieste in linguaggio naturale che citino file e comandi reali.
Permessi e comandi di fx
Ogni chiamata a uno strumento passa da un controllo prima di essere eseguita. Leggere, cercare e listare file dentro l’area di lavoro non richiede approvazione, mentre write_file, edit_file, delete_file, run_command, install_skill e le operazioni fuori dalla cartella di lavoro sì.
Le modalità sono tre da scegliere con criterio.
| Modalità | Comportamento |
|---|---|
ask | chiede conferma prima di ogni chiamata sensibile non risolta da una regola |
auto | applica le regole salvate, poi fa revisionare automaticamente il resto |
yolo | disattiva i controlli di fx per quella esecuzione |
La modalità auto è quella predefinita. La revisione automatica invia una richiesta separata all’AI Gateway usando gpt-5.4 come revisore, indipendentemente dal modello che hai scelto per lavorare. Ogni chiamata in auto costa quindi più della stessa chiamata in ask.
Le regole vivono in ~/.fx/settings.json e possono essere globali o legate a una singola area di lavoro. I file .fx.json dentro il repository non possono definirle, così clonare un progetto altrui non ti cambia i permessi sotto il naso.
{
"permission": {
"*": "ask",
"bash": {
"git *": "allow",
"git push *": "deny"
},
"edit": {
"docs/*": "allow",
"*": "deny"
}
}
}
Qui arriva la parte che chi valuta lo strumento deve leggere con attenzione. Fino alla 0.0.4 fx includeva una sandbox del sistema operativo, disponibile su macOS, che limitava le scritture di un comando approvato alla cartella di lavoro. La 0.0.5 ha rimosso quella sandbox: i comandi approvati ora girano come normali processi figli del sistema, e la configurazione relativa è stata ritirata.
La documentazione online non è ancora del tutto allineata a questo cambiamento, quindi il consiglio pratico è verificare con fx permissions --json cosa stia effettivamente applicando la versione installata. Il livello di isolamento, oggi, è quello che offre il tuo sistema operativo, non quello che offre fx.
Skill, MCP e subagent
Una delle decisioni più intelligenti di fx è non aver inventato l’ennesimo formato proprietario per le istruzioni riutilizzabili. Una skill è una cartella con dentro un file SKILL.md, con frontmatter YAML e istruzioni in Markdown, esattamente come in altri agenti.
La ricerca delle skill parte dall’area di lavoro e risale verso l’alto, controllando skills/, .fx/skills/, .claude/skills/, .codex/skills/, .opencode/skills/ e .agents/skills/, poi le stesse cartelle sotto la home. In pratica, se hai già una libreria di skill scritta per un altro agente, fx la vede senza che tu debba spostare un file.
All’avvio fx legge solo i metadati, mentre le istruzioni entrano nel contesto unicamente se la skill viene invocata, così se hai venti skill installate non si mangiano la finestra di contesto a ogni richiesta.
# Dentro la sessione interattiva
/skills # apre il catalogo
/skills install vercel-labs/agent-skills --skill find-skills
/skills create mia-skill
/skills path # dove finiscono le skill gestite
Sul fronte MCP, fx è un client a tutti gli effetti e la configurazione risiede solo in ~/.fx/mcp.json. I file MCP dentro un repository non vengono mai letti né eseguiti, quindi clonare un progetto non può aggiungere un server alla tua configurazione. È una scelta di sicurezza che altri strumenti farebbero bene a usare.
{
"mcp": {
"local-tools": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-everything"],
"enabled": true
},
"remote-tools": {
"type": "http",
"url": "https://mcp.example.com/mcp"
}
}
}
Anche qui la gestione del contesto è pensata bene, perché gli strumenti vengono scoperti su richiesta tramite mcp_search_tools e caricati solo quando servono. Un catalogo con centinaia di strumenti non intasa il prompt.
Chiudono il quadro i subagent, sessioni figlie che condividono area di lavoro e runtime ma hanno modello, livello di ragionamento, permessi e trascrizione propri. Si aprono con ctrl+x, possono essere temporanei o persistenti, e i messaggi tra genitore e figlio restano in coda su disco. Un figlio creato dal modello eredita i permessi del chiamante e non può chiedere autorità più ampia, mentre uno creato a mano dal pannello può partire in yolo, quindi quella casella va guardata prima di premere invio.
fx ask, l’agente dentro uno script o una pipeline CI
La modalità che rende fx diverso dagli agenti pensati solo per la sessione interattiva è fx ask, che esegue una singola richiesta e termina. L’output normale finisce su standard output in Markdown, mentre avanzamento e diagnostica restano su standard error, così una redirezione produce un file pulito.
# Richiesta singola
fx ask "spiega cosa fa questo repository"
# Prompt generato da uno script
printf "riassumi src/core\n" | fx ask
# Output strutturato, filtrato con jq
fx ask --json "riassumi le modifiche correnti" | jq -r .output
# Senza creare una sessione salvata
fx ask --no-save "elenca i file di test senza asserzioni"
# Continua la conversazione precedente
fx ask --resume last "ora aggiungi i test"
L’oggetto JSON restituito contiene il testo della risposta, il codice di uscita, il modello usato, l’identificativo di sessione, il numero di passi, il conteggio dei token e l’elenco delle chiamate agli strumenti con il loro esito. Puoi costruirci sopra automazioni, per esempio un controllo che commenta una pull request o uno script che riassume le modifiche del giorno.
In esecuzione non interattiva i permessi si comportano in modo diverso. Le regole salvate continuano ad applicarsi, --auto fa revisionare automaticamente le richieste non risolte, ma se una chiamata resta in sospeso fx esce prima di eseguire lo strumento invece di restare in attesa di un intervento umano che non c’è.
Esistono poi due comandi che fanno risparmiare tempo su lavori ripetitivi, ovvero fx pr e fx issue, che preparano una bozza di pull request o di issue a partire dal contesto del repository. Con --create la pubblicano usando gh, la CLI ufficiale di GitHub, che va installata a parte.
Chi ha bisogno di riservatezza totale può puntare fx verso endpoint di loopback compatibili, usando modelli in esecuzione sulla propria macchina. Con la rete in uscita bloccata, prompt e contesto restano interamente locali e nessuno strumento di rete può fare richieste.
Cosa aspettarsi da una versione 0.0.5
Il primo limite è dichiarato dagli stessi autori, fx è sperimentale. In quattro giorni si è passati dalla 0.0.1 alla 0.0.5 con due cambiamenti incompatibili, tra cui la rimozione della sandbox e lo spostamento della selezione del provider dentro /setup. Se cerchi uno strumento stabile su cui basare il flusso di lavoro di un team, non è ancora questo il momento.
Il secondo limite riguarda le piattaforme supportate, cioè macOS e Linux su architetture x86_64 e arm64. Non esiste una build nativa per Windows, quindi chi lavora lì deve passare da WSL, con tutte le frizioni che questo comporta su percorsi e permessi dei file.
C’è poi una dipendenza di fondo. Il codice è libero e gratuito, ma ogni richiesta al modello passa dall’AI Gateway di Vercel, sia con il login sia con la chiave API. Puoi usare modelli di provider diversi e persino i tuoi modelli locali, però il percorso predefinito ti porta dentro l’infrastruttura di Vercel, che vede metadati come modello, token, latenza e costo.
Sul piano della privacy il quadro è comunque migliore della media. Nessuna telemetria di prodotto, sessioni e cronologia salvate solo in ~/.fx/, controllo degli aggiornamenti senza identificatori della macchina, e per i piani Pro ed Enterprise la possibilità di attivare la Zero Data Retention a livello di team.
Un tool affilato per chi vive nel terminale
fx non è un prodotto per tutti. Chi cerca un assistente che ti prenda per mano dentro l’editor troverà strumenti più comodi e più maturi. Chi invece passa la giornata in una shell, scrive script e considera un buon programma quello che fa una cosa sola e la fa in fretta, qui trova qualcosa che parla la sua lingua.
La combinazione che rende fx interessante nel lungo periodo è quella tra fx ask con output JSON, il server ACP e la build WebAssembly. Sono tre modi di richiamare lo stesso motore, e insieme trasformano un agente da terminale in un componente riutilizzabile dentro sistemi più grandi.
Il consiglio è di provarlo su un progetto secondario, con la modalità permessi impostata su ask e qualche regola scritta a mano per i comandi che ripeti sempre. Quattro comandi per installarlo e disinstallarlo si riducono a cancellare un binario e una cartella, quindi il costo di una prova è vicino a zero.
