Pi Coding Agent einrichten: in 28 Minuten zum ersten Test

Pi Coding Agent macht die Umgebung des Modells anpassbar

Pi ist ein schlankes Agentengerüst: die Software, die ein Modell mit Dateien und Befehlen verbindet. Die passende Vorstellung ist eine Werkbank. Das gewählte Modell entscheidet, was zu tun ist; Pi stellt ihm die Werkzeuge dafür bereit.

Die vier standardmäßig aktivierten Tools decken den grundlegenden Arbeitsablauf ab:

Das Modell fordert einen Tool-Aufruf an, Pi führt ihn aus und gibt das Ergebnis an die Unterhaltung zurück. Dieser Ablauf kann sich wiederholen, bis die Aufgabe erledigt ist. Die vier genannten Tools sind standardmäßig aktiviert; sie bilden nicht die vollständige Liste aller integrierten Tools in 1.0. Referenz zu den Pi-Tools, Ablauf des Agenten.

Wer bereits Claude Code oder Codex nutzt, sollte Pi danach beurteilen, welche Arbeitsabläufe er selbst gestalten möchte. Meine Empfehlung: Pi ausprobieren, sobald es einen konkreten Anpassungswunsch gibt, etwa einen eigenen Befehl für Repository-Reviews oder einen wiederverwendbaren Migrations-Skill. Eine breitere Auswahl bietet der Überblick über Coding-Agenten mit freier Modellwahl.

Was Pi 1.0 an Terminal, Tool-Aufrufen und Anmeldung ändert

Mit Version 1.0.0 wird die Vollbildansicht zum Standard. Außerdem überarbeitet das Release den Codemode und die Anmeldung. Eine TUI ist eine Benutzeroberfläche, die direkt im Terminal dargestellt wird. Für die Einrichtung sind diese Änderungen relevant:

MCP verbindet den Agenten mit externen Tools. OAuth ist ein Anmeldeverfahren, das Zugriff gewährt, ohne dem Tool das eigene Passwort zu geben. Im Codemode kann das Modell Tool-Aufrufe in JavaScript zusammenstellen und ausgewählte Ergebnisse an die Unterhaltung zurückgeben. Die Einsparung bei den Prompt-Tokens gilt für diesen Modus. Sie verspricht keine um 40% niedrigere Rechnung für jede Aufgabe. Release-Hinweise zu Pi 1.0.0, Codemode-Referenz.

Dasselbe Release ergänzt die Bilderzeugung aus Codemode-Skripten, Radius unter /login und quietStartup: "header". Für die erste Programmieraufgabe können diese Funktionen zunächst beiseitebleiben. Release-Hinweise.

Pi einrichten und die erste Aufgabe in 28 Minuten abschließen

Als Ausgangspunkt eignen sich ein vertrautes Repository, ein funktionierender Testbefehl und Zugang zu einem unterstützten Modell. Der folgende Zeitplan ist ein Vorschlag: Wie lange Downloads, Anmeldung und Tests dauern, hängt von der jeweiligen Umgebung ab. Die Aufgabe sollte klein genug sein, um das Ergebnis noch vor Sitzungsende zu prüfen.

Minute 0 bis 5: installieren und das Projekt öffnen

Die Installation über npm setzt laut Projekt Node.js 22.19 oder neuer voraus. Der folgende Befehl legt Pi auf 1.0.0 fest, damit die Anleitung und die installierte Version zusammenpassen:

node --version
npm install -g --ignore-scripts @earendil-works/pi-coding-agent@1.0.0
pi --version
cd /path/to/project
pi --tui-mode regular

/path/to/project wird durch den eigenen Arbeitsordner ersetzt. pi --version sollte 1.0.0 ausgeben. Ein Start mit schlichtem pi verwendet die neue Vollbildansicht. Die offizielle Alternative für macOS/Linux lautet curl -fsSL https://pi.dev/install.sh | sh und installiert die aktuelle Version. Installationsdokumentation des Projekts, Schnellstart.

Minute 5 bis 10: das vorhandene Konto verbinden

In Pi zunächst /login ausführen, den Anbieter wählen und die angebotene Anmeldung abschließen. Anschließend mit /model ein verfügbares Modell auswählen. Der Anbieter stellt den Zugangsweg bereit; das Modell erzeugt die Antworten.

Pi dokumentiert sowohl die Anmeldung mit Anthropic-Abonnement als auch OpenAIs „Sign in with ChatGPT“. OpenAI beschreibt die Tarifnutzung als Autorisierung für berechtigte Anfragen, abhängig von der Berechtigung des Kontos. Ein API-Schlüssel führt dagegen zu einer gesonderten Abrechnung. OAuth-Anbieter in Pi, OpenAI-Dokumentation zur Anmeldung.

