Un plug-in (tunaLlama) qui délègue la génération de code lourde de Claude Code / Codex CLI à un LLM local

C’est un outil de délégation créé pour ceux qui voient vite fondre leur quota d’utilisation forfaitaire avec Claude Code ou Codex CLI en vibe coding.

https://github.com/hang-in/tunaLlama

Quand on code avec Claude Code, ce sont les étapes à sortie longue (génération de code, revue de fichiers, refactorisation) qui consomment le plus de tokens. Or ces étapes sont généralement déterministes et les écarts de qualité entre modèles y sont faibles. À l’inverse, la décomposition (exigences → liste de tâches) et la validation (vérifier si le résultat retourné satisfait les exigences) impliquent des entrées/sorties courtes, mais avec de fortes différences de qualité entre modèles.

tunaLlama est un backend + plug-in qui fige exactement cette asymétrie dans le flux de code.

RôleModèleResponsabilitéArchitectClaude / Codex (forfait)Décomposition / spécification / validation / intégrationDeveloperLLM local (Ollama / Cloud / LM Studio)Génération de code / auto-revue / auto-correctionReviewerMême session que l’ArchitectVerdict final

Seules les étapes lourdes en tokens basculent en local, tandis que les étapes courtes de décomposition et de validation restent dans Claude / Codex.

Claude Code et Codex CLI peuvent tous deux utiliser des outils externes via un système de plug-ins.
Une fois installé, l’agent l’appelle de lui-même lorsqu’il juge cela nécessaire pendant le travail.
L’utilisateur n’a donc pas besoin de dire à chaque fois « utilise cet outil ». tunaLlama est un type de plug-in de ce genre, qui expose 13 outils via un serveur MCP (Model Context Protocol).
Un seul dépôt fait fonctionner à la fois Claude Code et Codex CLI.
(le fichier claude-plugin/marketplace.json est reconnu par les deux clients.)

Quand l’utilisateur demande une tâche (coréen / anglais)

1. L’Architect décompose la tâche — si c’est court, tuna_dev_review, sinon rédaction d’un document spec puis tuna_dev_review_from_spec
2. Le backend répète la boucle generate → review → fix (bounded delegation — condition d’arrêt : review pass ou max iter)
   Tous les appels sont enregistrés dans SQLite et indexés avec l’analyseur morphologique coréen Kiwi
3. L’Architect valide le résultat puis le renvoie à l’utilisateur

Comparé à l’exécution d’un LLM local mid-size seul, le fait que l’Architect nettoie et transmette le contexte apporte un gain de +0.58 à +0.64 (validation sur 3 modèles, Phase 7-2). Autrement dit, avec le même LLM local, le fait de bien organiser le contexte avant transmission améliore significativement le résultat.
Cela dit, cette mesure repose sur des seeds synthétiques. Elle a été effectuée sur un jeu de test préparé à l’avance à partir de scénarios de tâches fréquents en conditions réelles, et rien ne garantit qu’on obtienne exactement les mêmes résultats dans les workflows utilisateurs. Depuis la v0.5.7+, 4 métriques d’organic dogfooding (standalone_toy_rate / convention_adherence_rate / ast_excess_score / syntactically_valid) sont automatiquement chargées dans ~/.tunallama/metrics.db, et la reproductibilité côté utilisateurs externes continue d’être collectée, y compris sur les baselines cumulées.

Concernant l’économie de quota, comme les formules de calcul des limites Anthropic / OpenAI ne sont pas publiques, il n’y a pas de résultat quantifié du type « X % économisé ». En pratique : « c’est mieux que de l’utiliser tel quel ».

Prise en charge du coréen

L’intégration de l’analyseur morphologique Kiwi permet l’indexation de recherche en coréen. Pour une entrée sans espaces comme « imeil geomjeung », une recherche sur « imeil » peut quand même correspondre. Cette structure compense les limites du tokenizer unicode61 de FTS5, qui découpe le coréen uniquement en syllabes / jamo. En revanche, les néologismes et termes spécialisés que Kiwi ne traite pas bien peuvent affecter la qualité de recherche.

