pi — retour d'expérience setup complet et audit, juillet 2026

Contexte de test

pi 0.82.1, paquet @earendil-works/pi-coding-agent, setup et audit complet menés en juillet 2026 sur ma machine principale (Mac, Neovim + herdr, config versionnée via chezmoi). Niveau de certitude à poser d’emblée : ce n’est pas mon agent quotidien principal — ça reste Claude Code. J’ai monté un setup pi complet (14 extensions, layering d’un modèle par preset, skills partagés), je l’ai audité ligne à ligne, mais je ne l’ai pas encore mis en charge sur des semaines de production. Cette review porte sur ce que le setup fait, vérifié contre le code réel — pas sur un ressenti de driver quotidien.

Ce qu’il fait réellement

pi connecte le terminal à 30+ providers avec un core délibérément nu. La phrase de son auteur résume tout : « pi is aggressively extensible so it doesn’t have to dictate your workflow ». Concrètement, il te donne sept outils (read, bash, edit, write, grep, find, ls), un TUI, des sessions JSONL qui se ramifient — et rien d’autre. Pas de serveurs MCP, pas de sub-agents, pas de plan mode, pas de popups de permission. Tout ce qui manque est un choix, pas un oubli : à toi de le construire en extension TypeScript.

Le point qui le rend intéressant pour un workflow agentique sérieux, c’est le multi-provider natif combiné à l’extensibilité. C’est ce qui rend le layering d’un modèle par preset non seulement possible, mais propre.

Ce qui fonctionne

Le multi-provider comme fondation, pas comme option. Ctrl+P cycle entre Claude, GPT, Gemini, les modèles opencode Go et le local, sans quitter la session. Sur ce socle, affecter un modèle à chaque rôle — le plus rapide sur le volume mécanique, le plus capable sur le plan — devient une ligne de config. C’est le model routing que Claude Code, mono-provider, ne peut structurellement pas offrir.

Nuance apprise à l’usage : appeler Claude depuis pi passe par claude -p, qui casse les prompts interactifs (pas d’AskUserQuestion) et aveugle toute supervision. Dans mon layering, les modèles open tiennent donc tous les presets, et le frontier — quand une tâche mérite le meilleur modèle avec tous les gates — part vers Claude Code directement, hors pi. Le multi-provider de pi est réel, mais il s’arrête là où l’interactivité d’un provider compte.

L’extensibilité qui absorbe l’existant. Mes quinze hooks bash de Claude Code — blocage rm -rf, secret-guard, pre-push-gate, review-gate — se regroupent en une seule extension typée. Au lieu de quinze scripts qui se maintiennent séparément, un fichier avec isToolCallEventType("bash", event) qui te donne event.input.command typé, l’accès à ctx.ui.confirm() et au session manager. Testable, importable, versionnable. Le code de ces garde-fous est public, avec leurs bancs de test.

Zéro duplication avec le reste du setup. pi lit les skills standard directement depuis ~/.claude/skills — 37 skills exposées, seulement leurs descriptions en contexte (progressive disclosure, ~1 600 tokens). La connaissance ne se dédouble pas entre outils : elle vit à un seul endroit.

Ce qui ne fonctionne pas

Aucune sandbox, et c’est structurel. pi tourne avec tes permissions utilisateur. Les seuls garde-fous sont les extensions que tu écris. Si tu ne codes pas le blocage des commandes destructrices, il n’y en a pas — et l’audit de mon propre setup l’a prouvé : ma regex de blocage rm -rf laissait passer les formes les plus courantes (rm -rf ~, rm -rf $HOME) parce qu’elle exigeait un caractère après le chemin. Le filet que tu crois avoir n’est réel que si tu le testes.

Le layering n’est pas une feature native. Les presets qui portent tout mon workflow sont une extension maison (preset.ts) — zéro occurrence de « presets » dans le code de pi lui-même. Ça marche, mais sans filet en amont : c’est du code à moi, avec ses bugs à moi.

Le mode non-interactif ment par omission. En pi -p ou --mode json, defaultProjectTrust vaut « ask » — donc aucun prompt de confiance ne s’affiche, et les ressources du projet sont silencieusement ignorées. Tu crois que pi lit ton AGENTS.md ; il ne le lit pas, et ne te le dit pas. Il faut --approve. Un piège que seul un audit révèle.

Une dette d’alias déjà programmée. Les extensions importent encore l’ancien scope @mariozechner/* ; le CHANGELOG 0.80.0 annonce le retrait futur de l’alias vers @earendil-works/*. Aujourd’hui ça passe grâce à un aliasing du loader — le jour où il saute, tout casse d’un coup.

Pour qui ?

pi est le bon choix si tu vis déjà dans le terminal et que l’anti-lock-in est une exigence, pas une préférence : BYOK, MIT, multi-provider, tout portable. C’est aussi le meilleur terrain que je connaisse pour faire du layering de modèles propre — un sujet que je détaille dans un article dédié à opencode Go.

Mais sois lucide sur le contrat : le minimalisme de pi te renvoie la charge. Pas de MCP, pas de sub-agents, pas de garde-fous par défaut — tu construis, ou tu t’en passes. Si tu veux du plug-and-play, Claude Code livre l’écosystème clé en main ; si tu veux le multi-provider sans tout réimplémenter toi-même, OpenCode est un cran moins nu. pi récompense ceux qui veulent tout contrôler, et punit ceux qui espéraient ne rien maintenir.