Die Pi-Website nennt Anthropic, OpenAI, Google, OpenRouter, Ollama und weitere Anbieter. Dass ein Anbieter unterstützt wird, bedeutet jedoch nicht, dass jedes seiner Modelle in jedem Konto verfügbar ist. Fehlt ein Modell, sollte zuerst die Anmeldung geprüft werden: /model zeigt Modelle an, für die nutzbare Zugangsdaten vorliegen. Mit Ctrl+S lässt sich im Auswahlmenü das Standardmodell speichern. Dokumentation zur Modellauswahl.

Für Ollama dient das Projektbeispiel für einen kompatiblen Endpunkt als Vorlage für ~/.pi/agent/models.json. Es verwendet http://localhost:11434/v1, den API-Typ openai-completions, den Platzhalterschlüssel ollama und eine Modell-ID, die von der eigenen Installation bereitgestellt wird. Beim Öffnen von /model wird die Datei neu geladen. Das ist der lokale Zugangsweg, um Pi ohne kostenpflichtiges Modellkonto auszuprobieren.

Minute 10 bis 13: Regeln für das Repository hinterlegen

Im Stammverzeichnis des Repositorys eine kurze AGENTS.md anlegen oder die vorhandene Datei ergänzen. Pi findet Anweisungen in ~/.pi/agent/, in übergeordneten Verzeichnissen und im aktuellen Verzeichnis. Änderungen während einer Sitzung werden mit /reload neu geladen. Konfigurationsdokumentation.

Die Anweisungen sollten zum tatsächlichen Repository passen. Ein Beispiel:

Use the existing test runner and neighboring test conventions.
Keep this task within the function and tests I name.
Do not add dependencies or change the public API.
Run the focused tests and report the exact command and result.
Leave commits and publishing to me.

Ist der passende Befehl für die betroffenen Tests bekannt, gehört er ebenfalls in die Datei. AGENTS.md gibt dem Modell Orientierung; sie setzt keine verbindlichen Zugriffsgrenzen durch.

Minute 13 bis 23: eine nützliche Änderung umsetzen

Geeignet ist eine vorhandene Hilfsfunktion, deren Verhalten bei leerer Eingabe definiert ist, für die aber noch ein Regressionstest fehlt. Die Funktion und einen benachbarten Test mit @ über Pis Dateiauswahl anhängen. Anschließend die Aufgabe so formulieren:

Ein Regressionstest schützt erwartetes Verhalten davor, später wieder zu brechen. Diese Aufgabe liefert einen konkreten Diff, ohne dass Pi die Anwendung neu entwerfen muss. Der Schnellstart beschreibt sowohl die Dateiauswahl mit @ als auch die anschließende Prüfung geänderter Dateien. Dokumentation zur ersten Aufgabe.

Minute 23 bis 28: das Ergebnis selbst prüfen

Den geänderten Test lesen und git diff prüfen, also die Übersicht der Dateiänderungen. Dabei kontrollieren, ob die Assertion tatsächlich das erwartete Verhalten abfragt. Anschließend den gezielten Testbefehl selbst ausführen. Erfolgreiche Tests stützen die Änderung; ob die Assertion sinnvoll ist und der Umfang stimmt, bleibt eine eigene Entscheidung.

Der erste Durchlauf ist gelungen, wenn der gewählte Anbieter funktioniert hat, Pi die beabsichtigte Änderung umgesetzt hat und der Diff nachvollziehbar ist. Weitere Anpassungen können bis zur nächsten Sitzung warten.

Pi kostet keine Lizenzgebühr – entscheidend ist die Modellnutzung

Pis MIT-Lizenz verursacht keine Softwaregebühr pro Nutzer. Ein Abonnementzugang verbraucht das vom Tarif bereitgestellte Kontingent; ein API-Schlüssel führt zur nutzungsabhängigen Rechnung des Anbieters. Bei einem lokalen Modell entstehen die Kosten für die eigene Hardware und deren Betrieb.

Ein konkretes API-Rechenbeispiel: OpenAI berechnet für GPT-6.1 Sol bei Standardverarbeitung mit kurzem Kontext $2 pro Million Eingabe-Tokens und $10 pro Million Ausgabe-Tokens. Tokens sind die Inhaltseinheiten, die für die Abrechnung gezählt werden. Offizielle OpenAI-Preise.

Angenommen, über alle Anfragen einer kleinen Aufgabe summiert sich die Nutzung wie folgt:

