ThothII/docs/research/2026-09-07-pi-config-vs-oh-my-pi.md

Pi + pi-config di Amos vs Oh My Pi

Ricerca aggiornata al 7 settembre 2026. Fonti: esclusivamente repository, documentazione, sorgenti, issue tracker e release ufficiali dei progetti.

Risposta breve

Per la maggior parte degli sviluppatori che vuole un agente completo e pronto all'uso, sceglierei Oh My Pi (OMP), ma non con le impostazioni di sicurezza predefinite. OMP integra provider, routing per ruolo, LSP/DAP, subagent, web, browser, sessioni, memoria, marketplace e una UX terminale molto più ampia. È un prodotto coerente, installabile e aggiornabile come tale.

Sceglierei invece Pi con pezzi selezionati di pi-config se volessi un nucleo piccolo, leggibile e fortemente personalizzabile, accettando di assemblare, verificare e mantenere personalmente ogni componente. Il vantaggio non è avere più funzioni: è sapere con precisione quali funzioni si stanno aggiungendo.

La prima distinzione è fondamentale:

• amosblomqvist/pi-config non è una distribuzione alternativa di Pi. È la configurazione personale di Amos Blomqvist: una raccolta di estensioni e skill da copiare selettivamente sopra il Pi ufficiale. Il README invita esplicitamente a non installarla come un unico pacchetto e a non clonarla sopra la propria configurazione.
• Per “Oh My Pi” qui si intende can1357/oh-my-pi, il fork integrato di Pi che si presenta come agente “batteries included”. Non è un semplice tema o dotfile pack.

Di conseguenza il confronto corretto è Pi ufficiale + componenti scelti da pi-config e dai repository companion contro OMP come fork/prodotto integrato.

Confronto spalla a spalla

