NanoClaw - Mini-Agent für ressourcenarme Setups

Wofür NanoClaw konzipiert ist

NanoClaw entsteht aus einer pragmatischen Beobachtung: Nicht jedes Agenten-Szenario braucht die volle Wucht eines Frameworks mit Vektor-Stores, asynchronen Tool-Pipelines und Cloud-LLM-Anbindung. Sehr viele Aufgaben in der Industrie, im Smart Home oder in mobilen Außeneinsätzen sind klein, fokussiert und verlangen vor allem zwei Dinge: niedriger Ressourcenverbrauch und Offline-Fähigkeit. Genau dort setzt NanoClaw an. Die Bibliothek ist nicht als kleiner Bruder im Sinne eines abgespeckten Spielzeugs gedacht, sondern als eigenständige Variante, die bewusst auf bestimmte Komfortfunktionen verzichtet, um auf Geräten mit 512 MB bis 2 GB RAM zuverlässig zu laufen.

Klassische Einsatzfelder sind Edge-AI-Knoten in Fertigungslinien, autonome Sensoren in der Landwirtschaft, Heim-Hubs, die Geräte über MQTT oder Zigbee orchestrieren, sowie kleine Service-Roboter, die nur sporadisch Online-Verbindung haben. In all diesen Szenarien ist eine permanente Anbindung an einen Cloud-LLM-Anbieter weder wünschenswert noch zuverlässig. Latenz, Datenschutz, Roaming-Kosten oder schlicht eine Funklochsituation machen Cloud-Calls zur Belastung. NanoClaw schiebt deshalb das Modell auf das Gerät und nutzt vor Ort kompakte Sprachmodelle wie Llama 3.2 1B oder Phi-3-mini.

Was geht mit NanoClaw konkret? Klassifikationsaufgaben, kurze Dialoge, Befehlsinterpretation, einfache Tool-Aufrufe, regelbasierte Entscheidungen mit etwas LLM-Würze und natürlich Sensor-Auswertung mit menschenlesbarer Begründung. Ein Beispiel: Ein Pi 5 in einem Gewächshaus liest alle fünf Minuten Temperatur, Bodenfeuchte und Luftqualität, gibt diese Werte als Kontext an NanoClaw und lässt den Agenten entscheiden, ob die Bewässerung gestartet werden soll, ob ein Lüftungsfenster geöffnet werden muss oder ob ein Hinweis an den Betreiber gesendet wird. Das alles funktioniert vollständig lokal, ohne dass ein einziges Byte das Netzwerk verlässt.

Was geht nicht beziehungsweise nicht gut? Komplexe mehrstufige Recherche, lange Tool-Chains mit fünf oder mehr Schritten, hochpräzise Generierung längerer Texte, anspruchsvolle Code-Erzeugung oder Reasoning-Aufgaben, die ein 70B-Modell verlangen. Sobald ein Use-Case mehrere parallele Werkzeuge orchestrieren muss, asynchrone API-Calls erfordert oder ein semantisches Gedächtnis über Wochen aufbaut, stößt NanoClaw an seine Grenzen. Das ist keine Schwäche, sondern ein bewusstes Designziel: NanoClaw will nicht alles können, sondern das Wenige, das es kann, schnell, zuverlässig und mit minimaler Hardware.

Diese Fokussierung hat einen weiteren angenehmen Effekt: Die Code-Basis bleibt überschaubar, Wartung und Auditierbarkeit sind deutlich einfacher als bei einem Vollframework. Wer in regulierten Umgebungen arbeitet, etwa Medizintechnik, kritische Infrastruktur oder OT-Systeme, schätzt diese geringe Angriffsfläche. Wo OpenClaw mit Plugins, MCP-Servern und Vektor-Datenbanken eine reichhaltige Oberfläche bietet, präsentiert sich NanoClaw bewusst minimalistisch und damit sicherheitstechnisch übersichtlicher.

Architektur-Unterschiede zu OpenClaw

