Nanocoder: Terminal-Coding-Agent mit eigenem Modell und lokaler Datenhaltung

Welches Problem Nanocoder löst und für wen es gedacht ist

Die meisten Coding-Agenten binden Nutzer an einen Anbieter. Wer den Agenten im Terminal startet, gibt damit auch vor, welches Modell die Prompts sieht und wohin der Code Ausschnitte gehen. Nanocoder dreht diese Voreinstellung um: Der Agent ist das Werkzeug, das Modell bleibt austauschbar. Die README nennt als Kernaussage, der Agent laufe auf dem Modell der eigenen Wahl, lokal über Ollama oder über jede OpenAI-kompatible API wie OpenRouter, Anthropic und Google. Der Nutzer entscheide, welcher Anbieter den Code ausführt und wohin die Daten gehen.

Die Zielgruppe sind Entwickler, die bereits ein Modell-Abo oder eine lokale GPU haben und keinen zweiten Anbietervertrag wollen. Ebenso angesprochen sind Teams, bei denen Prompts das Firmennetz nicht verlassen dürfen, weil der Agent dann gegen eine lokale Ollama-Instanz läuft. Die Nano Collective positioniert das Projekt ausdrücklich als nichtkommerziell, ohne Bezahlstufen und ohne Telemetrie, die Prompts weiterleitet. Das ist eine Organisationsentscheidung, keine technische Garantie. Wer den Agenten einsetzt, sollte die tatsächlichen Netzwerkverbindungen selbst prüfen, statt sich auf die Selbstbeschreibung zu verlassen.

Wie der Agent aufgebaut ist: Provider-Schicht, Modi und Terminal-Rendering

Nanocoder ist in TypeScript geschrieben. Die sichtbare Architektur besteht aus drei Teilen: einer Provider-Schicht, die entweder Ollama oder eine OpenAI-kompatible HTTP-API anspricht, einer Reihe von Entwicklungsmodi und einer Terminal-Oberfläche mit zwei Rendering-Varianten.

Die Provider-Schicht ist der Kern der Portabilität. Statt Modellaufrufe fest zu verdrahten, nimmt der Agent Provider und Modell als Parameter entgegen, entweder beim Start über CLI-Flags oder interaktiv. Die Modi steuern, wie viel Autonomie der Agent bekommt. Die README nennt vier: normal, auto-accept, yolo und plan. Im Plan-Modus arbeitet der Agent ohne Schreibzugriff, im Yolo-Modus ohne Rückfrage. Dazwischen liegen die Abstufungen, in denen der Agent Änderungen vorschlägt und der Nutzer sie bestätigt.

Das Rendering ist ein eigener Designpunkt. Im Inline-Modus, dem Standard, schreibt der Agent fertige Nachrichten in den nativen Scrollback des Terminals. Scrollbar, Mausrad und Suche des Terminals funktionieren dadurch unverändert, und das Transkript bleibt nach dem Beenden sichtbar. Im Fullscreen-Modus, aktiviert über das Flag --alt-screen oder den Schlüssel alternateScreen in den Preferences, läuft die Oberfläche auf dem alternativen Bildschirmpuffer mit eigenem Scrolling, Scroll-Indikator und automatischem Zurückspringen ans Ende bei neuer Ausgabe. Der Preis: Mouse Reporting entzieht dem Terminal die Klick-Zieh-Auswahl, weshalb Ctrl+P einen Auswahlmodus umschaltet. Wer häufig kopiert, sollte beim Inline-Modus bleiben.

Installation und die ersten Befehle

Die Installation erfolgt global über npm. Die README zeigt den kürzesten Weg:

npm install -g @nanocollective/nanocoder nanocoder

Alternativ nennt die Dokumentation Homebrew für macOS und Linux sowie Nix Flakes. Wer eine dieser Bezugsquellen bevorzugt, findet die Details in docs/getting-started/installation.md.

Provider und Modell lassen sich direkt beim Start setzen. Für einen nicht-interaktiven Lauf gegen OpenRouter gibt die README dieses Beispiel:

nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"

Für einen interaktiven Lauf gegen eine lokale Ollama-Instanz:

nanocoder --provider ollama --model llama3.1

Die Flags dürfen vor oder nach dem Unterbefehl run stehen, beide Varianten sind laut README gültig. Der Modus lässt sich ebenfalls vorab wählen, etwa nanocoder --mode plan run "audit the auth module" für einen Lauf ohne Schreibzugriff. Ein reiner Modusstart ohne Aufgabe ist ebenfalls möglich, zum Beispiel nanocoder --mode yolo.

