Faire tourner Pi Coding Agent avec un LLM local Bonsai dans WSL

/ Intelligence Artificielle / Par

Faire tourner Pi Coding Agent avec un LLM local Bonsai dans WSL

Je voulais utiliser un LLM local pour coder dans WSL, avec un vrai agent capable de lire les fichiers, lancer des commandes et travailler directement sur un projet.

J’ai d’abord testé Aider, mais pour mon besoin, Pi Coding Agent s’est révélé plus adapté grâce à son approche orientée outils.

Voici la configuration qui a fonctionné.

1. Mon setup

J’utilise :

  • WSL
  • un modèle local Bonsai 27B au format GGUF
  • llama.cpp comme serveur local (attention c’est un fork adapté à Bonsai)
  • Pi Coding Agent comme agent de code

Mon modèle :

/home/yvonh/Bonsai-demo/models/bonsai2-gguf/27B/Ternary-Bonsai-2-27B-PQ2_0.gguf

Mon binaire llama.cpp :

/home/yvonh/Bonsai-demo/bin/cuda/llama-server

2. Lancer Bonsai avec llama.cpp

Attention c’est le llma.cpp propre à Bonsai, ce n’est pas le llam.cpp que vous voyez habituellement.

La commande fonctionnelle est :

/home/yvonh/Bonsai-demo/bin/cuda/llama-server -m /home/yvonh/Bonsai-demo/models/bonsai2-gguf/27B/Ternary-Bonsai-2-27B-PQ2_0.gguf --ctx-size 32768 --port 8081

Le serveur expose ensuite une API compatible OpenAI sur :

http://localhost:8081/v1

Pour vérifier que le modèle est bien exposé :

curl http://localhost:8081/v1/models

3. Attention à la fenêtre de contexte

Au départ, le serveur tournait avec une fenêtre de contexte de :

16384 tokens

Pi envoyait une requête d’environ 17 852 tokens, ce qui provoquait l’erreur :

400 request exceeds the available context size

La solution a été d’augmenter le contexte de llama.cpp :

--ctx-size 32768

Il faut aussi déclarer la même taille côté Pi.

Par exemple dans :

~/.pi/agent/models.json

j’utilise notamment :

{
  "contextWindow": 32768,
  "maxTokens": 4096
}

Il est important de comprendre que modifier uniquement contextWindow dans Pi ne suffit pas.

La vraie limite est définie côté llama.cpp.

4. Installer Pi Coding Agent

Dans WSL :

npm install -g @mariozechner/pi-coding-agent

Puis :

pi --version

Et dans un projet :

cd ~/mon-projet
pi

5. Configurer Bonsai dans Pi

Pi peut utiliser un provider compatible OpenAI.

Le fichier se trouve ici :

~/.pi/agent/models.json

Exemple de configuration :

{
  "providers": {
    "bonsai": {
      "baseUrl": "http://localhost:8081/v1",
      "api": "openai-completions",
      "apiKey": "dummy",
      "models": [
        {
          "id": "/home/yvonh/Bonsai-demo/models/bonsai2-gguf/27B/Ternary-Bonsai-2-27B-PQ2_0.gguf",
          "name": "Bonsai 2 27B Local",
          "reasoning": false,
          "contextWindow": 32768,
          "maxTokens": 4096,
          "cost": {
            "input": 0,
            "output": 0,
            "cacheRead": 0,
            "cacheWrite": 0
          }
        }
      ]
    }
  }
}

Ensuite, dans Pi :

/model

et il suffit de sélectionner :

Bonsai 2 27B Local

6. Pourquoi Pi plutôt qu’Aider dans mon cas

Aider fonctionne très bien pour modifier du code, mais son fonctionnement repose surtout sur un protocole d’édition.

Pi correspond davantage à ce que je cherchais : un agent capable d’utiliser des outils.

Il peut notamment :

  • lire les fichiers
  • inspecter le projet
  • lancer des commandes shell
  • utiliser git
  • lancer des tests
  • modifier des fichiers
  • observer le résultat
  • continuer son travail

Le fonctionnement ressemble davantage à :

LLM
 ↓
appel d’un outil
 ↓
résultat
 ↓
nouvelle décision
 ↓
nouvel appel d’outil

C’est beaucoup plus proche de l’expérience Codex CLI ou Claude Code.

7. Le script que j’utilise

Pour éviter de retaper toute la commande llama.cpp, j’ai créé :

~/start-bonsai.sh

avec ce contenu :

#!/bin/bash

LLAMA_SERVER="/home/yvonh/Bonsai-demo/bin/cuda/llama-server"
MODEL="/home/yvonh/Bonsai-demo/models/bonsai2-gguf/27B/Ternary-Bonsai-2-27B-PQ2_0.gguf"

CTX_SIZE=32768

while [[ $# -gt 0 ]]; do
  case "$1" in
    --ctx)
      CTX_SIZE="$2"
      shift 2
      ;;
    *)
      echo "Option inconnue : $1"
      echo "Usage: $0 [--ctx taille]"
      exit 1
      ;;
  esac
