In pi: Das 92.000-Sterne-Toolkit für deinen eigenen Agenten

Claude Code, Codex und Gemini CLI sind Agent-Harnesses, die jemand anders entworfen hat — und verbringst du deinen Arbeitstag in einem davon, lebst du mit dieser Design-Entscheidung. Willst du ein Verhalten ändern, ein Tool ergänzen, eine Permission-Regel anpassen? Du wartest, bis der Hersteller liefert. Du kennst den Inhalt des System-Prompts nicht, siehst die Schleife nicht, die die Tools ausführt, und kannst nichts davon ändern — obwohl diese Tools längst der Hauptarbeitsplatz tausender Entwickler sind.

Ein Open-Source-Projekt geht den genau umgekehrten Weg: pi, ein Toolkit, das die Einzelteile liefert, um den eigenen Agenten zu bauen, vom Modell-Connector bis zur Oberfläche. Es holte im ersten Jahr 92.000 GitHub-Sterne und liefert etwa jede Woche ein Release. Dieser Artikel behandelt, was pi wirklich in der Box liefert, wie man mit seinem SDK den eigenen Agenten baut, und ein ehrliches Urteil gegen die fertigen Harnesses.

Ein Harness ist die gesamte Maschinerie rund um ein Sprachmodell, die daraus einen funktionierenden Agenten macht. Ein Modell allein kann nur eins: Text lesen und Text erzeugen. Es liest keine Dateien, führt keinen einzigen Befehl aus, und erinnert sich von einer Session zur nächsten an nichts. Alles andere ist der Harness — der System-Prompt, der das Modell rahmt, die Tools, die ihm zur Verfügung stehen, die Schleife, die Tool-Aufrufe ausführt und Ergebnisse zurückgibt, und die Oberfläche in deinem Terminal.

Der Harness entscheidet auch die Details, die im Alltag zählen: wie der Verlauf komprimiert wird, wenn der Kontext überläuft, wie ein Tool-Fehler ans Modell zurückgeht, was geloggt wird und was nicht. Claude Code ist ein Harness. Codex auch. Wenn dich ein Agent beeindruckt, geht ein Großteil des Verdienstes an diese Maschinerie, nicht ans Modell — setz dasselbe Modell in zwei verschiedene Harnesses ein, und du bekommst zwei Agenten, die auf ganz unterschiedlichem Niveau sind.

pi, gebaut von Earendil Works, zerlegt diese Maschinerie in wiederverwendbare Bausteine. Du kannst den Coding-Agenten so nutzen, wie er ist, oder dir die Bausteine einzeln nehmen und selbst bauen. Die zweite Option ist die, die uns interessiert.

pi ist ein Monorepo — ein einziges Repository, das fünf separat veröffentlichte Pakete beherbergt — und jedes Paket deckt eine Etage des Harness ab:

Paket	Was es macht
pi-ai	Einheitliche API zu OpenAI, Anthropic, Google und dem Rest: Response-Streaming, Reasoning-Blöcke mit ihren Denkstufen, dynamische Erkennung der Modelle jedes Anbieters. Lab-Wechsel durch ein geändertes Argument.
pi-agent-core	Die Agent-Schleife selbst: Conversation-State, plus der Zyklus, der die Nachricht sendet, Tool-Aufrufe liest, sie ausführt und Ergebnisse zurückgibt, bis die Aufgabe fertig ist. Die kniffligen Fälle — ein fehlschlagendes Tool, eine abbrechende Antwort, parallele Aufrufe — sind bereits abgedeckt.
pi-tui	Terminal-Rendering-Bibliothek mit differenziellem Rendering: zeichnet nur neu, was sich auf dem Bildschirm ändert.
pi-coding-agent	Der komplette Coding-Agent, zusammengesetzt aus den obigen Bausteinen — der Beweis, dass das Toolkit für ein fertiges Produkt reicht.
pi-telemetry	Eigene Nutzungsmetriken einbinden, ohne Anbieter-Lock-in.

Die Agent-Schleife ist genau das Teil, das man von Grund auf schlecht schreiben würde; sie sauber zu bauen sind Wochen Arbeit, die man sich mit einem Import spart. Das Team wendet das gleiche Rezept auch anderswo an: ein eigenes Repository, pi-chat, nutzt dieselben Bausteine für Konversationsautomation.

Die Zahlen zeigen, dass die Formel funktioniert:

Metrik	Wert
GitHub-Sterne	92.123
Forks	11.400
Commits	5.700+
Lizenz	MIT
Releases in den ersten zwei Augustwochen 2026	3 (v0.84.2 am 14. August)

