Open source · MIT · Tough-Respawn/loom

Loom

Un agent tool-use local, offline, monté au-dessus d'un modèle open-weight

Un modèle open-source qui agit sur la machine avec des outils : localiser, lire, modifier, exécuter, vérifier. Le pari : rester productif internet coupé et démontrer le savoir-faire d'internaliser le harnais sur un modèle autre que Claude.

llama.cppPython 3.12 · uvFlask + Preact/htmMoE offload · CPU-MoEPlaywrightClient MCPComfyUI (image/vidéo)Skills & plugins compat. Claude Code

Ce que Loom fait (et pas)

Trois choix architecturaux assumés, chacun documenté par des expériences qui les ont validés ou falsifiés.

Boucle tool-use pure

Un seul chemin : le modèle décide, appelle un outil, on lui rend le résultat. Pas de rail de réflexion imposé, deux orchestrateurs déterministes essayés et supprimés. Quand une tâche mérite d'être structurée, c'est le modèle qui écrit le script d'orchestration et le lance via run_workflow.

Local & offline par défaut

llama.cpp + llama-swap, API OpenAI-compatible sur :8080. MoE 24B+ jouables sur petite VRAM par offload des experts en RAM. Trois familles servies par la même UI : texte local, API distantes, image et vidéo via ComfyUI. Rester productif internet coupé.

Frontière de confiance

Tout contenu externe (URL, PDF, sortie d'outil, réponse d'un serveur MCP) marqué DONNÉE, jamais instructions. Garde anti-SSRF qui traite aussi l'IPv4 embarquée en NAT64/DNS64 (RFC 6052), deny-list, mode permission ask/allow. Défense en profondeur, active même hors-ligne.

En quoi Loom diffère

Quatre alternatives connues, ce qu'elles font, ce que Loom fait à la place ou en plus.

Claude Code (Anthropic)

Agent premium, Claude-only, cloud requis.

Loom

Modèle-agnostique et 100 % offline. Compatible avec les mêmes skills et plugins Claude Code, sous licence MIT.

Aider / Continue

CLI de coding, git-natif, verticale unique.

Loom

Agent générique avec web-UI, 28 outils multi-domaine (localisation, lecture, exécution, vérification), outils MCP tiers, workflows Python.

LangChain / LangGraph

Framework Python d'orchestration, découpe imposée par le graph.

Loom

Boucle tool-use pure : le modèle décide la séquence. Deux orchestrateurs déterministes essayés puis retirés (×12 le coût pour 0 résultat).

Ollama + Open WebUI

Chat local simple, un modèle qui parle.

Loom

Agent qui agit sur ta machine : écriture disque, shell, navigateur headless, sous mode permission ask/allow avec deny-list.

Le pattern qui unifie ces différences : Loom exécute le harnais d'un agent premium (Claude Code-like) au-dessus d'un modèle open-weight, sur ta machine, offline.

Le banc empirique

On mesure sur du vrai. Configuration exacte, modèles testés, résultats reproductibles.

Hardware

GPU
NVIDIA RTX 2060, 6 Go VRAM
RAM
64 Go (offload experts MoE)
CPU
6 cœurs physiques / 12 threads
OS
Windows 11 · 100 % offline
Runtime
llama.cpp + llama-swap

L'offload des experts MoE en RAM rend les modèles 24B+ jouables sur 6 Go de VRAM. Le goulot n'est plus la RAM (~25 Go utilisés / 64) ; c'est la bande passante mémoire et la VRAM disponible pour l'attention.