done

"$LLAMA_SERVER" \
  -m "$MODEL" \
  --ctx-size "$CTX_SIZE" \
  --port 8081

Puis :

chmod +x ~/start-bonsai.sh

Je peux maintenant lancer Bonsai simplement :

~/start-bonsai.sh

avec 32768 tokens par défaut.

Ou choisir une autre taille :

~/start-bonsai.sh --ctx 65536

8. Workflow final

Mon workflow est maintenant très simple.

Premier terminal :

~/start-bonsai.sh --ctx 32768

Deuxième terminal :

cd ~/mon-projet
pi

Puis je sélectionne Bonsai dans :

/model

J’obtiens ainsi un agent de code local fonctionnant avec un modèle GGUF, llama.cpp et Pi directement dans WSL.

Conclusion

La combinaison qui fonctionne bien pour moi est :

Bonsai 27B GGUF
        ↓
    llama.cpp
        ↓
API OpenAI compatible
        ↓
Pi Coding Agent
        ↓
fichiers / shell / git / tests

Le point le plus important à retenir concerne la fenêtre de contexte.

Si Pi annonce 32k mais que llama.cpp tourne encore avec 16k, les requêtes échoueront dès que le contexte devient trop gros.

Il faut donc garder les deux configurations cohérentes :

llama.cpp : --ctx-size 32768
Pi        : contextWindow 32768
Pi        : maxTokens 4096

Avec cette configuration, j’ai pu utiliser mon Bonsai local comme véritable agent de développement dans WSL.

Le harness de Pi minimaliste

En vert ce qui vient avec Pi par défaut, j’ai demandé une liste d’extensions à installer pour arriver au niveau de Codex ou Claude Code.

 Copy-paste bootstrap (install order)

 Essentials — to feel like CC:

 ```bash
   pi install npm:@gotgenes/pi-permission-system   # permission gates
   pi install npm:pi-subagents                     # sub-agent delegation / multi-agent
   pi install npm:pi-mcp-extension                 # MCP (connect any MCP server)
   pi install npm:pi-web-access                    # web search / fetch / repo clone
   pi install npm:pi-memory                        # cross-session memory
 ```

 Plan mode (pick one):

 ```bash
   pi install npm:pi-plan-task                     # configurable, approved, resumable
   # OR pi install npm:@plannotator/pi-extension   # interactive plan review w/ annotations
 ```

 Make it look/feel like CC (UI polish):

 ```bash
   pi install npm:@zigai/pi-footer                 # compact status line
   pi install npm:pi-claude-code-tui               # polished CC-style startup header
   pi install npm:@zigai/pi-response-renderer      # more compact responses
 ```

 Then browse the whole ecosystem in-session with /pi-resource-center (if that resolves for
 you) or the npm search (https://www.npmjs.com/search?q=keywords%3Api-package) / Discord.

 Config wiring

 ```bash
   # System prompt (replace or append) — project + global
   echo "Your project conventions here." > .pi/SYSTEM.md
   echo "Global defaults" > ~/.pi/agent/SYSTEM.md
   # APPEND_SYSTEM.md appends instead of replacing.

   # Context/instructions (auto-loaded from cwd + parents + global)
   # project:  ./AGENTS.md        global:  ~/.pi/agent/AGENTS.md

   # Skills — same folder standard as CC, so existing skills usually drop in
   # project:  .pi/skills/        global:  ~/.pi/agent/skills/
   # also:     ~/.agents/skills/  (shared w/ other harnesses)

   # Settings: /settings, or edit
   # ~/.pi/agent/settings.json   (global)
   # .pi/settings.json           (project, overrides)
 ```

 You already have ~/.pi/agent/models.json set up with your local Bonsai provider, so no auth
 work needed.

 Two honest caveats for your setup

 1. Security — pi packages run with full system access and execute arbitrary code (the README
 says this explicitly). This is especially important for pi-permission-system, which is
 what's actually gating what your model can run. I'd review the source of anything you
 install before you do. I can pull a package's source and skim it for you first.
 2. Your model — you're currently on a local Bonsai 27B (16k context, no reasoning, no
 developer-role). The harness features all work fine with it, but the "smart" parts —
 plan-mode completion auditors, sub-agent orchestration, heavy compaction — shine with a
 bigger cloud model (Claude/OpenAI). If you plan to run those workflows, add an
 ANTHROPIC_API_KEY or OPENAI_API_KEY and /login so you can cycle models per-task.

 Want me to install the essentials now, and/or pull the source of pi-permission-system and
 pi-subagents and give you a quick security skim before you trust them with your shell?

A part l’orchestration d’agents, parce que j’ai un model LLM local moins puissant que Claude ou Codex, les plugins fonctionnent sur mon poste. On peut installer l’orchestration d’agent à condition d’jouter les API KEY de Claude et Codex (utiliser les LLM via API KEY sont plus cher que d’utiliser via son compte).