AIDiveIntro: dieci mod, ne sopravvivono tre
I mod di Claude Code sono funzioni TypeScript dentro i plugin che possono ridisegnare l'interfaccia di Claude Code o riscrivere ciò che fa, e nel giro di un giorno dal lancio di inizio ottobre tre tour video diversi hanno detto agli sviluppatori di installarne dieci. Due di quei creator ammettono davanti alla camera che alcuni mod non fanno risparmiare niente, e nessuno ne ha misurato uno solo. Questo test lo fa: ognuno dei dieci mod super pubblicizzati ha girato su una settimana di lavoro vera, con un numero per il suo overhead, per i suoi risparmi e un verdetto tenere o eliminare. Il risultato in anteprima: solo tre su dieci meritano un posto sulla macchina di uno sviluppatore che lavora davvero, e uno di loro spende token in silenzio a ogni singola risposta.
L'ondata e cosa abbiamo provato
La definizione di Anthropic sta in un respiro: un mod è una funzione che si aggancia a un evento e può girare prima, dopo o al posto di quell'evento. Un evento è una tool call, un prompt inviato o una parte dell'interfaccia da disegnare. I mod sono semplice TypeScript, distribuiti dentro un plugin che si installa come qualsiasi altro.
Il tweet di lancio ha superato i quattro milioni di visualizzazioni in circa un giorno, con ventimila like e più segnalibri che risposte e repost messi insieme. Due giorni dopo il lancio, un catalogo della community aveva già scansionato più di mille mod pubblici in centinaia di repository.
Il banco di prova di questo test è una settimana di lavoro vera: 85 sessioni su quattro progetti, quasi 900 prompt e poco meno di 6.000 tool call. Ogni mod è passato dall'audit del validator, che elenca a cosa si aggancia e cosa può toccare, e ogni mod ha eseguito lo stesso compito contro una baseline pulita, sulla release corrente, sulla stessa macchina.
La divisione in sintesi: sei dei dieci non costano niente di misurabile a runtime, tre costano tempo o token reali e uno rompe l'unica promessa che fa.
Il livello decorazione, misurato
I sei silenziosi restano entro il rumore della connessione. Il contatore degli obiettivi, la heatmap del repo, il registratore di volo, il router dei modelli, i segnalibri di sessione e l'handoff automatico stanno tutti tra un quarto di secondo risparmiato e un quinto di secondo aggiunto, su un compito di base di circa quattro secondi.
| Mod | Variazione di runtime | Note |
|---|---|---|
| Contatore degli obiettivi | entro il rumore | pannello decorativo |
| Heatmap del repo | entro il rumore | illumina i file man mano che vengono letti |
| Registratore di volo | entro il rumore | timeline in tempo reale del turno |
| Router dei modelli | entro il rumore | rende sui subagent, vedi il verdetto |
| Segnalibri di sessione | entro il rumore | impronta di capacità molto ampia |
| Handoff automatico | ~70 ms a riposo | scrive un handoff a una soglia di contesto |
Sono bellissimi e non si è rotto niente: ogni run di ogni configurazione ha completato il compito correttamente. In headless non costano nulla, perché non c'è niente da disegnare; in un terminale questi pannelli si ridisegnano fino a trenta volte al secondo, quindi il costo onesto del livello decorazione è l'attenzione, non i token.
L'audit del validator è il punto in cui smette di far ridere. Il mod dei segnalibri può chiamare il modello, avviare processi sulla tua macchina e scrivere file, e legge dall'ambiente i percorsi della tua configurazione. Niente di tutto questo è nascosto e niente è malevolo, ma è un bel po' di raggio d'azione per un segnalibro. Quattro mod escono qui: il contatore degli obiettivi, la heatmap e il registratore di volo come decorazione con beneficio misurato pari a zero, e il mod dei segnalibri perché chiede più di quanto renda.
Il mod di punta ti fattura a ogni turno
Il motore di suggerimenti è il mod che ogni video mostra per primo: la risposta finisce, sopra il composer compaiono tre suggerimenti di prompt, premi un numero e la bozza si compila da sola. Il meccanismo è documentato dal suo stesso autore: quando il turno si completa, fa un fork della sessione per chiedere a un modello quei suggerimenti, e il fork condivide la cache del prompt della sessione, quindi costa circa una breve risposta. I tour quella riga non la citano mai.
Misurato sul banco di prova, sono circa 250 token di output in più per risposta qualificante e quasi tre secondi di tempo reale in più, e una risposta qualificante è quasi ogni risposta: qualsiasi cosa più lunga di circa ottanta caratteri. Il fork non ha nemmeno un controllo sulla superficie. I suggerimenti si disegnano solo in un terminale, ma il fork parte ovunque, compresi i run headless dove non si può disegnare proprio niente.
| Mod | Costo misurato | Quando scatta |
|---|---|---|
| Motore di suggerimenti | ~250 token di output + ~2,9 s per risposta qualificante | ogni risposta sopra ~80 caratteri, anche in headless |
| Custode della cache | ~1,5 s per turno, più chiamate al modello in modalità warming | a ogni turno, in warming per ore |
Il custode della cache ha la stessa forma: circa un secondo e mezzo per turno, con una modalità warming che spende piccole chiamate al modello per ore per evitare che la cache del prompt si raffreddi. Con un abbonamento la finestra della cache è già di un'ora, quindi paghi dei ping per risolvere un problema che il piano ha in gran parte già risolto. Sono entrambi design onesti con costi documentati, entrambi sono tasse su ogni turno che le liste di installazione non prezzano mai, ed entrambi escono dalla macchina.
Mod contro hook, lo stesso lavoro
Claude Code aveva già gli hook: uno script shell nelle tue impostazioni che scatta sugli stessi eventi. La documentazione risponde alla scelta con una riga di tabella: un mod serve per l'interfaccia e per riscrivere gli eventi; un hook serve per bloccare, consentire o loggare con uno script che hai già.
La differenza misurabile è lo spawn del processo. Un hook delle impostazioni avvia un processo nuovo a ogni tool call. Cronometrato su questa macchina, un hook shell che non fa niente costa circa 8 ms e un hook che avvia Node circa 43 ms, a ogni singola chiamata, prima ancora che lo script faccia qualcosa. Sulle 5.993 tool call della settimana di test sono oltre quattro minuti di puro avvio dell'interprete. Un mod non paga niente di tutto ciò: il suo handler gira dentro il processo del motore, e il log del motore mostra il passaggio che si risolve in circa un millisecondo.
| Handler | Costo per chiamata | Una settimana di 5.993 chiamate |
|---|---|---|
| Hook shell (no-op) | ~8 ms | ~48 s |
| Hook Node (no-op) | ~43 ms | ~4,3 min |
| Mod (in-process) | ~1 ms | ~6 s |
L'unico vero report di migrazione in circolazione dice la stessa cosa: ventisette hook shell sono confluiti in cinque mod, e con loro è sparito lo spawn a ogni chiamata. La regola che resta: interfaccia o riscrittura di eventi, mod; bloccare, consentire o loggare con uno script di cui ti fidi, hook (il costo dello spawn conta solo su migliaia di chiamate); conoscenza che continui a ripetere, skill. Un hook che hai letto vale più di un mod che non hai letto.
La guardia che non fa niente
Il mod di sicurezza più semplice possibile è una guardia che osserva ogni comando shell, e questa era scritta apposta per andare in crash. A Claude Code è stato chiesto di creare un file marker; la guardia ha lanciato un'eccezione; il comando è partito comunque e il file è apparso. Non è un bug ma il comportamento predefinito documentato: quando un hook lancia un'eccezione, va in timeout o restituisce la forma sbagliata, Claude Code lo salta e va avanti. Una decorazione rotta non dovrebbe bloccare una sessione, ma una guardia rotta fallisce aperta, in silenzio, con una riga in un log di debug che nessuno legge.
La correzione è un solo catch handler che restituisce un deny. La stessa guardia che va in crash, con il catch, rifiuta il comando e nomina il guasto. Una riga decide se una guardia fallisce aperta o chiusa, la documentazione distribuisce proprio questo pattern e quasi nessuno lo installa.
Un team della community ha rieseguito i casi sulla release corrente e ha giudicato dai file marker invece che da ciò che diceva il modello. Il pattern catch ha fallito chiuso tre run su tre, e un percorso è ancora rotto in silenzio: un deny restituito dopo che la chiamata era già stata inoltrata non ferma il tool. Il file è arrivato tre volte su tre mentre al modello veniva detto che la scrittura era fallita.
Il field report che ha dato un nome al problema ha eseguito per giorni una guardia che era abilitata, caricata e non faceva niente, perché un flag obsoleto l'aveva spenta da sotto: tre chip di stato verdi sopra un contatore fermo a zero. Un silenzio che somiglia in tutto alla salute.
La guardia anti-collisione si guadagna il primo "tenere". Risolve un problema reale, due chat aperte che modificano lo stesso file, e il suo modo di fallire è rumoroso: chiede in una finestra di dialogo e non consente mai in silenzio. Costa circa mezzo secondo sulle modifiche e non aggiunge niente al prompt. Installala, e dalle comunque il catch handler.
Cosa concedi quando ne incolli uno
Anthropic lo dice in parole semplici il giorno del lancio: i mod girano con lo stesso accesso alla tua macchina di Claude Code stesso. Non sono in sandbox; installali come installeresti qualsiasi codice sul tuo computer. In concreto, un mod può agire sulla tua macchina come te: leggere il tuo ambiente e le tue impostazioni, dove vivono le chiavi API; vedere ogni prompt e ogni tool call; riscriverli; approvare una tool call prima ancora che ti venga chiesto; e spendere l'uso del tuo piano in chiamate al modello tutte sue.
Due trappole fregano anche gli utenti attenti. Le regole di permesso governano le tool call di Claude, non le chiamate del mod stesso: nega a Claude un file env e un mod può comunque leggere quel file direttamente con il suo accesso ai file, o avviare un programma che lo fa. La policy di rete ha lo stesso limite: spegni il traffico web e le chiamate fetch del mod vengono rifiutate, ma un processo figlio avviato dal mod raggiunge la rete con accesso completo. Esiste un mod di guardia integrato che si carica prima di tutto il resto, ma solo su macchine gestite e per i posti Team o Enterprise; un posto singolo su un abbonamento personale non ne ha niente.
Niente di tutto questo è teorico. Un utente ha pubblicato una proof of concept pochi giorni dopo il lancio: un mod il cui pulsante avvia un programma e scrive nella home directory, installato dal catalogo senza alcun avviso, e il suo punto regge: il catalogo sembra un app store, il che suggerisce una verifica che non c'è. Un bug separato negli hook ha rotto l'isolamento dei subagent per un giorno; il maintainer l'ha chiamato un grosso errore e l'ha corretto una release dopo.
La scansione del catalogo su più di mille mod pubblici: oltre quattrocento avviano processi sull'host, quasi quattrocento leggono file, e oltre trecento vedono ogni tool call. La cautela del catalogo è la cornice giusta: è un'impronta, non un verdetto; un PR tracker deve eseguire git. La disciplina costa due minuti: esegui il validator prima di abilitare qualsiasi cosa e conosci le uscite: safe mode per una sessione, un'impostazione per fermare per sempre ogni hook installato.
Tenerne tre, eliminarne sette
Dei dieci, tre si meritano il posto: la guardia anti-collisione, il router dei modelli e l'handoff automatico.
| Mod | Verdetto | Il numero dietro |
|---|---|---|
| Guardia anti-collisione | tenere | ~0,5 s sulle modifiche, fallisce in modo rumoroso, niente aggiunto al prompt |
| Router dei modelli | tenere | subagent fatturato sul modello economico, un terzo del prezzo |
| Handoff automatico | tenere | 70 ms di niente, una scrittura di handoff alla soglia di contesto |
| Motore di suggerimenti | eliminare | ~250 token di output + ~2,9 s a ogni risposta qualificante |
| Custode della cache | eliminare | ~1,5 s per turno, ping di warming contro una finestra di cache di 1 ora |
| Modalità registrazione | eliminare | maschera lo schermo ma non il disco |
| Contatore degli obiettivi | eliminare | decorazione, beneficio misurato pari a zero |
| Heatmap del repo | eliminare | decorazione, beneficio misurato pari a zero |
| Registratore di volo | eliminare | decorazione, beneficio misurato pari a zero |
| Segnalibri di sessione | eliminare | raggio d'azione ben oltre il suo compito |
Il router dei modelli ha una ricevuta: una sessione sul modello grande ha avviato un subagent, e la lettura dell'uso del run stesso ha mostrato il subagent fatturato sul modello economico, un terzo del prezzo per lo stesso piccolo lavoro. Nelle settimane piene di subagent sono soldi veri. L'handoff automatico non costa niente fino al momento in cui rende: settanta millisecondi di overhead a riposo e, oltre una soglia di contesto, scrive una volta l'handoff per la ripartenza a freddo. Uno dei creator dell'ondata ammette che il pulsante manuale di handoff non fa davvero risparmiare tempo; come scrittura automatica a soglia, invece sì.
La disciplina che sopravvive al test: leggi l'audit del validator prima di abilitare qualsiasi cosa, dai a ogni guardia il suo catch handler così fallisce chiusa, e registra le demo in safe mode invece di fidarti di un mod che maschera. I limiti sono reali: una settimana, una macchina, un carico di lavoro, tre run per punto sul modello piccolo. I tuoi tre potrebbero essere diversi, ma ora sai come trovarli.