Modèles servis

  • ornith

    ornith-1.0-35b-heretic-q8_0 · local, GGUF Q8, flash-attn, NVMe interne

    35B local principal · ~14 t/s decode

  • agents-a1

    agents-a1-35b-abliterated-q8_0 · local, GGUF Q8, NVMe interne

    35B local complémentaire · ~14 t/s decode

  • qwen3.6-35b-a3b

    qwen3.6-35b-a3b-abliterated · local, MoE 3B actifs, SSD externe

    MoE local, décode rapide · non mesuré sur ce banc

  • gemma4-e4b

    gemma4-e4b-heretic · local, petit modèle, SSD externe

    tâches courtes, repli léger · non mesuré sur ce banc

  • glm-zai

    API OpenAI-compat (Z.ai) · distant, pas de contrainte VRAM

    modèle par défaut en config · débit provider

  • glm-flash

    API OpenAI-compat (Z.ai) · distant, tier gratuit

    sous-agents (dispatch_agent) · débit provider

  • deepseekv4

    API OpenAI-compat · distant

    frontier distant de comparaison · débit provider

  • kimi-k3

    API OpenAI-compat · distant

    frontier distant de comparaison · débit provider

Résultat clé : le harnais peut desservir un petit modèle

Même tâche (créer un démineur HTML jouable), même modèle. Seule différence : le harness.

Harness dirigiste

Lignes de log
5 643
Appels d'outils
≈ 356
Résultat
boucle infinie

Harness léger (tool-use pur)

Lignes de log
699
Appels d'outils
≈ 30
Résultat
démineur fonctionnel

≈ 12× le coût pour zéro résultat. La leçon : découper une tâche pour un petit modèle suppose qu'il sait décomposer et exécuter chaque atome. Un modèle fiable à 99 %/étape reste à 92 % sur 8 étapes ; à 85 %, il tombe à 27 %. Découper aide au-dessus du seuil, empire en-dessous.

Deux orchestrateurs déterministes essayés et supprimés (juin 2026). La boucle tool-use pure, où le modèle décide, s'est validée sur mesure. On fiabilise par le prompt, la qualité des erreurs et les outils. Jamais par un rail rigide.

Les outils

28 outils natifs, groupés par usage, plus ceux qu'apportent les serveurs MCP tiers. Le harness ne pilote pas, il outille et vérifie.

Localiser & lire

find_files, search_text, list_dir, read_file (texte + PDF/XLSX/DOCX), read_image

Modifier & exécuter

write_file, append_file, edit_file, format_code (ruff), run_shell, monitor (processus surveillé en asynchrone)

Vérifier le rendu

check_page (Playwright headless, prouve qu'une page est jouable), serve_and_check (démarre un serveur, charge la page, tue l'arbre de process)

Planifier & déléguer

manage_todos, dispatch_agent (sous-agent isolé), run_workflow (script Python qui orchestre N sous-agents), use_skill

Mémoriser & noter

remember, recall (SQLite FTS5), write_note, read_note, calculate, current_date

Web & extensions

web_search, fetch_url, list_plugins, add_marketplace, install_plugin, tool_search (charge à la demande les outils différés)

Neuf outils de cœur restent toujours dans le préfixe du prompt (localiser, lire, écrire, éditer, shell, todos). La longue traîne est différée : le modèle appelle tool_search pour charger le schéma d'un outil quand il en a besoin. Les outils MCP sont toujours différés, un seul serveur pouvant en annoncer des dizaines.

Ce qui étend le modèle

Loom n'est plus seulement une boucle et des outils. Trois mécanismes d'extension, tous hors-ligne une fois installés.

Client MCP stdio

Loom se branche sur des serveurs MCP tiers et fusionne leurs outils dans le même registre que les siens, avec le même marquage de contenu non fiable. Dépendance optionnelle : aucun coût au runtime tant qu'aucun serveur n'est configuré.

Store de plugins Claude Code

Marketplaces, installation et cache, dans un store propre à Loom. On installe un plugin Claude Code et c'est un modèle open-weight local qui s'en sert, sans réseau. Les skills sont aussi des fichiers markdown locaux, déclenchés par le modèle via use_skill, jamais activés à la main.

Image et vidéo via ComfyUI

Troisième famille de modèles, après le texte local en llama-swap et les API distantes. Un dossier par modèle avec son graphe ComfyUI au format API ; Loom démarre le moteur, soumet le workflow et range le média dans la session. Génération et édition d'image, texte-vers-vidéo et image-vers-vidéo.