Installation en 5 minutes

Il suffit d’envoyer une ligne dans la session :

"Installe-le en suivant INSTALL.md de https://github.com/hang-in/tunaLlama";

L’agent installe alors les dépendances, configure .env, enregistre le plug-in et effectue la validation étape par étape de façon autonome.
Si vous préférez une installation manuelle, consultez le README.

Matrice de fonctionnement dans les deux environnements

Claude Code et Codex CLI fonctionnent avec le même dépôt, mais certaines fonctionnalités n’ont été validées que d’un seul côté (mesure réelle v0.5.6, Claude Code 2.1.138 + Codex CLI 0.128.0) :

ÉlémentClaude CodeCodex CLIAppel des 13 outils MCP✓✓
Partage de la DB (~/.tunallama/memory.db)✓✓
Partage de state.md✓✓
Appel explicite de tuna_load_memory / tuna_recall✓✓
Agents auto-discovery✓
SessionStart hook + state.md auto-prepend✓
(v0.5.5+)✗MCP resource auto-attach✗✗
Dans Claude Code, state.md auto-prepend fonctionne automatiquement,
alors que dans Codex CLI il est recommandé que l’utilisateur appelle explicitement tuna_load_memory au premier tour ou récupère directement la documentation.
L’appel des 13 outils MCP fonctionne correctement des deux côtés, donc la délégation elle-même est possible au niveau outil.

Limites

L’économie de quota repose sur des données ressenties (mentionnées plus haut)
Le coût en system prompt des outils MCP est un trade-off assumé — la description + le schéma des 13 outils ajoutent environ 1.6k tokens au system prompt de chaque conversation. Ce n’est pas un accidental context bloat, mais un coût d’affordance conçu pour permettre à l’Architect de choisir l’outil de délégation approprié

Un environnement de LLM local (Ollama, etc. — Ollama cloud fonctionne aussi) est indispensable — sinon ça ne marche pas
Les mesures de recherche reposent sur des seeds synthétiques (mentionné plus haut)
Certaines fonctionnalités de Codex CLI ne fonctionnent pas (voir matrice ci-dessus)
La qualité de recherche peut être affectée par les néologismes / termes spécialisés coréens

Pourquoi pas des seeds de prompt / AGENTS.md

L’objectif n’est pas de résoudre les limites de contexte en faisant lire davantage de documents à l’agent.
À la place, les unités de travail sont découpées finement puis transmises via des outils MCP à un LLM local / à faible coût, tandis que le modèle Architect de niveau supérieur se concentre sur une spec courte, les résultats de review et le jugement final sur le diff.
Avec le temps, des règles d’exploitation fondées sur des documents peuvent produire des problèmes de stale state, de drift et de lost-in-the-middle.
tunaLlama évite cela en enregistrant les appels de délégation dans SQLite et en ajoutant une couche d’exécution capable de rechercher / rappeler ces informations au besoin.

Pour qui cela peut être utile

Utilisateurs de Claude Code Pro/Max au forfait (motivation : gestion des limites)
Utilisateurs de Codex CLI (forfait OpenAI / gestion du quota API)
Personnes disposant déjà d’un environnement Ollama local / Ollama Cloud / LM Studio
Personnes qui traitent des tâches en coréen (intégration Kiwi)

Tests / licence

Version v0.5.x utilisable pour le dogfooding. 507 tests unitaires / plug-in + 27 tests d’intégration / qualité de recherche, couverture de 90 %.
La commande de mesure est indiquée dans le README (pytest --no-cov -q -m "not search_quality and not integration").
La licence est MIT. Le README anglais (README.en.md) reste synchronisé. Retours / issues / PR bienvenus.
Les propositions de compatibilité avec d’autres CLI d’IA sont également bienvenues.