Die MIT-Lizenz bedeutet, dass du pi nutzen, ändern und ohne Einschränkung weitergeben darfst, auch in einem kommerziellen Produkt. pi ist kein Framework mehr unter vielen: es ist ein kompletter Harness, ausgeliefert in Einzelteilen, gepflegt in stetigem Tempo.

Die pi-CLI ist der fertig zusammengesetzte Coding-Agent, den du bekommst, bevor du überhaupt Code anfasst, und hier fängst du an. Die Installation ist eine Zeile, und ihr --ignore-scripts-Flag ist kein Detail: es verhindert, dass deine Abhängigkeiten ihre Install-Skripte ausführen — eine der meistmissbrauchten Angriffsflächen auf npm. Starte pi, verbinde deinen Anbieter mit dem Login-Befehl, und du hast einen Coding-Agenten direkt hier im Terminal. Die Statusleiste zeigt den aktuellen Ordner, die Session, verbrauchte Tokens und die Kosten in Echtzeit — du siehst jede Anfrage bepreist in dem Moment, in dem sie raus geht, statt die Rechnung erst am Monatsende zu entdecken.

Slash-Befehle decken den Alltag ab: model zum Modellwechsel mitten im Lauf, compact fasst den Verlauf zusammen, wenn der Kontext wächst, export zieht die Konversation heraus, settings für den Rest. Eine Markdown-Datei im Prompts-Ordner wird zu einem Befehl, den man per Namen auslöst.

pis wahre Signatur ist die Session-Verwaltung. Jede Konversation wird als JSONL im Home-Ordner gespeichert, nach Projekt sortiert — und der Verlauf ist tatsächlich ein Baum, keine Linie. Du kannst zu jedem Punkt einer Konversation zurückkehren und mit fork einen anderen Weg einschlagen, dann mit tree zwischen Branches wechseln. Ein misslungener Prompt kostet nichts mehr: zurück zum Knoten davor, nochmal versuchen, ohne den anderen Zweig zu verlieren. Da alles lokal gespeichert wird, bringt dich resume zurück in jede vergangene Session, selbst Wochen später. Weder Claude Code noch Codex bieten eine Verlaufsnavigation in dieser Form.

Standardmäßig bekommt das Modell nur vier Tools: read, write, edit und bash. Das ist sehr wenig im Vergleich zu den Agenten am Markt, und das ist Absicht (dazu weiter unten mehr). Die Konfiguration folgt derselben Logik: eine globale Settings-Datei im Home-Ordner, eine pro Projekt, die sie überschreibt, und ein Trust-System, das nachfragt, bevor es die lokalen Einstellungen eines erstmals geöffneten Ordners anwendet. Beim Umstieg lädt pi automatisch bestehende AGENTS.md- oder CLAUDE.md-Dateien als Kontext, sodass vorhandene Anweisungen ohne Umschreiben funktionieren.

Einen Agenten mit pis SDK zu bauen, beginnt mit einem einzigen Import: createAgentSession, dem man eine Model-Runtime und einen Session-Manager übergibt, liefert einen funktionierenden Agenten. Der Session-Manager ist die Wahl der Persistenz — im Speicher für ein Wegwerfskript, oder auf Platte, um Konversationen von Lauf zu Lauf wiederzufinden.

Wir haben es an einem lokalen Projekt getestet. Unser Skript fragt, was im aktuellen Ordner liegt; der Agent ruft sein read-Tool auf, liest den Ordner und antwortet. Das ist die volle Schleife, von uns geschrieben, in etwa zehn Zeilen TypeScript. Sessions, die das SDK erzeugt, haben dieselbe Baumstruktur wie die der CLI — jede Nachricht hängt an ihrem Elternteil — sodass Verlaufsverzweigung auch im eigenen Code funktioniert.

Bei den Custom Tools wird es interessant. defineTool nimmt einen Namen, eine Beschreibung, ein typisiertes Parameter-Schema und eine Execute-Funktion, und das Tool erscheint dem Modell genau wie read oder bash. Wir schrieben eins, das die Videoliste des Kanals abfragt, übergeben in customTools, und der Agent rief es von allein ab der ersten passenden Frage auf. Es ist im Grunde derselbe Mechanismus wie ein MCP-Server, nur dass alles in der eigenen Datei lebt — ohne separaten Prozess, ohne Protokoll dazwischen. Weil das Parameter-Schema typisiert ist, vervollständigt der Editor die Argumente automatisch, und der Agent bekommt bereits validierte Eingaben.

Man kontrolliert auch das Modell, die Denkstufe (von ganz aus bis maximal), die genaue Liste der Tools, die das Modell sieht, und sogar den ganzen System-Prompt über einen Resource-Loader, wenn man bei null anfangen will. Für die Anzeige gibt session.subscribe jedes Event zurück — gestreamten Text, Tool-Aufrufe, Fehler — die man umleiten kann, wohin man will: ein Terminal, ein Messaging-Bot, oder eine CI-Pipeline, die Pull Requests kommentiert. An einem Nachmittag wird man vom Nutzer eines Agenten zu jemandem, der einen geschrieben hat, und weiß endlich, was bei jeder Runde der Schleife passiert.