Wer OpenClaw kennt, findet in NanoClaw eine reduzierte, aber konzeptionell vertraute Welt. Das Kernobjekt heißt weiterhin Agent, Tools werden registriert, Prompts strukturiert und Antworten gestreamt. Allerdings wurden mehrere Subsysteme entweder weggelassen oder durch leichtgewichtige Varianten ersetzt. Das wichtigste Beispiel ist das Memory-Modul. Während OpenClaw zwischen Buffer-Memory, Summary-Memory und einem Retrieval-basierten Vektor-Memory wählen lässt, kennt NanoClaw nur einen einzigen Modus: einen Ringpuffer mit maximal zehn Nachrichten. Das reicht für Konversationen über kurze Zeiträume und vermeidet, dass das Modell auf einem Pi mit großen Kontextfenstern bestraft wird.

Ein zweiter wesentlicher Unterschied liegt im Tool-System. OpenClaw nutzt Pydantic, um Eingaben und Ausgaben jeder Funktion typsicher zu validieren. Auf einem Embedded-Board ist diese Validierung jedoch oft Overkill und kostet Startzeit sowie Speicher. NanoClaw verzichtet daher auf Pydantic und setzt auf einfache Python-Annotationen mit optionaler Laufzeitprüfung. Das ist weniger streng, aber für die typischen drei bis fünf Tools eines Edge-Agenten völlig ausreichend. Wer mehr Robustheit braucht, kann in seinen eigenen Funktionen weiterhin manuell prüfen.

Auch die MCP-Anbindung ist anders ausgeprägt. OpenClaw spricht das volle Model-Context-Protocol mit Server-Discovery, Capability-Negotiation und langen, persistierenden Verbindungen. NanoClaw unterstützt ein Subset, das vor allem auf lokal laufende Tools zielt: Filesystem, lokales SQLite, einfache HTTP-Endpunkte im selben Netz. Remote-MCP-Server über das Internet sind theoretisch möglich, aber ausdrücklich nicht der Hauptanwendungsfall. Diese Beschränkung passt zur Edge-Idee, denn ein autarker Knoten soll nicht von externen Diensten abhängen.

Sehr deutlich wird der Unterschied bei Asynchronität. OpenClaw ist von Grund auf async und erlaubt parallele Tool-Aufrufe, Streaming-Antworten und nebenläufige LLM-Anfragen. NanoClaw arbeitet synchron, weil die unterliegenden Inferenz-Engines wie llama.cpp auf einem Pi sowieso einen einzigen Worker ausnutzen und parallele Aufrufe wenig bringen. Die synchrone Natur vereinfacht das Debugging in eingebetteten Umgebungen erheblich, in denen man oft per serieller Konsole arbeitet und keine üppigen Profiler zur Verfügung hat.

Schließlich unterscheidet sich der Speicher-Footprint. OpenClaw setzt typischerweise 2 GB RAM voraus, allein wegen der diversen Subsysteme und der ausgereiften Logging-Infrastruktur. NanoClaw läuft mit 512 MB an, wenn das gewählte Modell ebenfalls schlank ist. Diese Schwelle ist wichtig, weil sie eine ganze Klasse älterer Hardware ins Spiel bringt: Pi Zero 2 W, ältere Industrie-PCs, ARM-Boards der Generation vor 2020.

Aspekt	OpenClaw	NanoClaw
Memory-Strategien	Buffer / Summary / Retrieval	Buffer (max 10 Msgs)
MCP-Support	Voll	Subset (lokale Tools)
RAM-Mindestbedarf	2 GB	512 MB
Tool-System	Vollständig typisiert	Light, kein Pydantic
Async-Tools	Ja	Nein

Setup auf einem Raspberry Pi