Für das Rendering gibt es zwei gegenläufige Flags: --alt-screen erzwingt den Fullscreen-Modus, --no-alt-screen erzwingt Inline auch dann, wenn die Preference alternateScreen auf true steht. Ein Sonderfall, der in der README erwähnt wird: /clear setzt das Terminal vollständig zurück, und beim Beenden über Ctrl+C oder /exit wird die Eingabeoberfläche sauber entfernt, sodass das Transkript stehen bleibt.

Konfiguration jenseits der Kommandozeile

Dauerhafte Einstellungen liegen in einer Preferences-Datei. Die README nennt konkret den Schlüssel alternateScreen, der den Fullscreen-Modus dauerhaft aktiviert. Die Dokumentationsstruktur verweist für weitere Optionen auf den Bereich Configuration, der AI-Provider, MCP-Server, Preferences, Logging und Timeouts abdeckt. Wer den Agenten produktiv nutzt, sollte diese Datei bewusst setzen, statt sich auf die Standardwerte zu verlassen, weil Timeouts und Logging das Verhalten bei langen Modellläufen bestimmen.

Ein weiterer Konfigurationsbereich sind Skills. Die Feature-Dokumentation führt darunter Commands, Subagents, Tools und Event-Trigger. Dazu kommen Lifecycle-Hooks, ein projektbezogener Daemon, Checkpointing, Task-Management und die bereits erwähnten Entwicklungsmodi. Das ist deutlich mehr als ein Chat-Wrapper: Der Agent kann über Hooks in bestehende Abläufe eingreifen und über den Daemon projektbezogen laufen. Wer diese Teile nutzt, sollte die entsprechenden Abschnitte der Feature-Dokumentation lesen, bevor er sie aktiviert, weil Hooks und Event-Trigger das Verhalten des Agenten ohne sichtbare Rückfrage verändern können.

Für MCP-Server gilt dasselbe Muster: Sie werden in der Konfiguration eingetragen und erweitern den Werkzeugkasten des Agenten. Die README nennt keine einzelnen Server, sondern verweist auf docs/configuration/index.md. Ohne diese Datei bleibt offen, welche Transportarten unterstützt werden.

Grenzen und Fälle, in denen Nanocoder das falsche Werkzeug ist

Die Lizenz ist im Repository als NOASSERTION gekennzeichnet. Das bedeutet, dass die automatische Erkennung keine Standardlizenz zuordnen konnte. Wer Nanocoder in einem Unternehmen einsetzen will, muss die tatsächliche Lizenzdatei selbst lesen und gegebenenfalls rechtlich prüfen lassen. Die README beschreibt das Projekt als nichtkommerziell und verweist auf eine Economics Charter in der Dokumentation. Diese Charter regelt nach der Beschreibung die Bezahlung von Beiträgen, nicht die Nutzungsrechte am Code. Die beiden Dinge sollten nicht verwechselt werden.

Ein zweiter Punkt ist die Modellqualität. Nanocoder liefert die Verbindung zum Modell, nicht das Modell. Ob ein lokales Ollama-Modell einen Refactoring-Auftrag sinnvoll ausführt, hängt allein von diesem Modell ab. Wer ein kleines lokales Modell mit einem großen gehosteten vergleicht, wird unterschiedliche Ergebnisse sehen, ohne dass Nanocoder daran etwas ändert. Der Agent ist ein Harness, keine Qualitätsgarantie.

Drittens: Der Yolo-Modus führt Änderungen ohne Rückfrage aus. Die README beschreibt ihn als einen von vier Modi, ohne Sicherheitsnetz zu nennen. Wer ihn auf einem Repository ohne Versionskontrolle startet, riskiert überschriebene Dateien. Der Plan-Modus ist die naheliegende Alternative für einen ersten Lauf, weil er laut README keinen Schreibzugriff vorsieht.

Schließlich die Frage der Reife. Die letzten Releases liegen laut Repository bei v1.30.0 vom 26. August 2026, davor v1.29.0 im Juli und v1.28.1 im Juni. Der Rhythmus ist monatlich, die Versionsnummern sind noch vor 2.0. Wer einen stabilen Agenten mit langfristiger API-Zusage braucht, sollte die Release Notes vor einem Upgrade lesen.

Alternative: ein Anbieter-Agent mit fertigem Modell