Das ist eine Beispielrechnung, keine gemessene Nutzung einer Aufgabe. Sie setzt Standardverarbeitung, höchstens 272,000 Eingabe-Tokens pro Anfrage sowie keine Cache-Schreibvorgänge oder separat berechneten Tools voraus. Für zwischengespeicherte Eingaben, Cache-Schreibvorgänge, längere Anfragen und andere Verarbeitungsstufen gelten andere Preise. Einhundert Aufgaben mit genau diesem Nutzungsmuster würden $30 an Modellgrundkosten verursachen. Preisdetails zu GPT-6.1 Sol.

Für die Budgetentscheidung zählt, ob die gewünschten Anpassungen ihren Wartungsaufwand rechtfertigen. Pi spart die Lizenzgebühr für das Agentengerüst. Modellnutzung, menschliche Prüfung und der Entwicklungsaufwand für den eigenen Arbeitsablauf bleiben bestehen.

Arbeitsabläufe mit dem passenden Mechanismus erweitern

Anweisungen eignen sich für Konventionen, Skills für wiederholbare Verfahren und Erweiterungen für ausführbares Verhalten.

Die SKILL.md eines Skills beginnt mit Name und Beschreibung. Mit /skill:name wird ein bestimmter Skill ausdrücklich geladen. Erweiterungen laufen im Pi-Prozess; ihr Code sollte deshalb vor dem Laden geprüft werden. Skills, Erweiterungen.

pi install ./local-package installiert ein lokal vorbereitetes Paket. Für ein veröffentlichtes Paket lautet der Befehl pi install npm:@scope/package@version, mit dessen tatsächlichem Namen und Versionsstand. Mit --local wird der Paketeintrag auf Projektebene in .pi/settings.json gespeichert. Werden Ressourcen während einer laufenden Sitzung geändert, lädt /reload sie neu. Paketdokumentation.

Für einen externen MCP-Dienst wird dessen Server konfiguriert; falls OAuth erforderlich ist, erfolgt die Anmeldung mit /mcp login <server>. Das eignet sich als spätere Ergänzung einer bereits funktionierenden Einrichtung. MCP-Dokumentation.

Sechs Aufgaben, geordnet nach praktischem Nutzen

Der beste Ausgangspunkt ist wiederkehrende Arbeit in einem vertrauten Repository. Die folgenden Abläufe sind Vorschläge; ihr Nutzen hängt von der Codebasis und einer sorgfältigen Prüfung ab.

1. Einen gemeldeten Fehler durch Regressionstests absichern. Ein Gründer, der eine Webanwendung mit Abomodell betreut, könnte Fehlerreproduktion, Implementierung und Tests anhängen. Pi soll daraus einen zunächst fehlschlagenden Test und eine gezielte Korrektur erstellen; danach werden die relevanten Prüfungen erneut ausgeführt. Der Nutzen liegt darin, den beobachteten Fehler dauerhaft in einem Test festzuhalten.
2. Eine Änderung vor dem Pull Request prüfen. Ein Entwickler könnte Pi den lokalen Diff und einen Review-Skill für das Repository geben und nach möglichen Fehlern mit Dateiverweisen und Begründung fragen. Wird ein konkretes Problem vor dem Review entdeckt, lässt sich möglicherweise eine Rückfragerunde vermeiden.
3. Einen klar abgegrenzten Anwendungsteil migrieren. Ein Maintainer könnte das Migrationsverfahren als Skill hinterlegen, auf ein Modul anwenden und dessen Prüfungen ausführen. Die mögliche Zeitersparnis entsteht durch die Wiederverwendung des Verfahrens für ähnliche Module, während jeder Diff weiterhin geprüft wird.
4. Ein unbekanntes Repository verstehen. Ein neues Teammitglied könnte Pi bitten, eine Anfrage vom Einstiegspunkt bis zur Speicherung nachzuverfolgen. Die Ergebnisse werden als Notizen mit Dateiverweisen und relevanten Prüfungsbefehlen festgehalten. Solche Notizen könnten wiederkehrende Fragen beim Einstieg reduzieren.
5. Ein kleines Wartungsskript schreiben. Wer veraltete Testdaten betreut, könnte Pi ein Skript entwerfen, an Beispieleingaben ausprobieren und seine Nutzung dokumentieren lassen. Ein geprüftes Skript könnte wiederholte manuelle Änderungen ersetzen.
6. Einen internen Entwicklungsablauf bauen. Ein technischer Leiter könnte einen eigenen Befehl und Skills als Paket bereitstellen. Alternativ lässt sich Pi über den Print-Modus für einzelne Befehle, per RPC zur Steuerung eines separaten Prozesses oder mit der SDK-Bibliothek zum Einbetten von Sitzungen in eine Anwendung integrieren. Der Nutzen liegt darin, den Agenten auf eine wiederkehrende Aufgabe zuzuschneiden; Integration und Betreuung liegen beim technischen Leiter. Integrationsschnittstellen.

