Claude Code vs Gemini CLI
Il terminale è uno, le migliori IA per lavorarci sono due. Quale fa al caso tuo?
⏱️ Lettura: ~10 minuti.
☕ Caffè necessari: un paio. Uno all’inizio e uno dalle parti degli hook.
Patti chiari
Questo scritto presuppone che chi legge sappia già cosa sono Claude Code e Gemini CLI, e magari abbia lavorato almeno una volta con entrambi. Per questo motivo, l’articolo non è neppure corredato da note esplicative. O sai (più o meno) di cosa stiamo parlando, o è meglio se ti fermi qui. Quella che hai sotto gli occhi non è una guida introduttiva, è un confronto. Inoltre, trattandosi di strumenti in rapidissima evoluzione, i rilasci sono a cadenza settimanale e i changelog sono fiumi in piena. Tra sei mesi alcuni dettagli potrebbero essere già archeologia.Se hai dubbi, facciamo un rapido test.
Due filosofie quasi opposte
Claude Code e Gemini CLI sono due agenti IA che partono da presupposti opposti.
Claude Code è codice proprietario (roba di Anthropic), a pagamento, e progettato sull’idea di un controllo umano deliberato e granulare. La sua “estetica” è quella dello strumento da officina: tante leve separate, ognuna col suo scopo, e l’aspettativa che chi lo usa sappia perché sta tirando proprio quella. Il modello sottostante è esclusivamente Claude (Sonnet, Opus, Haiku), selezionabile a mano col comando /model.
Gemini CLI è open-source sotto licenza Apache 2.0, pubblicato su GitHub, con un tier OAuth gratuito sorprendentemente generoso (60 richieste al minuto, 1.000 al giorno). Accede all’intera famiglia Gemini con context window nativa da un milione di token. È pensato per essere accessibile, l’onboarding è una procedura di pochi minuti, e la documentazione (che è una delle migliori che abbia mai visto) è verificabile direttamente sul repo, comprese le scelte di design e i confronti espliciti con Claude Code.
Nessuno dei due è “meglio”. Sono concepiti in modo diverso e lavorano in modo diverso.
Non ti scordar di me
Tutti e due hanno un file Markdown che funge da memoria persistente. In Claude Code si chiama CLAUDE.md, in Gemini CLI GEMINI.md. Il principio è identico: scrivi qui le regole che l’agente deve rispettare sempre in quel progetto, e te le ritrovi caricate in ogni sessione.
Esempio tipico (vale per entrambi):
# Regole del progetto
- Linguaggio: TypeScript strict mode, no `any`
- Test: ogni nuova funzione richiede un test unitario
- Niente console.log in produzione, usare il logger condiviso
- Lo stile è dettato da .prettierrc — non rinegoziabileLa gerarchia di caricamento è la stessa per entrambi: globale (in ~/.claude/ o ~/.gemini/), root del progetto, sottodirectory. Le regole più specifiche hanno priorità contestuale sulle più generali.
Ora vediamo le differenze…
Claude Code ha una scorciatoia elegante: qualsiasi messaggio che inizia con # durante una sessione interattiva non viene processato come prompt, ma proposto come nota da salvare in CLAUDE.md. L’agente chiede solo se la nota va al file di progetto o a quello globale. Quando si lavora a lungo, è il modo più naturale per cristallizzare una regola appena emersa.
Gemini CLI offre invece due cose che Claude Code non ha. La prima è l’importazione modulare: dentro un GEMINI.md puoi includere altri file con la sintassi @path/to/file.md. Esempio concreto:
# GEMINI.md (root del progetto)
@./docs/coding-style.md
@./docs/api-conventions.md
@./docs/testing-rules.md
## Note specifiche del progetto
- L'API gira su porta 8080 in dev
- Il database è PostgreSQL 16Detta come va detta, questa è una figata stratosferica che mi ricorda cosa comportò l’arrivo dei CSS per l’HTML (sì, sono così vecchio): lo stile di codifica vive in un file, le convenzioni API in un altro, le regole di test in un terzo. Se cambi le regole di test, modifichi un file solo. Claude Code, ad oggi, concatena tutto in un documento piatto, marcando i confini con commenti; leggibile, ma poco modulare.
La seconda differenza è il comando /memory. Permette di vedere il contenuto consolidato (/memory show), ricaricare i file senza riavviare la sessione (/memory reload), aggiungere note al volo (/memory add testo), o elencare i file in uso (/memory list). Su Claude Code, per ricaricare un CLAUDE.md modificato a mano, di solito serve un /clear o un riavvio. Detta come va detta, anche questa è una figata stratosferica.
Una nota di metodo che vale per entrambi: nelle sessioni molto lunghe, le istruzioni messe nei messaggi iniziali della conversazione possono essere “compattate” e perse. Anthropic lo documenta esplicitamente. Regola d’oro: le istruzioni importanti vanno nei file di memoria, non nei prompt.
MCP: stesso protocollo, interpretazioni diverse.
Il Model Context Protocol è il meccanismo standard con cui entrambi gli agenti si collegano a servizi esterni (detta facile: è il sistema con cui puoi costruire un tempio greco in Blender, scrivendo posto giusto del terminale “costruisci un tempio greco”): filesystem locali, API web, database, IDE, qualsiasi cosa esponga un endpoint MCP. Su questo terreno, gli strumenti convergono: entrambi supportano stdio per processi locali, SSE e HTTP per server remoti, ma ne implementano la configurazione in modo diverso.
Claude Code dedica un file separato a MCP: .mcp.json nella root del progetto. È versionabile insieme al codice, condivisibile col team, e tenuto distinto da settings.json (che gestisce permission, hook e altro). La scelta è coerente con la filosofia generale: ogni cosa al suo posto e un posto per ogni cosa.
Caratteristica recente: il Tool Search. Per default, gli strumenti MCP non vengono caricati subito ma scoperti su richiesta (lazy loading). Se hai cinque server MCP collegati con venti tool ciascuno, l’agente non si trascina in contesto la documentazione di tutti e cento, ma cerca quel che gli serve, quando gli serve. Quando un server invece è centrale e i suoi tool devono essere sempre visibili, basta impostare alwaysLoad: true. È un ottimo sistema per avere un compromesso accettabile tra capacità di elaborazione e consumo di token.
Gemini CLI integra invece MCP direttamente in settings.json, sotto la chiave mcpServers. Tutto convive nello stesso file (tutte le cose nello stesso posto). Meno modulare, ma più immediato.
In compenso Gemini CLI ha due frecce in più al suo arco. La prima sono le risorse MCP: alcuni server espongono non solo strumenti (azioni eseguibili) ma anche risorse contestuali come file, payload, report. Gemini CLI le scopre automaticamente e permette di referenziarle in chat con la stessa sintassi @ usata per i file locali. Quando il messaggio parte, la CLI legge la risorsa e la inietta nel contesto. È il modo più pulito di portare contenuto strutturato dentro una conversazione.
La seconda è l’integrazione nativa con FastMCP, la principale libreria Python per costruire server MCP. Dalla versione 2.12.3 di FastMCP, il comando fastmcp install gemini-cli configura il server e gestisce le dipendenze automaticamente. Per chi sviluppa server MCP in Python, è una semplificazione notevole.
Last but not least, la sicurezza: Gemini CLI “sanifica” l’ambiente quando lancia processi MCP. Per default rimuove variabili sensibili (token, secret, password, API key) dall’ambiente ereditato. Se un server MCP ha bisogno di una di queste variabili, va dichiarata esplicitamente nella sua configurazione. Claude Code raggiunge un risultato analogo, ma per via diversa, attraverso il sistema delle permission decisamente più complicato per chi è alle prime armi.
Plugin, estensioni, hook (ti serve il secondo caffè)
Claude Code articola l’estensione delle proprie potenzialità con:
Skills — file Markdown (
SKILL.md) che descrivono una competenza specifica. Si invocano con uno slash command o si caricano automaticamente quando rilevanti. Sono il mattone più leggero.Plugins — bundle completi che possono includere skill, comandi, agenti, configurazioni MCP. Esiste una directory ufficiale di plugin con standard di qualità per i contributi di terze parti.
MCP — vedi sopra.
Agent SDK — per chi vuole costruire agenti propri sopra l’infrastruttura.
Ma il pezzo più potente sono gli hook.
Un hook è una regola che dice: “quando succede questo evento del ciclo di vita dell’agente, esegui questa cosa”. La cosa può essere uno script shell, una chiamata HTTP, o addirittura una valutazione fatta da un altro modello LLM. Gli eventi documentati sono dodici e questi sono i più usati:
SessionStart: a inizio sessione, per caricare contesto dinamico.UserPromptSubmit: prima che l’agente elabori il tuo prompt — per validarlo o arricchirlo.PreToolUse: prima dell’esecuzione di qualsiasi tool. Può approvare o bloccare l’azione.PostToolUse: subito dopo, per formattazione o controlli.Stop: quando l’agente finisce di rispondere.
Gemini CLI non ha nulla di equivalente. Il suo sistema di estensione si fonda sulle Extensions (definite in TOML, contengono comandi, tool e config) e sugli Agent Skills, attualmente in preview, che permettono di configurare subagenti specializzati invocabili con /agent skill-name. C’è anche supporto per subagenti remoti via protocollo A2A.
Quello che manca è l’aggancio agli eventi del ciclo di vita. Il controllo deterministico sulle azioni passa per il Policy Engine (configurabile in settings.json) e per il sistema di approvazione interattiva. Funziona tutto, ma non offre la stessa flessibilità di Claude Code.
E poi arriva Gemma
Vale la pena una piccola digressione su una feature di Gemini CLI implementata alla fine di aprile che a prima vista sembra faccia una cosa, ma in realtà ne fa un’altra.
Gemini CLI può usare Gemma 3 1B in esecuzione locale sulla macchina dell’utente. Sembrerebbe l’ennesima opzione di “modello locale per non dipendere dal cloud” e invece no. Gemma qui non genera niente. Fa il router: classifica le richieste e decide a quale modello cloud mandarle. Le richieste semplici (lettura di un file, una domanda banale) vengono indirizzate a Gemini Flash, velocissimo e molto economico; quelle complesse vanno a Gemini Pro.
Il vantaggio è economico: un classificatore locale (che gira in pochi millisecondi e consuma circa un giga di disco) è gratis. Pagare un modello cloud per fare classificazione su ogni richiesta sarebbe inutilmente caro. Se il server locale è giù, la CLI ricade silenziosamente sul classificatore cloud.
Claude Code, allo stato attuale, non supporta alcun modello locale e opera esclusivamente in cloud. Aggiungiamo inoltre che, anche se Gemma per adessoè solo un “orchestratore” e non un’alternativa generativa, le cose potrebbero cambiare a breve.
Tabella sinottica
Quale scegliere?
Domanda sbagliata. La domanda giusta è: cosa devi fare?
Se il lavoro richiede un controllo deterministico sull’esecuzione (quality gate, formattazione automatica, blocco di azioni rischiose, audit di compliance), gli hook di Claude Code non hanno equivalenti.
Se invece la priorità è una context window enorme (un milione di token, su Gemini 2.5 e successivi, sono molti file in un colpo solo), un tier gratuito per cominciare a sperimentare senza spendere, l’open-source per ispezionare e modificare il comportamento dell’agente, le risorse MCP per portare contenuto strutturato in chat, e una configurazione più immediata, Gemini CLI è la scelta giusta.
Esiste poi una terza opzione, sempre più diffusa nei workflow seri: usarli entrambi, su progetti diversi o anche sullo stesso progetto per compiti diversi. I file CLAUDE.md e GEMINI.md possono coesistere nella stessa repo senza interferire, e il loro contenuto può perfino essere quasi identico.
Una sola cosa è certa: tra sei mesi metà di quanto scritto qui sarà già obsoleto. Il che ci porta alla prossima domanda sbagliata.
Prof, lei quale usa?
Per adesso, Gemini CLI.
Sitografia
Anthropic — Claude Code Documentation: https://docs.claude.com/en/docs/claude-code
Google — Gemini CLI (repo GitHub ufficiale): https://github.com/google-gemini/gemini-cli
Google — Gemma Models: https://ai.google.dev/gemma