Plug-in zum Auslagern schwerer Codegenerierung von Claude Code / Codex CLI an ein lokales LLM (tunaLlama)

Dies ist ein Delegationstool für alle, bei denen beim Vibe Coding die Nutzungslimits der Flatrates von Claude Code oder Codex CLI schnell aufgebraucht sind.

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

Wenn man mit Claude Code programmiert, verbrauchen Schritte mit langen Ausgaben am meisten Tokens (Codegenerierung, Datei-Review, Refactoring). Diese Schritte sind jedoch meist deterministisch, und die Unterschiede in der Modellqualität sind gering. Umgekehrt gibt es bei Zerlegung (Anforderungen → Aufgabenliste) und Validierung (ob das zurückgegebene Ergebnis die Anforderungen erfüllt) zwar nur kurze Ein- und Ausgaben, aber große Unterschiede in der Modellqualität.

tunaLlama ist ein Backend + Plug-in, das genau diese Asymmetrie als Code-Flow festschreibt.

RollenmodellVerantwortungArchitectClaude / Codex (Flatrate)Zerlegung / Spezifikation / Validierung / IntegrationDeveloperlokales LLM (Ollama / Cloud / LM Studio)Codegenerierung / Selbst-Review / SelbstkorrekturReviewerdieselbe Session wie ArchitectEndgültige Beurteilung

Nur tokenlastige Schritte werden lokal ausgelagert, während die kurzen Zerlegungs- und Validierungsschritte bei Claude / Codex bleiben.

Claude Code und Codex CLI können beide per Plug-in externe Tools nutzen.
Einmal installiert, kann der Agent sie bei Bedarf während der Arbeit selbstständig aufrufen.
Der Nutzer muss also nicht jedes Mal sagen: „Bitte benutze dieses Tool.“ tunaLlama ist eine solche Plug-in-Art und stellt über einen MCP-Server (Model Context Protocol) 13 Tools bereit.
Ein einziges Repository funktioniert sowohl mit Claude Code als auch mit Codex CLI.
(claude-plugin/marketplace.json wird von beiden Clients erkannt.)

Wenn der Nutzer eine Aufgabe anfordert (Koreanisch / Englisch)

1. Der Architect zerlegt die Aufgabe – bei kurzen Aufgaben mit tuna_dev_review, bei langen durch Erstellen eines spec-Dokuments und danach tuna_dev_review_from_spec
2. Das Backend wiederholt die Schleife generate → review → fix (bounded delegation – Abbruchbedingung ist review pass oder max iter)
   Alle Aufrufe werden in SQLite protokolliert und mit dem koreanischen Morphologie-Analysator Kiwi indexiert
3. Der Architect validiert das Ergebnis und gibt es an den Nutzer zurück

Beim Vergleich zwischen allein laufenden mid-size lokalen LLMs und dem Fall, in dem der Architect den Kontext aufbereitet und weitergibt, ergab sich ein Plus von +0.58 bis +0.64 (Validierung mit 3 Modellen, Phase 7-2). Das bedeutet: Selbst mit demselben lokalen LLM wird das Ergebnis spürbar besser, wenn der Kontext gut aufbereitet übergeben wird.
Allerdings basiert diese Messung auf synthetischen Seeds. Sie wurde also auf einem vorab erstellten Testset mit häufigen realen Aufgabenszenarien gemessen; ob das in echten Nutzer-Workflows genauso ausfällt, ist eine andere Frage. Organische Dogfooding-Metriken werden ab v0.5.7+ in vier Varianten (standalone_toy_rate / convention_adherence_rate / ast_excess_score / syntactically_valid) automatisch in ~/.tunallama/metrics.db gespeichert, und Reproduzierbarkeit durch externe Nutzer wird weiterhin bis hin zu kumulierten Baselines gesammelt.

Zur Limitschonung gibt es keine quantitativen Ergebnisse wie „X % Ersparnis“, weil die Limit-Berechnungsformeln von Anthropic / OpenAI nicht öffentlich sind. Die Aussage ist nur: „Es ist besser, als es einfach direkt zu benutzen.“

Koreanisch-Unterstützung

Durch die Integration des Kiwi-Morphologie-Analysators ist koreanisches Such-Indexing möglich. Bei Eingaben ohne Leerzeichen wie „E-Mail-Verifizierung“ wird auch bei einer Suche nach „E-Mail“ ein Treffer gefunden. Das ergänzt die Grenze des unicode61-Tokenizers von FTS5, der Koreanisch sonst nur nach Silben / Jamo trennt. Neologismen / Fachbegriffe, die Kiwi nicht gut verarbeitet, können die Suchqualität allerdings beeinflussen.