Area	Pi + pi-config	Oh My Pi	Valutazione
Installazione	Prima si installa Pi, poi si copiano singole estensioni/skill in ~/.pi/agent/; alcuni componenti richiedono npm install, Chromium, Python o tool di sistema. Il README di pi-config raccomanda la selezione manuale.	Installer shell/PowerShell, Homebrew, Bun, Nix e mise, più binari multipiattaforma nelle release.	OMP: onboarding e aggiornamento più coerenti.
Filosofia	Pi è un harness terminale minimale, esteso tramite TypeScript, skill, prompt template, temi e pacchetti; evita intenzionalmente alcune funzionalità integrate, inclusi subagent e plan mode, per lasciarle alle estensioni (README Pi). pi-config porta questa filosofia all'estremo: si prendono solo i pezzi voluti.	Fork “batteries included”: molte capacità sono native o integrate e configurabili da una superficie comune (README OMP).	Dipende: controllo e semplicità a Pi; completezza a OMP.
Provider e modelli	pi-config non aggiunge provider. Eredita da Pi login per Anthropic/OpenAI/Copilot, numerosi provider API, servizi cloud, OpenRouter e modelli locali/custom (provider Pi).	Dichiara oltre 60 provider e modelli locali/remoti; assegna modelli distinti ai ruoli default, smol, slow, plan, commit, vision, task, advisor e tiny, con fallback e credenziali multiple (model routing OMP).	OMP per ampiezza e routing; Pi resta già provider-agnostic.
Prompt e istruzioni	Pi supporta AGENTS.md, SYSTEM.md, APPEND_SYSTEM.md e prompt template. prompt-snippets aggiunge piccoli frammenti attivabili per singolo messaggio, poi azzerati (sorgente/README).	Stessi concetti di personalizzazione del prompt, con override globali/progetto/modello (documentazione); aggiunge ruoli modello, advisor e agent personalizzati.	OMP per orchestrazione; pi-config ha la migliore micro-UX per regole effimere per messaggio.
Subagent	Non nativi nel core. Il companion pi-interactive-subagents avvia agent asincroni in pannelli tmux, persistenti e pilotabili; include scout, researcher e worker, loadout a allowlist e nesting esplicito.	Subagent di prima classe con batch, modalità sincrona/asincrona, output strutturato, Agent Hub, steering/revive/kill e ricorsione controllata. L'isolamento del workspace esiste, ma è opt-in, non una proprietà automatica di ogni spawn (task).	OMP per orchestrazione complessiva; Amos per pannelli tmux e minimo privilegio più semplice da verificare.
Tool di coding	Il core Pi espone un set volutamente piccolo; pi-config aggiunge soprattutto browser, fetch/search, guard e UI di domande.	Lettura/scrittura/editing e AST, grep/glob, shell ed evaluator persistenti, LSP, DAP, code review, security scan, checkpoint/rewind e altri tool elencati nel README. Alcuni sono disattivati inizialmente.	OMP, nettamente, per intelligence sul codice e debug.
Web e browser	browser usa Playwright/Chromium headless ed è spento di default; è una singola pagina senza download/upload. web-search usa Google Custom Search e richiede API key/CSE (sorgente); c'è anche web-fetch.	Browser/computer integrati e ricerca con numerosi backend, inclusi servizi a pagamento, locali/pubblici e motori specializzati (README).	OMP per copertura; pi-config è più piccolo e comprensibile.
Skill e plugin	Skill file-based native di Pi più quattro skill incluse: analisi sessioni, PDF, web debug e trascrizione YouTube (inventario). learn, dictation, memoria e subagent sono repository separati.	Skill caricate progressivamente tramite metadata e URI skill:// (skill docs); marketplace per plugin Git/local/catalogo, con skill, comandi, agent, hook, tool, MCP e LSP (marketplace).	OMP per distribuzione e composizione.
MCP e interoperabilità	Dipende dalle capacità/estensioni del Pi base; pi-config non offre un livello MCP proprio.	Configurazione MCP utente/progetto e discovery di configurazioni provenienti anche da altri editor/agenti (MCP docs).	OMP.
UX/TUI	TUI Pi pulita con editor, fuzzy file search, immagini, shell, steering/follow-up e alberi di sessione. ask-user-question aggiunge un dialogo strutturato; snippets e pannelli tmux sono distintivi. pi-dictate aggiunge dettatura Deepgram.	TUI più ricca con card dei tool, preview/accettazione edit, picker, Agent Hub e time-travel; include sia sintesi vocale sia STT tramite scorciatoia Alt+H (README OMP).	OMP in generale; la semplicità di Pi può essere un pregio. La voce non è esclusiva della configurazione Amos.
Sessioni	Pi salva JSONL ad albero, consente resume/fork/clone/tree e compaction conservando lo storico (sessioni Pi).	JSONL append-only, struttura ad albero, blob esterni e ricostruzione versionata (formato); dump/export/share/fork/resume sono documentati come operazioni native (operazioni).	OMP, di poco, per operazioni integrate; i due condividono una base concettuale simile.
Memoria	pi-observational-memory è opzionale e spento di default: observer LLM paralleli distillano i turni, una compaction deterministica crea un ledger e un consolidatore produce file Markdown per sessione. È auditabile, ma aggiunge costo e complessità.	Memoria spenta di default con backend local, Hindsight, Mnemopi e Sharpshooter; sommari/lezioni possono attraversare sessioni e alimentare skill, con esplicita avvertenza che la memoria può essere obsoleta (memory docs).	OMP per scelta e integrazione; Amos per un modello per-sessione semplice da ispezionare.
Sicurezza applicativa	Pi dichiara di non avere un permission system integrato per filesystem, processi, rete o credenziali e consiglia container/microVM (security Pi). bash-guard intercetta euristicamente solo chiamate al tool bash: non protegge write, edit né i comandi !.	Ha policy per tool e tre approval mode, ma il default è yolo; in tale modalità gli override di comandi bash critici non forzano il prompt. Anche quando si approva un comando non c'è contenimento di filesystem, rete o subprocessi (approval docs). L'offuscamento dei segreti esiste ma è spento di default (secrets docs).	Nessun vincitore sicuro di default. OMP offre controlli migliori, ma sceglie un default molto permissivo.
Isolamento	Nessun sandbox OS o worktree per-agent documentato; l'allowlist del loadout limita i tool, non il filesystem raggiungibile dai tool concessi.	Gli spawn normali condividono la cwd del parent. Workspace separato e merge patch/branch richiedono task.isolation.enabled e isolated: true sul task; l'opzione non è disponibile in plan mode (task). Neppure questo è un sandbox OS.	OMP per isolamento anti-collisione opt-in; parità negativa come confine di sicurezza.
Portabilità	I componenti sono piccoli file TypeScript/Markdown copiabili, quindi il lock-in concettuale è basso. Però molte estensioni Amos importano ancora il vecchio scope @mariozechner/*; il Pi attuale usa @earendil-works/*. L'advisory ufficiale depreca il vecchio pacchetto, quindi oggi serve una verifica/possibile migrazione degli import.	Binari e setup multipiattaforma; importa varie convenzioni esterne. Tuttavia si è allontanato dal Pi upstream: scope @oh-my-pi, runtime/test Bun, moduli nativi, auth e API proprie sono differenze dichiarate nella guida di porting.	Pi + selezione manuale per lock-in ridotto; OMP per portabilità operativa immediata.
Migrazione delle estensioni	È l'ambiente nativo della raccolta Amos, salvo la transizione di package scope appena citata.	Non tratta .pi/extensions come root nativa. Può leggere dichiarazioni pi.extensions nei manifest, ma il caricamento e le API non rendono la migrazione automaticamente compatibile (extension loading).	Non è drop-in in nessuna direzione; verificare ogni estensione.
Aggiornamenti e manutenzione	pi-config è un piccolo snapshot personale, senza release versionate; il registro commit mostra pochissimi cambiamenti e l'integrazione è responsabilità dell'utente. I companion hanno cicli propri.	Distribuzione versionata con release frequenti e asset per piattaforma; al 7 settembre 2026 la release più recente è v18.1.13.	OMP per manutenzione di prodotto; le release molto rapide aumentano anche il rischio di churn.
Maturità pratica	Il Pi sottostante è un progetto attivo e maturo, ma pi-config non è testato o pubblicato come distribuzione unitaria. L'autore di pi-dictate, per esempio, lo presenta esplicitamente come tool personale mantenuto per il proprio uso (README).	Repository ampio, migliaia di commit e cadenza di release elevata (storia, release). Più integrazione e utenti implicano più validazione reale, ma anche superficie di bug e regressioni maggiore.	OMP come prodotto; nessuna garanzia che “più grande” significhi “più stabile”.

Approfondimento: gestione dei subagenti

Sì: OMP ha una gestione dei subagenti paragonabile e, come orchestratore automatico, più completa. La proposta Amos non è però semplicemente inferiore: privilegia un diverso modello operativo, nel quale ogni agente vive in un vero pannello tmux che l'utente può osservare e usare direttamente, con un loadout strettamente autorizzato.

Capacità	Pi + Amos pi-interactive-subagents	Oh My Pi
Esecuzione e fan-out	Sempre asincrono e non bloccante; più chiamate partono in parallelo e notificano il parent indipendentemente (README, “How it works”). Non è documentato un limite di concorrenza configurabile.	task.batch è attivo di default e accetta tasks[]; con async.enabled=true gli agenti sono job in background, altrimenti il parent attende. Un semaforo task.maxConcurrency limita sia sync sia async (task: input, modi e limiti).
Messaggi fra agenti	subagent_message corregge uno spawn in corsa al prossimo confine di turno o riapre quello concluso; ask_question permette al child di parcheggiarsi e interrogare il parent (messaging).	hub send consegna steering/follow-up, anche agli agenti parcheggiati, che vengono riattivati; la messaggistica peer è disponibile anche ai child (task, “Notes”). Limite documentato: lo steering è testo libero, non uno stato condiviso strutturato di goal/todo.
Supervisione e intervento umano	Widget con stati starting/active/waiting/stalled/running, tool corrente e completamenti espandibili; il pannello tmux è la sessione reale, quindi l'utente può entrarvi e scrivere direttamente (status widget).	Alt+A apre Agent Hub: roster/albero, attività, modello, costo/token, transcript live, steering, revive e kill; l'utente può mettere a fuoco la sessione del child e scrivergli (Agent Hub). OMP non manca quindi della supervisione interattiva; Amos la rende più concreta e terminal-native tramite pannelli separati.
Resume e persistenza	Registro nome→sessione persistente attraverso i riavvii; il resume ripristina lo snapshot del loadout originale. Supporta sessioni standalone, lineage-only o fork con contesto del parent (resume, session mode).	Salva output e transcript (agent://, history://); agenti idle/parcheggiati sono riattivabili anche dopo il resume del parent (Agent Hub, “Persisted agents”). Eccezione importante: un task eseguito in workspace isolato viene smontato dopo merge/cattura patch e non è riattivabile (task flow).
Definizioni e routing modelli	File Markdown in .pi/agents o ~/.pi/agent/agents, con modello, thinking, skill, tool, cwd e modalità sessione; il singolo spawn può sovrascrivere il modello. Include tre profili (scout, researcher, worker) (custom agents).	File Markdown .omp/agents, agent inclusi e provenienti da estensioni/plugin; routing con override per nome, lista fallback e alias modelRoles, più effort per task, prewalk e advisor opzionali (agent definition, routing).
Tool e sicurezza applicativa	Allowlist stretta: il child parte con --no-extensions e riceve soltanto i tool e le estensioni esplicitamente elencati; lo snapshot preserva il vincolo al resume (tool access). È minimo privilegio applicativo, non sandbox OS.	Ogni definizione può limitare tools e spawns, e il limite di profondità rimuove task; però i child headless forzano tools.approvalMode: yolo, perché non hanno una UI locale per le conferme (task flow). Di conseguenza la qualità dell'allowlist/deny policy del parent è un confine essenziale.
Agenti annidati	Solo se subagent_agents è presente; la lista autorizza nomi precisi a ogni livello e non esiste uno spawn senza profilo nominato (tool access). Il parent attende anche i nipoti prima dell'auto-exit.	Supportati con policy spawns e limite task.maxRecursionDepth (default 2); al limite il tool task viene rimosso (recursion gating). Agent Hub conserva la gerarchia parent/child.
Filesystem, worktree e conflitti	cwd può assegnare una directory diversa, ma il README non documenta workspace/worktree isolati né merge automatici (role folders). Inferenza: più worker scriventi nella stessa checkout possono quindi collidere; separare le cwd resta responsabilità dell'orchestratore/utente.	Lo spawn ordinario usa la cwd del parent. L'isolamento è disponibile soltanto con configurazione globale attiva, isolated: true, repository Git e fuori dal plan mode; può applicare patch o cherry-pickare un branch (task modes). Verifica l'applicabilità della patch; in caso di conflitto lascia l'artefatto per intervento manuale e preserva lo stash in branch mode (gestione conflitti).
Output	Il risultato è l'ultimo messaggio assistant, inoltrato al parent; non è documentato un contratto JSON Schema né un merge di file (auto-exit).	outputSchema per item, modalità permissive/strict, risultato parsato e artefatti completi tramite agent://; il child deve concludere con yield, con fino a tre reminder (task outputs, flow).
Portabilità e prerequisiti	Questa variante è esplicitamente tmux-only e richiede Pi + tmux (requirements); l'upstream HazAT supporta più multiplexer, ma non è il componente qui confrontato.	Il runtime OMP è multipiattaforma; l'isolamento seleziona backend diversi per Linux, macOS e Windows e ricade su copia ricorsiva quando necessario (backend di isolamento).

Giudizio mirato

Per orchestrazione di subagenti sceglierei OMP, perché combina fan-out controllato, sync/async, Agent Hub, messaggistica peer, output tipizzato, nesting con limiti e isolamento anti-collisione opzionale. Quindi la risposta alla domanda “ce l'ha anche OMP?” è sì, e sul piano funzionale offre di più.

Pi + Amos resta preferibile in due casi: quando si vuole entrare fisicamente nei pannelli dei worker mentre lavorano, oppure quando si considera prioritaria una politica child “deny by default” molto leggibile. La sua gestione può essere ottimale per un power user tmux; non è però altrettanto completa come orchestratore automatico, soprattutto per output strutturato, concorrenza limitata e gestione/merge degli artefatti.

Due caveat impediscono un verdetto semplicistico:

1. in OMP “subagent isolato” non significa “ogni subagent”: senza entrambi i toggle necessari, gli agenti scriventi condividono la checkout;
2. isolamento e continuità sono in tensione: il child OMP isolato evita collisioni, ma dopo il merge/cleanup non può essere riattivato; uno non isolato può invece essere parcheggiato e ripreso.

Cosa include davvero pi-config

Nel repository principale ci sono:

• ask-user-question: richiesta strutturata con popup TUI e serializzazione dell'interazione;
• bash-guard: conferma/blocco euristico di comandi shell pericolosi;
• browser: automazione Playwright su Chromium headless, disattivata inizialmente;
• custom-header: header TUI personalizzato;
• prompt-snippets: regole brevi attivabili sul singolo messaggio;
• web-fetch e web-search;
• skill per analisi sessioni, PDF, debug web e trascrizione YouTube.

L'elenco e i prerequisiti sono nel README ufficiale. Le capacità più ambiziose sono in repository distinti:

• pi-interactive-subagents, subagent interattivi in tmux;
• pi-observational-memory, memoria osservazionale per sessione;
• pi-dictate, STT con Deepgram;
• learn, ambiente didattico con quiz, log e agent di ricerca/visualizzazione.

Questi componenti non formano automaticamente una singola installazione testata, aggiornata e versionata insieme. Considerarli una “suite” è un'inferenza utile per il confronto, non una promessa del maintainer.

Dove OMP è realmente superiore

1. È coerente come prodotto. Installazione, configurazione YAML, schema, tool, sessioni e aggiornamenti fanno parte dello stesso rilascio (settings).
2. Il routing dei modelli è molto più sofisticato. Non si sceglie soltanto un modello: si possono assegnare costi/capacità differenti a pianificazione, task, vision, commit, advisor e attività leggere.
3. L'intelligence sul codice è integrata. LSP, DAP, editing AST, evaluator persistenti e review non richiedono di costruire un proprio stack di estensioni.
4. Subagent e memoria sono parti del sistema, non componenti companion da sincronizzare a mano.
5. Ha più opzioni di interoperabilità: MCP, marketplace e discovery di configurazioni da altri strumenti.

Questa superiorità è soprattutto di copertura e integrazione, non una prova automatica di qualità superiore per ogni singola funzione. Le quantità dichiarate nel README di OMP sono affermazioni del progetto, non benchmark indipendenti.

Dove Pi + la configurazione Amos è migliore

1. È più facile capire il perimetro. Ogni estensione è piccola, selezionabile e sostituibile. Si può usare prompt-snippets senza accettare browser, memoria o subagent.
2. Ha meno lock-in architetturale. Le skill Markdown e molte estensioni TypeScript restano vicine all'ecosistema Pi, anche se oggi gli import verso il vecchio package scope richiedono attenzione.
3. Alcune idee sono più eleganti che “integrate”. Gli snippet effimeri per messaggio, gli agent visibili nei pannelli tmux e la memoria in file Markdown per sessione sono facili da osservare e modificare.
4. Favorisce l'apprendimento del sistema. È una buona base per chi vuole costruirsi il proprio harness anziché adottare una piattaforma già opinionata.

Il prezzo è tempo operativo: installazione, dipendenze, compatibilità, aggiornamenti e test ricadono sull'utente.

Sicurezza: la conclusione scomoda

Né Pi + pi-config né OMP forniscono, da soli, un sandbox di sicurezza.

• In Pi, bash-guard è un buon guardrail UX, ma non vede tutte le scritture e non contiene il processo. Le estensioni Pi hanno accesso al sistema con i privilegi dell'utente; la documentazione raccomanda esplicitamente container o microVM (Pi security).
• In OMP esistono più policy, deny list e modalità di approvazione. Tuttavia tools.approvalMode parte da yolo, i safety override bash non diventano prompt in quella modalità, un comando approvato conserva accesso ambientale e le estensioni girano nello stesso processo (approval mode, extension loading). Anche la protezione dei segreti è opt-in.

Se scegliessi OMP imposterei subito almeno:

1. tools.approvalMode: always-ask per un ambiente sensibile, oppure write come compromesso;
2. deny/prompt espliciti per evaluator, browser/computer e tool non necessari;
3. offuscamento segreti abilitato e configurato;
4. esecuzione in container, VM o microVM quando repository, credenziali o rete sono sensibili.

Con Pi farei la stessa cosa a livello OS e tratterei bash-guard come seconda cintura, non come sandbox.

Raccomandazione per profilo

Profilo	Scelta consigliata	Perché
Sviluppatore che vuole essere produttivo subito	Oh My Pi	Meno assemblaggio; LSP/DAP, modelli, agent e sessioni sono già integrati.
Power user multi-model / molti provider	Oh My Pi	Routing per ruolo, fallback e credenziali multiple sono capacità native.
Team che vuole una configurazione ripetibile	Oh My Pi, release fissata	Installer, Nix/mise, config e release versionate sono più riproducibili; fissare la versione riduce il churn.
Hacker di Pi che vuole costruire il proprio ambiente	Pi + componenti pi-config	Superficie ridotta, sorgenti leggibili, composizione libera.
Utente che vuole solo snippet, guard o browser	Pi + singole estensioni	Non serve adottare un fork molto più grande per tre capacità.
Chi apprezza subagent visibili e interattivi in tmux	Pi + pi-interactive-subagents	È una scelta UX specifica e ben distinta dall'Agent Hub.
Ambiente ad alta sicurezza	Nessuno dei due senza isolamento OS	I controlli applicativi non sostituiscono container/microVM; OMP va inoltre tolto da yolo.
Runtime Pi già integrato via RPC, come ThothII	Restare su Pi salvo progetto di migrazione dedicato	OMP offre RPC/ACP, ma package scope, caricamento estensioni, eventi e semantiche del fork richiedono test contrattuali: non è una sostituzione drop-in.

Nota specifica per ThothII

Per usare un agente nel terminale del repository, OMP può essere valutato senza cambiare l'architettura. Sostituire invece il processo Pi che ThothII avvia in modalità RPC è un'altra decisione. ThothII dipende dal contratto degli eventi RPC, dall'estensione gate, dal resume e dal comportamento di sessione. La guida di porting di OMP e la sua documentazione di caricamento estensioni mostrano divergenze sufficienti da richiedere almeno una suite di compatibilità end-to-end prima di considerarlo un sostituto.

Verdetto

Il migliore in assoluto, per me, è Oh My Pi — con una release fissata e una configurazione iniziale più restrittiva del default. Vince quasi tutte le categorie funzionali e riduce drasticamente il lavoro di integrazione.

Non lo sceglierei però “alla cieca”: yolo come default è un caveat serio, la superficie enorme rende probabile qualche regressione e il fork crea più dipendenza dalle proprie API. Per una workstation con codice e credenziali reali lo metterei dietro approvazioni esplicite e isolamento OS.

Pi + pi-config è la scelta migliore quando l'obiettivo è un ambiente personale minimale e intenzionale, non quando si cerca il maggior numero di funzioni. Installerei solo i componenti necessari, controllerei gli import dopo la migrazione da @mariozechner/* a @earendil-works/* e aggiungerei test prima di usarli in un flusso critico.