@alucard_24/pi-compaction-model0.1.0

@alucard24/pi-compaction-model

Estensione per pi che permette di usare un modello diverso da quello della sessione per la compattazione del contesto (auto-compaction, /compact e recovery da overflow), con un livello di thinking configurabile che rispetta i livelli supportati dal modello scelto.

La scelta è globale e persistente: vale per tutti i progetti e sopravvive a riavvii, /reload e nuove sessioni.

Installazione

Da npm:

pi install npm:@alucard_24/pi-compaction-model

Da GitHub:

pi install git:github.com/Alucard24/pi-compaction-model

Oppure da percorso locale:

pi install /percorso/a/pi.compact.model

Il package viene registrato in ~/.pi/agent/settings.json. Dopo l'installazione ricaricare con /reload o riavviare pi.

Comandi

Comando	Effetto
/compaction-model	Picker interattivo: modello (con filtro di ricerca e descrizioni) + livello di thinking
/compaction-model help	Spiega tutti i comandi (alias: /compaction-model-help)
/compaction-model status	Mostra modello, livello effettivo, livelli supportati, stato account e percorso del file di config
/compaction-model set <provider/modelId> [thinking]	Configura direttamente modello e (opzionale) thinking
/compaction-model thinking <level>	Cambia solo il thinking del modello già configurato
/compaction-model off	Torna al comportamento di default: modello della sessione attiva

Valori di thinking validi: off, minimal, low, medium, high, xhigh, max. Se il modello non supporta il livello richiesto, il comando rifiuta il valore mostrando i livelli supportati.

Account di connessione

Il picker e i comandi mostrano solo modelli di provider con un account connesso in pi (API key o OAuth): la lista rispetta i modelli configurati in pi (enabledModels / --models), filtrandoli per hasConfiguredAuth. Se un provider non è connesso, /compaction-model set e thinking lo rifiutano con un messaggio che invita a usare /login o a configurare l'API key, e /compaction-model status segnala Account: <provider> NOT connected.

File di configurazione

~/.pi/agent/compaction-model.json:

{
  "provider": "openrouter",
  "model": "anthropic/claude-haiku-4.5",
  "thinkingLevel": "low"
}

• thinkingLevel omesso (o file assente) → viene usato il livello di thinking della sessione, clampato ai livelli supportati dal modello di compattazione (stesso comportamento di pi).
• model può contenere / (es. openrouter/anthropic/claude-haiku-4.5): si divide solo sul primo /.
• File assente → nessuna configurazione, si usa il modello della sessione (default).

Come funziona

1. L'estensione intercetta l'evento session_before_compact (prima di qualsiasi compattazione) e rilegge il file di config da disco, così le modifiche manuali valgono dalla compattazione successiva senza /reload.
2. Se non c'è configurazione, non fa nulla: pi usa il comportamento built-in.
3. Se c'è configurazione, risolve il modello dal registry, calcola il thinking level effettivo con clampThinkingLevel di pi e delega a compact() della stessa versione di pi, così formato della summary, gestione split-turn, previousSummary e tracking dei file restano identici al default.
4. La chiamata passa da ctx.modelRegistry.streamSimple, quindi auth (API key/OAuth), override di baseUrl e provider registrati da altre estensioni funzionano come nel path built-in.
5. Viene rispettata anche la policy di retry di pi (retry in settings.json globale e di progetto, se il progetto è trusted).
6. Se il modello configurato non esiste più, non ha auth, o la summarization fallisce, l'estensione avvisa e lascia che pi esegua la compattazione di default con il modello attivo.

Il modello di compattazione è visibile nel footer come cmp <modello>:<livello>.

Limiti noti

• La branch summarization (/tree → "Summarize branch?") continua a usare il modello attivo; l'estensione copre solo la compattazione.
• La configurazione è solo globale; non esiste un override per progetto.

Licenza

MIT — vedi LICENSE.

Sviluppo

Test unitari (solo helper puri, nessuna dipendenza da pi):

npm test

Verifiche di integrazione (usano il loader reale di pi con un registry finto, nessuna chiamata di rete):

# una tantum: link dei pacchetti pi per la risoluzione dei moduli
mkdir -p node_modules/@earendil-works
PKG="$(dirname "$(readlink -f "$(command -v pi)")")/../.."
ln -sfn "$PKG" node_modules/@earendil-works/pi-coding-agent
ln -sfn "$PKG/node_modules/@earendil-works/pi-ai" node_modules/@earendil-works/pi-ai
ln -sfn "$PKG/node_modules/@earendil-works/pi-tui" node_modules/@earendil-works/pi-tui
ln -sfn "$PKG/node_modules/@earendil-works/pi-agent-core" node_modules/@earendil-works/pi-agent-core

node scripts/check-extension.mjs   # carica l'estensione col loader di pi
node scripts/check-handler.mjs     # verifica modello/thinking/fallback del handler

End-to-end reale (costo: una chiamata assistant banale + una summarization minima):

npm run test:e2e
# oppure con modelli espliciti:
node scripts/check-rpc-compaction.mjs --active deepseek/deepseek-flash --compaction deepseek/deepseek-v4-pro --thinking low

Gli script di integrazione sono anche disponibili come npm run test:integration (check-extension + check-handler).

check-rpc-compaction.mjs avvia pi in --mode rpc nel percorso del progetto, configura temporaneamente ~/.pi/agent/compaction-model.json (provider/modello diversi da quello attivo, es. attivo deepseek/deepseek-flash, compattazione deepseek/deepseek-v4-pro), esegue una compattazione manuale reale e verifica che la entry salvata abbia fromHook: true e usage. Il file di config temporaneo viene rimosso a fine test (il test si rifiuta di partire se il file esiste già).