Der bevorzugte Einstieg in NanoClaw ist ein Raspberry Pi 5 mit 8 GB RAM, weil dieses Board genug Reserve für Modelle bis 3B Parameter bietet und gleichzeitig die übliche Peripherie (GPIO, USB, HDMI) bereitstellt. Der Pi 4 funktioniert ebenfalls, hier sollte allerdings die 8-GB-Variante gewählt werden, wenn man nicht ausschließlich mit dem 1B-Modell arbeiten möchte. Als Betriebssystem hat sich Raspbian Bookworm bewährt, weil es einen aktuellen Python-3.11-Stack mitbringt und mit wenig Konfiguration auskommt.

Die Installationsschritte sind absichtlich knapp gehalten. Im ersten Block werden System-Updates eingespielt, Git und ein Python-Venv-Tool nachgerüstet, anschließend das NanoClaw-Repository geklont und im editierbaren Modus installiert. Im zweiten Block kommt Ollama hinzu, das die Modellverwaltung übernimmt und das Pull-Format vereinheitlicht. Für die ersten Experimente reicht Llama 3.2 3B, später kann man je nach Anwendungsfall auf 1B abrüsten oder auf Phi-3-mini wechseln.

# Raspberry Pi 5, Raspbian Bookworm
sudo apt update && sudo apt install -y python3-venv git
git clone https://github.com/openclaw/nanoclaw.git
cd nanoclaw
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

# Ollama für lokales Llama 3.2 3B
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2:3b

Beim ersten Start sollte man genau hinhören, sprich auf den Lüfter achten. Ein Pi 5 ohne aktive Kühlung throttelt unter Dauerlast nach wenigen Minuten und die Token-Rate halbiert sich. Wir empfehlen einen offiziellen Pi-Lüfter oder ein Aluminiumgehäuse mit passiver Kühlung und großen Rippen. Damit hält das Board die in der Tabelle weiter unten genannten 4 bis 6 Token pro Sekunde stabil über Stunden. Ohne Kühlung sinkt der Wert auf 2 bis 3 Token pro Sekunde, was für interaktive Szenarien zu langsam wird.

Beim Stromverbrauch sollte man realistisch planen. Ein Pi 5 mit ausgelastetem CPU zieht etwa 7 bis 9 Watt, ein Pi 4 etwa 5 bis 7 Watt. Über einen Tag gerechnet sind das bei Dauerbetrieb rund 0,2 kWh, also wenige Cent an Stromkosten. Wer mit Solar oder Akku arbeitet, plant am besten 12 V mit einem effizienten Buck-Konverter ein und gönnt dem Board eine Pufferung von mindestens zwei Stunden, damit kurze Stromausfälle keine SD-Karten-Korruption verursachen. Apropos SD-Karte: Für produktive Setups gehört eine SSD per USB-3 oder, beim Pi 5, per offiziellem M.2-HAT zur Pflichtausstattung. Das verkürzt Modell-Ladezeiten von 40 Sekunden auf rund 8 Sekunden und verhindert Abnutzung der SD-Karte durch Logging.

Für die Performance-Erwartung gilt eine einfache Faustregel: Pro Milliarde Modellparameter rechnet man mit etwa 4 bis 8 Sekunden Antwortlatenz für eine kurze Antwort von rund 80 Tokens. Ein 1B-Modell antwortet also in 4 bis 8 Sekunden, ein 3B-Modell in 12 bis 24 Sekunden. Das fühlt sich für interaktive Chats nach Heimserver an, ist aber für getriggerte Hintergrundjobs absolut akzeptabel. Wer kürzer warten möchte, sollte mit System-Prompts arbeiten, die explizit knappe Antworten verlangen, und außerdem die Output-Token mit einem harten Limit (max_tokens) deckeln.

Modelle und Hardware-Empfehlungen

Die Wahl des richtigen Modells ist auf Edge-Geräten der wichtigste Stellhebel. Anders als in der Cloud, wo man oft den größten verfügbaren Anbieter nimmt und sich um Preis pro Token sorgt, geht es lokal um den schmalen Grat zwischen Qualität und Reaktionszeit. Llama 3.2 1B ist erstaunlich fähig für eng umrissene Aufgaben wie Klassifikation, kurze Antworten oder Befehlsausführung. Sobald jedoch mehr Kontext oder zusammenhängendes Reasoning gefragt ist, lohnt sich der Sprung auf 3B oder Phi-3-mini.

