homelab-coding-agents
🏠⚡ J’ai 4 machines, 512 Mo de RAM sur les plus petites, et pourtant je fais tourner 5 coding agents différents en parallèle. Voici comment.
Le contexte
Depuis quelques mois je fais tourner un homelab de 4 nœuds sur mon réseau local (192.168.1.20/24) :
- 2x Raspberry Pi Zero 2 (edge, ressources très contraintes)
- 2x serveurs (un Optiplex et un Inspiron reconditionnés, rôle compute)
L’objectif : arrêter de dépendre d’un seul agent IA, d’un seul fournisseur de modèle, ou d’une seule machine. Un vrai mesh où chaque nœud a un rôle défini, où les harnesss de coding agents (Claude Code, Codex, OpenCode, Vibe) coexistent avec mon propre harness maison (Oh-My-PI, alias omp), et où les Pi Zero ne sont pas juste des porte-clés USB glorifiés.
Ce post en 4 parties :
- 1️⃣ Le schéma d’architecture
- 2️⃣ Comparatif technique des harnesss
- 3️⃣ Qui parle à l’extérieur, et comment
- 4️⃣ Le mesh entre les 4 machines
1️⃣ Architecture
RÉSEAU 192.168.1.0/24
┌───────────────────────────┐
│ │
│ [Pi Zero 2 #1] .21 │
│ role : edge │
│ harness : omp │
│ │
│ [Pi Zero 2 #2] .22 │
│ role : edge │
│ harness : omp │
│ │
│ [Optiplex] .23 │
│ role : compute │
│ harness : omp, │
│ Claude Code, Codex, │
│ OpenCode, Vibe │
│ │
│ [Inspiron] .24 │
│ role : compute │
│ harness : omp, │
│ Claude Code, Codex, │
│ OpenCode, Vibe │
│ │
└───────────────────────────┘
Les Pi Zero 2 ne font tourner qu’omp : c’est mon harness perso, taillé pour de l’ARM Cortex-A53 avec 512 Mo de RAM, sans prétention. Il gère les tâches edge : polling de capteurs, petits scripts, relais vers le reste du mesh. Les deux serveurs, eux, encaissent tout le reste : c’est là que je fais tourner les gros harnesss commerciaux ou open source.
2️⃣ Comparatif des harnesss
Petite précision importante avant le tableau : Claude Code, Codex CLI, OpenCode et Vibe ne font (quasiment) jamais tourner de modèle en local. Ce sont des clients CLI qui appellent une API distante ; le “footprint” qui compte, c’est celui du runtime (Node.js ou Python) et de l’orchestration, pas des poids du modèle.
| Harness | Modèle(s) | Footprint RAM/CPU | Exécution | Tool-use | Extensibilité |
|---|---|---|---|---|---|
| omp | agnostique, léger, taillé maison | Très faible — conçu pour ARM 512 Mo | Local (calls API légers) | Basique, ciblé edge | Scripts custom |
| Claude Code | Claude (Sonnet/Opus) via API Anthropic | Runtime Node.js, modéré | Hybride (agent local, inférence distante) | Natif, riche (bash, fichiers, web) | MCP, hooks, plugins, subagents |
| Codex CLI | GPT (via ChatGPT ou API OpenAI) | Runtime Python/Node, modéré, sandbox OS-level | Hybride + cloud tasks async | Natif, sandbox à 3 niveaux | MCP natif, hooks, subagents |
| OpenCode | 75+ providers (Anthropic, OpenAI, Google, local via Ollama…) | Runtime léger, TUI terminal | Hybride, provider-agnostique | Natif + LSP (diagnostics compilateur) | MCP, plugins |
| Vibe (Mistral) | Modèles Mistral (Devstral…) | Runtime Python, léger à modéré | Hybride | Natif (bash, fichiers, grep) | MCP (stdio/http), hooks, subagents |
Sur le papier, tous ces harnesss pourraient tourner sur un Pi Zero 2 puisque l’inférence est déportée. En pratique, le confort de dev (TUI riche, plusieurs sessions parallèles, LSP) demande plus de RAM/CPU que ce que 512 Mo permettent sereinement — d’où le choix de les réserver aux deux serveurs, et de garder omp sur les Pi comme client ultra-léger.
3️⃣ Communication avec l’extérieur
| Harness | Capacité native | Alternative si limitée |
|---|---|---|
| omp | Appels API HTTP simples | MCP server maison si besoin d’outils riches |
| Claude Code | MCP, web search, bash, filesystem | — (déjà natif) |
| Codex CLI | MCP natif, web search mid-task, cloud tasks | — (déjà natif) |
| OpenCode | MCP local/remote, LSP | Proxy HTTP si le serveur MCP distant est instable |
| Vibe | MCP (stdio/http/streamable-http), Connectors Mistral | Tunnel SSH si le serveur MCP est derrière un NAT |
Le point commun : tous parlent MCP nativement aujourd’hui, ce qui simplifie énormément le mesh — un même serveur MCP (accès filesystem partagé, base de données, ou passerelle vers omp) peut être branché indifféremment sur Claude Code, Codex, OpenCode ou Vibe sans réécrire de glue code.
4️⃣ Le mesh entre les 4 machines
┌────────────────┐
│ Optiplex .23 │
│ orchestrateur │
│ Claude Code │
└───────┬────────┘
MCP over TCP / SSH
┌──────────┼──────────┐
│ │ │
┌─────┴────┐ ┌───┴────┐ ┌───┴────┐
│Inspiron │ │Pi Zero1│ │Pi Zero2│
│ .24 │ │ .21 │ │ .22 │
│ worker │ │ edge │ │ edge │
│Codex/Vibe│ │ omp │ │ omp │
└──────────┘ └────────┘ └────────┘
Stratégie concrète :
- Optiplex joue l’orchestrateur : Claude Code y tourne avec un serveur MCP maison exposé sur le réseau local, qui relaie les commandes vers les 3 autres nœuds.
- Inspiron est le worker de compute : Codex CLI ou Vibe y exécutent les tâches lourdes (build, tests, génération de code) déléguées par l’orchestrateur, via SSH ou MCP over TCP selon le besoin de statefulness.
- Les 2 Pi Zero 2 ne reçoivent que des tâches courtes et atomiques via
omp— lecture de capteur, exécution d’un script, remontée d’un statut. Ils ne participent jamais à l’inférence ni à l’orchestration : ça évite qu’ils deviennent le goulot d’étranglement du mesh.
Le protocole : MCP over TCP pour tout ce qui est appel d’outil structuré, SSH pour les commandes ad hoc et le déploiement, HTTP simple pour les webhooks entre omp et le reste.
Le bénéfice concret pour un DevOps IA : un seul cerveau (l’orchestrateur) peut répartir intelligemment le travail entre 4 machines hétérogènes, sans dépendre d’un seul fournisseur de modèle ni d’un seul harness — et sans cramer les Pi Zero qui restent sur ce qu’ils savent faire.
Vous avez un setup multi-nœuds similaire ? Quel protocole vous utilisez pour le mesh entre vos agents ? Curieux de voir vos retours en commentaire 👇
#DevOps #AI #LLM #Homelab #CodingAgent