Le store de plugins est indépendant de ~/.claude : Loom héberge le sien, on y installe un plugin Claude Code et un modèle local s'en sert hors-ligne. Tranche actuelle : seuls les skills des plugins sont consommés, les agents et hooks ne sont pas câblés.

Mémoire, contexte et persistance

Un agent utile ne vit pas seulement dans une fenêtre de tokens. Quatre couches qui gardent l'état, dans le tour et entre les tours.

Sessions par projet

Un fil persistant par workspace, historique + outils actifs sauvegardés, CRUD depuis l'UI. Le titre est inféré automatiquement par le modèle après le premier tour, plus de "Nouvelle session".

Compaction multi-étage

Trois étages successifs : microcompact des vieux tours, résumé télégraphique via une primitive dédiée (fail-soft si le modèle est injoignable), force-fit déterministe qui ne s'arrête jamais pour saturation. Bouton "compacter" manuel instantané.

KV cache slot save/restore

Sauvegarde/restauration du slot KV autour des sous-agents et à la fin de chaque tour (routes llama-swap). Reprise de conversation = 10-11 tokens préfillés au lieu de ~930. Bascule d'onglet quasi instantanée.

Mémoire long-terme (SQLite FTS5)

Provider SQLite FTS5 pour la mémoire persistante (outils recall / remember). Reflect post-tour pour la capitalisation continue. Fichiers d'identité SOUL / USER / MEMORY qui survivent aux sessions et aux redémarrages.

Ces quatre couches sont dans le code (loom/agent/context.py, loom/agent/session.py, loom/agent/reflect.py, loom/memory/local.py), pas dans un roadmap.

Contributions upstream à llama.cpp

Utiliser un projet open-source sérieusement, c'est finir par y contribuer. Une PR ouverte sur ggml-org/llama.cpp et un second correctif en file d'attente, chacun né d'un problème vécu sur le banc.

PR #26004 · première contribution

en revue upstream

« server : preserve context checkpoints across slot save/restore ». Correction ciblée sur llama-server issue du travail quotidien sur Loom, ouverte le 22 juillet 2026 et toujours en revue. C'est ma première PR sur ggml-org/llama.cpp. La règle du repo est une seule PR ouverte à la fois pour un nouveau contributeur, donc la PR n°2 attend son merge.

Correctif n°2, en attente · Vulkan iGPU/UMA cached readback

branche fix/vulkan-uma-cached-readback

Six lignes. Cause racine : sur les iGPU/UMA, ggml_vk_buffer_read_2d lit une mémoire host-visible WRITE-COMBINED non-cachée : 19 Mo/s au lieu de plusieurs Go/s. Le fix passe par le chemin copie-device + staging. Bénéficie à tous les utilisateurs de Vulkan sur mémoire unifiée (iGPU Intel, AMD APU, Strix Halo).

Impact mesuré (PR n°2)

Checkpoint (iGPU/UMA)

3,3 s25 ms

×130

Append token (ornith)

7,4 s0,67 s

×11

Décode (t/s)

8,39,2

+11 %

Chiffres relevés sur banc, avec les mêmes prompts et arguments avant/après le patch, pas des projections. Notre laptop bascule sur la build maison en attendant le merge upstream.

Open source · MIT

Publié sous licence MIT sur Tough-Respawn/loom. Cloner, forker, adapter, au même titre que nos autres projets open source (legal, accounting, strategy, defensive-prompt-injection).

Cohérent avec la thèse : notre pratique open-weight se démontre en ouvrant aussi le code du harnais. Loom est un banc, mais un banc dont chacun peut inspecter, critiquer et rejouer les choix.

Ce qu'on ne promet pas, ni support, ni roadmap publique. C'est un dépôt d'ingénierie ; on répondra aux issues techniques quand elles sont documentées et reproductibles.

Un agent local, pour de vrai ?

Si la souveraineté du code, la résilience hors-ligne ou une alternative aux modèles frontier fait partie de votre équation, on peut en discuter concrètement.

Ou consulter notre pratique Open Weights.