Eine oft unterschätzte Variable ist das Quantisierungsformat. Standardmäßig liefert Ollama Q4_K_M, was eine sehr gute Balance darstellt. Wer mehr Geschwindigkeit will, kann auf Q4_0 wechseln und bekommt etwa 10 bis 15 Prozent mehr Token pro Sekunde, allerdings auf Kosten leichter Qualitätseinbußen. Wer höchste Qualität sucht und genug RAM hat, nimmt Q5_K_M oder Q6_K. In den meisten Edge-Szenarien bleibt Q4_K_M die beste Wahl, weil sie weder bei Speicher noch bei Geschwindigkeit Kompromisse erzwingt.

Bei der Hardware-Empfehlung gilt eine schlichte Hierarchie. Für reine Klassifikationsknoten ohne Dialog reicht ein Pi 4 mit 4 GB und einem 1B-Modell. Für gemischte Workloads mit gelegentlichen Konversationen empfiehlt sich der Pi 5 mit 8 GB und einem 3B-Modell. Für anspruchsvollere Setups in der Industrie sind Boards wie der Radxa Rock 5B oder kleine Mini-PCs auf Basis von Intel N100 attraktiv, weil sie deutlich mehr RAM und schnellere SSDs bieten und dabei unter 15 Watt bleiben. Diese kleinen X86-Maschinen laufen in derselben NanoClaw-Konfiguration wie ein Pi, profitieren aber von AVX2-Beschleunigung und sind dadurch für 7B-Modelle noch praktikabel, was auf einem Pi nicht mehr Spaß macht.

Wichtig ist außerdem der RAM-Headroom. Ein Modell, das laut Tabelle 3 GB benötigt, sollte nicht auf einem Board mit exakt 4 GB RAM laufen, weil das Betriebssystem, der NanoClaw-Prozess und etwaige Tool-Server ebenfalls Speicher belegen. Als Faustregel rechnen wir den Modellbedarf plus 1 GB Sicherheit. Auf einem Pi 5 mit 8 GB sind also komfortable 5 GB für Tools, Caches und das System frei. Bei knappem Speicher hilft Swap auf SSD, allerdings nur als Notnagel, denn das Auslagern aktiver Modellgewichte kostet drastisch Performance.

Modell	RAM-Bedarf	Token/s (Pi 5)	Use-Case
Llama 3.2 1B	1,5 GB	10-12	Klassifikation, kurze Antworten
Llama 3.2 3B	3 GB	4-6	Allzweck-Mini-Assistent
Phi-3-mini	3,5 GB	3-5	Code-orientiert

Migration NanoClaw zu OpenClaw

Wer ein Projekt mit NanoClaw begonnen hat und im Lauf der Zeit feststellt, dass die Anforderungen über die schmale Variante hinauswachsen, steht früher oder später vor einer Migration zu OpenClaw. Typische Auslöser sind ein Wechsel von Edge-Inferenz auf Cloud-LLMs, neue Tool-Pipelines mit asynchronen Aufrufen, ein semantisches Gedächtnis über mehrere Sitzungen oder die Notwendigkeit, mit MCP-Servern zu sprechen, die NanoClaw nicht abdeckt. In all diesen Fällen ist der Wechsel kein Drama, weil die beiden Bibliotheken konzeptionell sehr nah verwandt sind.