Die naheliegende Alternative ist ein Coding-Agent, der fest an ein Modell eines Anbieters gebunden ist, etwa Claude Code oder Codex. Der Unterschied liegt nicht in der Oberfläche, sondern in der Kette vom Terminal bis zum Modell. Bei einem anbietergebundenen Agenten entfallen Provider-Konfiguration und Modellauswahl: Man installiert, meldet sich an, und das Modell ist gesetzt. Dafür bestimmt der Anbieter, welche Modelle verfügbar sind, wohin die Prompts gehen und welche Bedingungen gelten.

Nanocoder kehrt diese Kette um. Der Nutzer konfiguriert Provider und Modell, kann zwischen lokalem Ollama und einer gehosteten API wechseln und ist nicht an einen Anbieter gebunden. Die README formuliert das als Grundsatz: Der Harness bleibe aus Prinzip multi-provider, man sei nie an das Modell eines Herstellers gebunden. Der Preis ist Konfigurationsarbeit. Wer keinen Provider einträgt, hat keinen Agenten. Wer ein lokales Modell wählt, braucht die passende Hardware und akzeptiert langsamere Läufe. Wer eine gehostete API wählt, gibt die Datenhoheit genau so weit ab, wie es die API verlangt.

Ein zweiter Unterschied ist die Governance. Nanocoder wird von einer Collective entwickelt, nicht von einem Unternehmen mit Produkt-Roadmap. Die README nennt als Vorteil, es gebe keine Bezahlstufen und keine Roadmap, die nach Monetarisierung ausgerichtet ist. Der Nachteil ist weniger vorhersehbar: Es gibt keinen kommerziellen Support, keine SLA und keine Garantie, dass ein bestimmter Anbieter dauerhaft unterstützt wird. Wer einen Ansprechpartner bei Ausfällen braucht, ist bei einem Anbieter-Agenten besser aufgehoben.

Wartung, Upgrades und was vor dem Einsatz zu prüfen ist

Die Wartungslast liegt beim Nutzer. Nanocoder wird global über npm installiert, ein Upgrade erfolgt also über denselben Kanal. Bei monatlichen Releases ist mit Änderungen an Flags, Preferences-Schlüsseln oder Modi zu rechnen. Wer den Agenten in einer CI oder in einem geteilten Repository einsetzt, sollte die Version pinnen und die Release Notes vor jedem Sprung lesen, statt automatisch zu aktualisieren.

Ein zweiter Wartungspunkt sind die Provider selbst. Eine OpenAI-kompatible API kann sich ändern, ein lokales Ollama-Modell wird aktualisiert, und beides kann das Verhalten des Agenten verschieben, ohne dass am Agenten etwas geändert wurde. Wer Reproduzierbarkeit braucht, sollte Provider und Modellversion in der Konfiguration festhalten.

Zur Lizenz: NOASSERTION ist keine Lizenzangabe, sondern das Fehlen einer erkannten. Vor einer kommerziellen Nutzung ist die LICENSE-Datei im Repository zu lesen. Die Economics Charter der Collective regelt nach der Beschreibung die Vergütung von Beiträgen und ersetzt keine Nutzungslizenz. Wer Nanocoder in einem Produkt einsetzen will, sollte diese beiden Dokumente getrennt prüfen und die Bewertung nicht aus der README ableiten.

Konkret vor dem ersten produktiven Lauf: die Preferences-Datei mit alternateScreen, Timeouts und Logging setzen, den Provider in der Konfiguration hinterlegen, einen Lauf mit nanocoder --mode plan auf dem Ziel-Repository durchführen und erst danach einen Modus mit Schreibzugriff wählen. Wer diese Reihenfolge einhält, sieht vor dem ersten Commit, wie der Agent mit der eigenen Codebasis umgeht.

Redaktionelles Fazit

Wer einen Terminal-Agenten sucht, der Ollama lokal oder eine OpenAI-kompatible API nutzen kann und dessen Verhalten über Konfigurationsdateien nachvollziehbar bleibt, findet in Nanocoder eine passende Basis. Wer einen Anbieter mit SLA, Support und rechtsverbindlicher Lizenzzusage braucht, sollte vorher die NOASSERTION-Kennzeichnung und die Economics Charter prüfen. Vor dem Einsatz im Team zuerst die Preferences-Datei mit alternateScreen, Timeouts und Logging sowie die Provider-Konfiguration für Ollama oder OpenRouter festlegen und einen Probelauf mit nanocoder --mode plan auf dem eigenen Repository durchführen, bevor der Agent Schreibrechte erhält.

Offizielle Quellen

1. Issues
2. Nano-Collective/nanocoder on GitHub
3. Project website
4. README
5. Releases