Die stärkste Produktidee: ein KI-Code-Review für das eigene Repository

Ein Review-Paket für die Prüfung vor dem Merge bietet die klarste Chance: Die Aufgabe wiederholt sich, und mögliche Käufer kennen bereits die Kosten verzögerter Reviews. Ein kleines Entwicklungsteam könnte für ein gepflegtes Paket bezahlen, das seine eigenen Konventionen prüft und nachvollziehbare Belege für Reviewer liefert.

Die Nachfrageprüfung ergab 1,300 geschätzte monatliche Google-Suchanfragen in den USA für „ai code review“. CodeRabbit Essentials liefert einen Preisanker: $24 pro Entwickler und Monat bei jährlicher Abrechnung oder $30 bei monatlicher Abrechnung. Das zeigt Interesse an der Aufgabe und eine bereits bestehende kostenpflichtige Produktkategorie. Eine Nachfrage nach einem Pi-Paket ist damit noch nicht belegt. Suchvolumen: DataForSEO-Keyword-Übersicht, geprüft am 3. Oktober 2026. CodeRabbit-Preise.

Die kleinste verkaufbare Version könnte einen Review-Skill, einen Befehl zum Zusammenstellen des lokalen Diffs, Prüfungen nach den Vorgaben des Repositorys und einen Bericht mit Dateiverweisen enthalten. Die Bereitstellung sollte anfangs lokal erfolgen. Die Herausforderung ist die Abgrenzung: Ein allgemeiner Prompt ist leicht zu kopieren, und ein Pi-Paket braucht eigene Wartung, Zugriffskontrollen und Support. Verkauft wird die Qualität der Repository-Prüfungen samt ihrer laufenden Pflege.

Ein Startpaket für Teams ist die zweite Chance. Ein Entwicklungsleiter könnte Einrichtung und Wartung einer einheitlichen Anbieterkonfiguration, AGENTS.md, gemeinsamer Skills und einer kleinen Auswahl freigegebener Erweiterungen einkaufen. Die Nachfrageprüfung ergab 1,600 geschätzte monatliche Suchanfragen in den USA für „open source ai coding assistant“, gemessen von DataForSEO am selben Datum. Als erste Version kämen ein Paket und ein Einführungsverfahren für die Repositorys eines Teams infrage. Die Einschränkung: Suchinteresse beweist keine Zahlungsbereitschaft für die Installation. Der dauerhafte Wert muss aus der Pflege des Teamablaufs entstehen.

Wann Pi nicht zum Team passt

Wer Freigabeschritte, Isolation und standardisierte Arbeitsabläufe als betreutes Produkt erwartet, sollte ein verwaltetes Tool wählen. Pis Tools arbeiten mit den Berechtigungen des Prozesses, der Pi startet. Die Vertrauenseinstellungen für Projekte steuern, welche Projektressourcen geladen werden; Tool-Aufrufe werden dadurch nicht in einer Sandbox eingeschlossen. Ein Arbeitsordner hindert Befehle nicht daran, andere zugängliche Pfade zu erreichen. Sicherheitsmodell von Pi.

Erweiterungen können Bestätigungsabläufe oder einen Schutz für bestimmte Pfade ergänzen; ein Container kann auf Betriebssystemebene eine Grenze ziehen. Diese Entscheidungen bringen Implementierungs- und Wartungsaufwand für das Team mit sich. Auch die JavaScript-Sandbox des Codemode verändert die Berechtigungen der aufgerufenen Tools nicht. Möglichkeiten der Erweiterungen, Codemode.

Integrierte Unteragenten und einen Planungsmodus lässt Pi ebenfalls aus seinem Kern heraus. Meine Einschätzung: Das ist ein guter Kompromiss für Entwickler, die eine kleine Basis selbst gestalten möchten. Für ein Team, das diese Entscheidungen jemand anderem überlassen will, passt er weniger gut. Entwurfsentscheidungen des Projekts.

Am Montag bekommt Pi eine klar begrenzte Fehlerbehebung oder Testaufgabe in einem selbst betreuten Repository. Diff und Testergebnis aufbewahren und anschließend entscheiden, welcher wiederkehrende Ablauf einen Skill verdient. Für einen individuell entwickelten Teamablauf ist die Entwicklung von KI-Agenten der passende Einstieg.