Installation in 5 Minuten

Ein einziger Satz in der Session genügt:

"Installiere es nach INSTALL.md aus https://github.com/hang-in/tunaLlama";

Der Agent installiert dann selbstständig Abhängigkeiten, konfiguriert .env, registriert das Plug-in und führt die Verifikation Schritt für Schritt durch.
Wenn Sie lieber manuell installieren möchten, siehe README.

Funktionsmatrix für beide Umgebungen

Claude Code und Codex CLI laufen zwar mit demselben Repository, aber einige Funktionen wurden nur auf einer Seite verifiziert (Messstand v0.5.6, Claude Code 2.1.138 + Codex CLI 0.128.0):

EintragClaude CodeCodex CLI13 MCP-Tools aufrufbar✓✓
DB-Sharing (~/.tunallama/memory.db)✓✓
state.md-Sharing✓✓
Expliziter Aufruf von tuna_load_memory / tuna_recall✓✓
Automatische Agent-Erkennung✓
SessionStart-Hook + automatisches Voranstellen von state.md✓
(v0.5.5+)✗Automatisches Anhängen von MCP-Resources✗✗
In Claude Code funktioniert das automatische Voranstellen von state.md automatisch,
in Codex CLI wird empfohlen, im ersten Turn explizit tuna_load_memory aufzurufen oder die Docs direkt zu holen.
Da das Aufrufen der 13 MCP-Tools auf beiden Seiten normal funktioniert, ist die Delegation selbst auf Tool-Ebene möglich.

Grenzen

Einsparungen bei Nutzungslimits beruhen auf subjektivem Erleben (wie oben erwähnt)
Kosten des System-Prompts für MCP-Tools sind ein beabsichtigter Trade-off – die Beschreibungen + Schemas der 13 Tools fügen jedem Conversation-System-Prompt etwa 1.6k Tokens voran. Das ist kein versehentliches Aufblähen des Kontexts, sondern bewusst als Affordance-Kosten dafür ausgelegt, dass der Architect geeignete Delegationstools auswählen kann

Lokale LLM-Umgebung (Ollama usw., auch Ollama Cloud funktioniert normal) ist Pflicht – ohne sie funktioniert es nicht
Suchmetriken basieren auf synthetischen Seeds (wie oben erwähnt)
Einige Funktionen in Codex CLI funktionieren nicht (siehe Matrix oben)
Suchqualität kann durch koreanische Neologismen / Fachbegriffe beeinflusst werden

Warum nicht Prompt-Seeds / AGENTS.md

Es wird nicht versucht, Kontextgrenzen zu lösen, indem man den Agenten mehr Dokumente lesen lässt.
Stattdessen werden Aufgaben in kleine Einheiten zerlegt und per MCP-Tool an lokale / kostengünstige LLMs übergeben; das übergeordnete Architect-Modell konzentriert sich auf kurze Specs, Review-Ergebnisse und die Beurteilung des finalen Diffs.
Dokumentbasierte Betriebsregeln können mit der Zeit stale state, Drift und Lost-in-the-middle-Probleme erzeugen.
tunaLlama vermeidet das, indem Delegation-Calls in SQLite protokolliert werden und eine Ausführungsschicht für Suche / Recall bei Bedarf bereitsteht.

Für wen das hilfreich sein könnte

Nutzer von Claude Code Pro/Max mit Flatrate (Motivation: Limit-Management)
Nutzer von Codex CLI (Management von OpenAI-Flatrate / API-Quota)
Personen mit bestehender Ollama Local / Ollama Cloud / LM Studio-Umgebung
Personen, die mit koreanischen Aufgaben arbeiten (Kiwi-Integration)

Tests / Lizenz

Usable Dogfooding Release v0.5.x. 507 Unit-/Plug-in-Tests + 27 Integrations-/Search-Quality-Tests, 90 % Coverage.
Der Messbefehl ist im README angegeben (pytest --no-cov -q -m "not search_quality and not integration").
Lizenz ist MIT. Das englische README (README.en.md) wird synchron gehalten. Feedback / Issues / PRs sind willkommen.
Vorschläge zur Kompatibilität mit anderen AI-CLIs sind ebenfalls willkommen.