Migrierbar sind insbesondere Tools und Prompts. Eine Funktion, die unter NanoClaw als Tool registriert war, lässt sich in OpenClaw mit minimalen Anpassungen übernehmen. Die Hauptarbeit besteht darin, Pydantic-Schemas für Eingaben und Ausgaben zu ergänzen, was sich in der Regel innerhalb weniger Minuten pro Tool erledigen lässt. Auch System-Prompts wandern unverändert. Wer Best-Practice-Prompts für sein 3B-Modell erarbeitet hat, sollte diese aber für ein größeres Cloud-Modell überprüfen, weil dort andere Formulierungen besser greifen, etwa explizite Rollen oder Few-Shot-Beispiele.

Nicht migrierbar im Eins-zu-eins-Sinn sind die Memory-Strategien. NanoClaw kennt nur den Buffer, OpenClaw bietet zusätzlich Summary und Retrieval. Wer von Anfang an plant, später zu migrieren, sollte deshalb seinen Buffer-Inhalt sauber strukturieren, also klare Rollen, knappe Texte und keine Tool-Outputs als rohe JSON-Schnipsel. Damit lässt sich der Übergang zu Summary-Memory leichter vollziehen. Für Retrieval-Memory braucht es ohnehin einen separaten Schritt: Konversationen oder Dokumente müssen embedded und in einem Vektor-Store abgelegt werden, was unter NanoClaw schlicht nicht vorgesehen ist.

Ein weiterer Punkt ist die Async-Umstellung. Tools, die unter NanoClaw als synchrone Funktionen liefen, werden unter OpenClaw idealerweise als async-Funktionen registriert, damit das Framework parallele Aufrufe orchestrieren kann. Dieser Schritt ist wichtig, weil OpenClaw in produktiven Setups erst dadurch seine Stärken ausspielt. Glücklicherweise ist die Anpassung mechanisch einfach: Aus def wird async def, aus blockierenden HTTP-Calls werden httpx-AsyncClient-Aufrufe und aus blockierender Datenbank-Logik wird ein asyncpg- oder aiosqlite-basiertes Pendant. Wer das von Anfang an im Hinterkopf hat, schreibt seine NanoClaw-Tools in einer Form, die später mit minimalem Mehraufwand migrierbar ist.

Fazit der Akademie

NanoClaw ist nicht der kleine Bruder, den man später wegwirft, sondern eine bewusste Antwort auf eine eigene Klasse von Problemen. Wann ist es die richtige Wahl? Immer dann, wenn die Hardware klein, das Budget für Cloud-Calls eng, der Datenschutzdruck hoch oder die Konnektivität unzuverlässig ist. Für Edge-Knoten, IoT-Hubs und autarke Industrieanwendungen liefert NanoClaw genau die Mischung aus Schlankheit und LLM-Komfort, die viele Teams seit Jahren manuell zusammenstückeln. Das Framework verkürzt diese Bastelarbeit auf wenige Tage und stellt eine vertraute Agent-API bereit.

Wann ist NanoClaw die falsche Wahl? Sobald ein Projekt komplexe Tool-Chains, lange Reasoning-Pfade, Multi-Agenten-Konstellationen oder einen umfangreichen Vektor-Speicher verlangt. Auch wenn die Latenzanforderungen unter zwei Sekunden für lange Antworten liegen, ist Edge-Inferenz schlicht nicht das richtige Werkzeug, dann sollte man auf OpenClaw und einen Cloud-LLM-Anbieter wechseln. Diese Klarheit gehört zu den wichtigsten Lehren dieser Bonus-Lektion: Werkzeuge nach Use-Case wählen, nicht nach Hype.

Für die weitere Vertiefung verweisen wir auf den Hauptpfad der OpenClaw-Akademie, insbesondere die Module zu Memory-Strategien, MCP-Integration und Tool-Design. Wer dort die ausführlichen Konzepte verstanden hat, kann sie in beide Richtungen anwenden: einmal bei der Vollausstattung mit OpenClaw und einmal bei der bewussten Reduktion mit NanoClaw. Beide Welten profitieren voneinander, denn ein Entwickler, der gelernt hat, mit 512 MB sparsam zu arbeiten, schreibt auch in der Cloud effizientere Agenten.