Die pi-CLI wird über vier Mechanismen angepasst, alle in normalen Ordnern im eigenen Projekt oder Home-Verzeichnis:

• Extensions — TypeScript-Module, die Tools, Slash-Befehle, Tastenkürzel oder UI-Elemente registrieren. Die Datei landet im Extensions-Ordner und lädt beim Start. Dort würde man zum Beispiel eine Permission-Wache schreiben: eine Extension, die Bash-Befehle abfängt und vor gefährlichen um Bestätigung bittet.
• Skills — Fähigkeitspakete nach dem Agent-Skills-Standard, demselben, den Anthropic populär machte, sodass bestehende Skills unverändert wiederverwendbar sind.
• Prompts — wiederverwendbare Prompts als reine Markdown-Dateien.
• Themes — laden sofort neu, während die CLI läuft.

All das installiert sich wie jedes andere Paket: pi install nimmt ein npm-Paket oder ein Git-Repository, und ein Befehl aktualisiert alles. Die Docs fassen die Philosophie in einem Satz zusammen: pi an die eigenen Workflows anpassen, nicht umgekehrt, ohne zu forken oder das Innere zu patchen.

Das ist das Gegenteil der großen Harnesses. Während Claude Code Sub-Agents, Plan-Modus und Permissions im Produkt liefert, lässt pi das bewusst weg, zum Bauen als Extension oder Installieren aus der Community. Die Wette ist klar: ein minimaler Kern, der sich kaum bewegt, und die gesamte Anpassung lebt auf der eigenen Seite, in Dateien, die man mit dem Projekt versioniert.

pis Transparenz zahlt sich in Arbeit aus, und dieser Preis hat drei Teile.

Erst die Guardrails: standardmäßig gibt es keine eingebauten Permission-Prompts, der Agent kann also einen Bash-Befehl ausführen, ohne zu fragen. Die offiziellen Docs stehen dazu und schlagen drei Isolationsmuster vor, Docker inklusive — aber diese vor dem Loslassen des Agenten auf einer wichtigen Maschine einzurichten, liegt in der eigenen Verantwortung.

Dann die Reife: das ist v0.84, nicht 1.0, mit rund hundert offenen Issues und einigen noch als experimentell markierten APIs, wie dem Remote-Session-Client, der erst in den letzten Wochen dazukam. Was heute funktioniert, kann beim nächsten Release brechen; das ist der normale Preis eines Projekts, das so schnell voranschreitet.

Und schließlich die Zeit. Jeder Komfort, den Claude Code ab Werk mitbringt — Plan-Modus, Sub-Agents, feingranulare Permissions — ist hier ein Projekt, das man selbst baut, oder ein Community-Paket, dem man hinterherjagt in der Hoffnung, dass es gepflegt bleibt. Das Extension-Ökosystem ist ein Jahr alt: man findet weniger fertige Pakete als Lücken zu füllen. Schon die Installation zeigt, wie viel Wachsamkeit das braucht, mit ihrem --ignore-scripts-Flag, und dieses Niveau muss über die gesamte Kette gehalten werden. Wer heute Abend noch Code liefern will, für den bremst pi erst aus, bevor es beschleunigt — den Haupt-Harness diese Woche allein wegen dieses Videos zu ersetzen, lohnt sich nicht.

pi ist für Entwickler, die Produkte mit Agenten bauen, nicht nur mit einem einzelnen Agenten. Für sie ist es wohl gerade die beste Lerninvestition überhaupt: die CLI installieren, einen zwanzigzeiligen Agenten mit dem SDK schreiben, und ihm ein eigenes Tool geben. Wer das tut, versteht Claude Code besser als die meisten seiner Nutzer.

Wer heute nur einen produktiven Assistenten will, bleibt beim integrierten Harness und kommt zurück, wenn 1.0 die Guardrails liefert: pis Wert liegt im Verstehen und Kontrollieren, nicht im Sofortkomfort. Dazwischen gibt es einen risikofreien Mittelweg — Claude Code für die Arbeit behalten, und pi als Testbank nutzen, um zu verstehen, was das Haupttool verbirgt.

Die Kernbotschaft: Harnesses sind keine Blackboxen mehr. Die Teile liegen auf dem Tisch, dokumentiert, unter MIT-Lizenz. Beeindruckt oder nervt beim nächsten Mal ein Agent, weiß man genau, welches Teil man sich ansehen muss.