Installation, Modelle & Konfiguration

Installation, Modelle und Konfiguration

0:00 Im ersten Modul haben wir eingeordnet, was Pi ist. Jetzt wird es praktisch. Ein Agent ist immer nur so gut wie die Umgebung, in der er startet — und diese Umgebung richten Sie in diesem Modul ein. Wir installieren Pi, binden Modelle an, legen Zugänge sauber ab und lernen die beiden Konfigurationsebenen kennen. Das klingt nach Fleißarbeit, entscheidet aber über Ihren Alltag: Wer hier saubere Standards setzt, muss nicht bei jedem Projektstart dieselben Fragen neu beantworten.

0:27 Am Ende haben Sie eine Umgebung, die Sie auf jeder neuen Maschine in wenigen Minuten wiederherstellen können.

Pi installieren und einrichten

0:34 Acht Kapitel liegen vor uns, und sie folgen einer bewussten Reihenfolge: erst installieren, dann Modelle anbinden, dann die Zugänge, dann die Feinsteuerung. Zwei Dinge lassen wir dabei ausdrücklich außen vor. Über Rechte und Vertrauen sprechen wir erst im nächsten Modul — dort gehört es hin, weil es eine eigene Denkweise braucht.

0:53 Und über das Schreiben von Code reden wir noch nicht. Hier geht es um das Fundament: Was liegt wo, was gilt wann, und woran erkennen Sie, dass es funktioniert? Diese vier Punkte sind der Fahrplan. Zuerst bringen wir Pi zum Laufen und stellen sicher, dass der Agent überhaupt handlungsfähig ist. Dann sortieren wir die Zugänge — und Sie werden sehen, dass es dafür mehrere Orte gibt, die einer klaren Rangfolge folgen.

1:17 Der dritte Punkt ist die bewusste Wahl von Modell und Denktiefe; das ist der Regler, an dem Sie täglich drehen. Und schließlich trennen wir zwei Konfigurationsebenen: Was gilt überall, und was gilt nur in diesem Projekt? Diese Trennung ersparen Sie sich später nicht.

Pi installieren und die Entwicklungsumgebung vorbereiten

1:33 Beginnen wir mit dem einfachsten Teil — und mit einem kleinen Detail, das leicht übersehen wird und trotzdem etwas über die Haltung des Projekts verrät. Installiert wird global über den Node-Paketmanager, gestartet wird immer im Verzeichnis des Projekts. Das Detail, das ich meinte, steckt in der Option „ignore-scripts".

1:52 Damit werden die Lifecycle-Skripte der Abhängigkeiten bei der Installation nicht ausgeführt — und die Dokumentation empfiehlt das ausdrücklich, weil Pi solche Skripte für eine normale Installation nicht braucht. Das ist ein kleiner Handgriff mit großer Wirkung: Sie verkleinern die Angriffsfläche schon beim Einrichten. Ein Werkzeug, das seine eigene Installation absichert, macht einen guten ersten Eindruck.

2:16 Vier Punkte zum Mitnehmen. Erstens: Der Agent arbeitet im aktuellen Verzeichnis — der Verzeichniswechsel gehört also zum Startvorgang und ist keine Formalie. Zweitens der schon erwähnte Sicherheitsgewinn beim Installieren. Drittens gibt es einen Installer über ein Shell-Skript; praktisch, aber Sie sollten wissen, dass Sie damit ein Skript aus dem Netz ausführen — eine Abwägung, die Sie bewusst treffen.

2:40 Und viertens brauchen Sie eine aktuelle Node-Umgebung; das Referenz-Image des Projekts nutzt Node 24. Für Windows, Termux und tmux gibt es eigene Doku-Seiten. Worauf es hier ankommt, ist die Abfolge, nicht die Schreibweise. Eine Zeile für die Installation, dann der Wechsel ins Projekt, dann der Start. Interessant sind die beiden letzten Zeilen: Sie zeigen, dass Pi nicht nur interaktiv läuft.

3:04 Mit einer einzigen Option bekommen Sie einen Durchlauf, der eine Frage beantwortet und sich wieder beendet — genau das, was man in Skripten braucht. Andere Paketmanager funktionieren ebenso. Und wenn Sie unter Windows arbeiten: dafür hat die Dokumentation eine eigene Seite, die sich lohnt. Die erste praktische Übung ist bewusst niedrigschwellig — und trotzdem aussagekräftig.

3:27 Sie starten Pi in einem eigenen Projekt und beurteilen den Startzustand: Ist ein Modell ausgewählt? Findet der Agent den Testbefehl? Das Erfolgskriterium ist deshalb nicht „es läuft", sondern: Die erste Antwort nennt Aufbau und Testbefehl des Projekts korrekt. Damit prüfen Sie gleich zwei Dinge auf einmal — Ihre Installation und die Aussagekraft des Agenten.

3:49 Wenn dabei etwas nicht stimmt, ist das kein Rückschlag, sondern der eigentliche Lerneffekt.

Unterstützte KI Modelle anbinden

3:55 Jetzt kommt der Teil, der Pi von vielen Alternativen unterscheidet: die Modellanbindung. Sie haben grundsätzlich zwei Wege — und die Entscheidung zwischen ihnen hat mit Kosten und mit Ihrer Vertragslage zu tun. Pi bringt keine eigenen Modelle mit, sondern setzt auf Ihre Zugänge. Entweder melden Sie sich mit einem bestehenden Abo an — der Login-Dialog unterstützt unter anderem Claude Pro und Max, ChatGPT Plus und Pro sowie GitHub Copilot — oder Sie hinterlegen einen API-Schlüssel des Anbieters.

4:25 Das Projekt spricht von über fünfzehn Providern und Hunderten Modellen. Der Vergleich: Pi ist der Kaffeevollautomat, der mit jeder Bohnensorte arbeitet, aber die Bohnen bringen Sie mit. Das ist ehrlicher als es klingt — Sie sehen jederzeit, was Ihr Zugang tatsächlich hergibt. Der Login-Weg deckt neben den großen Anbietern auch xAI, OpenRouter und Radius ab, und es gibt einen Gegenbefehl, der die Zugänge wieder entfernt.

4:50 Tokens erneuern sich selbst und liegen in einer Datei im persönlichen Pi-Verzeichnis — merken Sie sich diesen Ort, wir kommen im vierten Kapitel darauf zurück. Wer kein Abo nutzen will, kommt mit einer einzigen Umgebungsvariablen aus. Und was mich am meisten überzeugt: Sie können jederzeit auflisten, welche Modelle wirklich erreichbar sind, statt in Dokumentationen zu raten.

5:12 Der rote Faden dieser fünf Schritte ist Beweisführung. Anbinden ist schnell erledigt — entweder per Login-Dialog oder per Umgebungsvariable. Der eigentlich wichtige Schritt ist der dritte: das Auflisten der Modelle. Denn eine Konfiguration, die auf dem Papier stimmt, sagt noch nichts über die Erreichbarkeit. Dann wählen Sie für die Sitzung ein Modell — entweder über den Modellbefehl oder über das Tastenkürzel. Und zum Schluss stellen Sie eine kleine Aufgabe.

5:39 Erreichbarkeit ist erst dann bewiesen, wenn ein echter Aufruf durchgelaufen ist.

Cloud Modelle und lokale Modelle einordnen

5:45 Bleiben wir bei den Modellen, wechseln aber die Perspektive. Cloud oder lokal — diese Frage wird in vielen Teams gerade diskutiert, und sie ist seltener eine Leistungsfrage als eine Frage des Datenschutzes. Pi spricht beide Welten über dieselbe Oberfläche an. Für lokale Modelle gibt es zwei Wege: die eingebaute Anbindung an llama.cpp mit eigenem Verwaltungsbefehl, oder ein eigener Provider-Eintrag in einer Modelldatei — damit lassen sich Ollama, LM Studio oder vLLM einbinden.

6:13 Das Prinzip erinnert an einen Radioempfänger: Der Sender kann aus dem Netz kommen oder von der Festplatte, das Gerät und die Bedienung bleiben gleich. Für Sie heißt das: Die Entscheidung Cloud oder lokal müssen Sie nicht einmalig treffen, sondern können sie pro Aufgabe fällen. Vier Abwägungen. Lokal bleiben Code und Prompts auf Ihrer Maschine — für Projekte mit strengen Vorgaben oft der entscheidende Punkt.

6:38 Dafür sind Cloud-Modelle in der Regel deutlich leistungsfähiger; das sollte man nicht schönreden. Praktisch angenehm: Die Modelldatei wird bei jedem Aufruf des Modellbefehls neu gelesen, Sie können also während der Sitzung ergänzen, ohne neu zu starten. Und für eigene Endpunkte werden drei verbreitete Protokolle unterstützt, darunter das OpenAI-Format — was fast alle lokalen Laufzeiten mitbringen.

7:02 Diese Konfiguration wirkt technischer, als sie ist. Der Kern ist ein Provider-Block mit vier Angaben: wohin gesprochen wird, in welchem Protokoll, mit welchem Schlüssel — und eine Liste der Modelle. Bei lokalen Modellen ist der Schlüssel oft nur ein Platzhalter, weil niemand abrechnet. Wichtig ist die Fußnote: Verpflichtend ist einzig die Modellkennung, für alles andere gibt es Standardwerte, etwa ein Kontextfenster von 128.000 Tokens.

7:28 Sie können also klein anfangen und später ergänzen, wenn Sie Kosten oder Grenzen genauer abbilden wollen.

API Keys und Zugänge konfigurieren

7:35 Jetzt zu einem Thema, das im Alltag mehr Ärger macht als jedes andere in diesem Modul: Zugangsdaten. Nicht weil es kompliziert wäre, sondern weil es mehrere Orte gibt — und eine Rangfolge, die man kennen muss. Zugänge liegen entweder in einer Auth-Datei im persönlichen Pi-Verzeichnis oder in Umgebungsvariablen. Die Datei ist so abgesichert, dass nur Ihr Konto sie lesen darf.

7:57 Und jetzt kommt das Detail, das ich richtig gut finde: Das Schlüsselfeld akzeptiert nicht nur einen festen Wert, sondern auch eine Umgebungsvariable — oder ein Shell-Kommando, dessen Ausgabe verwendet wird. Damit holen Sie den Schlüssel direkt aus Ihrem Passwortmanager, und er steht nirgends im Klartext. Das ist die Art Kleinigkeit, die den Unterschied zwischen sauberer und riskanter Einrichtung macht.

8:21 Vier Punkte, die Sie sich merken sollten. Die Auth-Datei hat Vorrang vor Umgebungsvariablen — das ist die häufigste Ursache für vermeintlich falsche Schlüssel. Die Kommando-Variante hält den Schlüssel aus Dateien und aus der Shell-Historie heraus. Je Anbieter gibt es eine eigene Variable, die Namen sind in der Dokumentation tabelliert.

8:40 Und für Azure und Bedrock brauchen Sie zusätzlich eine Basis-Adresse beziehungsweise die üblichen AWS-Zugangswege — die weichen vom einfachen Schlüsselmuster ab. Die Logik dieser Tabelle ist eine Rangfolge, und sie erklärt fast alle Zugangsprobleme. Ganz oben steht die Angabe direkt beim Aufruf — sie überstimmt alles und ist für Sonderfälle gedacht. Dann kommt die Auth-Datei, die auch der Login-Dialog füllt.

9:04 Danach die Umgebungsvariable, typisch für Container und CI-Läufe. Und ganz unten die Schlüssel aus der Modelldatei für eigene Provider. Wenn also ein Schlüssel „nicht wirkt", ist die erste Frage nicht, ob er richtig ist, sondern ob weiter oben in dieser Liste noch ein anderer steht. Diese vier Fehler sehe ich regelmäßig. Der erste ist der eben besprochene Rangfolgen-Effekt.

9:27 Der zweite ist gefährlicher: die Auth-Datei in ein Backup oder in einen Container-Mount kopieren — damit reisen Ihre Zugänge mit, und die Dokumentation warnt davor ausdrücklich. Der dritte ist ein Kostenproblem: Abo-Login und API-Schlüssel parallel nutzen, ohne zu wissen, was gerade abgerechnet wird. Und der vierte ist der Klassiker: Schlüssel in einer Projektdatei ablegen, die anschließend im Repository landet. Prüfen Sie das lieber einmal zu oft.

Modelle passend zur Aufgabe auswählen

9:54 Sie haben jetzt Zugang zu vielen Modellen. Damit stellt sich eine neue Frage: Welches nehmen Sie eigentlich wofür? Meine These: Der bewusste Wechsel ist billiger als jeder lange Irrweg mit dem falschen Modell. Pi trennt Modellwahl und Werkzeug. Über Provider- und Modellangaben bestimmen Sie, wer arbeitet; mit einer Liste von Mustern legen Sie fest, zwischen welchen Modellen Sie per Tastenkürzel durchschalten können.

10:19 Besonders praktisch ist die Kurzschreibweise mit Doppelpunkt, die Modell und Denktiefe in einer Angabe verbindet. Das Bild dazu: Sie fahren nicht jede Strecke im gleichen Gang. Für den Stadtverkehr brauchen Sie keinen fünften — und für die Autobahn keinen ersten. Genau diese Beweglichkeit gewinnen Sie hier. Kurze Faktenfragen brauchen kein Spitzenmodell — das ist vor allem eine Kostenfrage, und die summiert sich.

10:44 Umbauten über viele Dateien profitieren umgekehrt von einem großen Kontextfenster. Ein Kniff, den ich empfehlen kann: Stellen Sie zwei Modellen dieselbe Frage, wenn Sie unsicher sind. Abweichende Antworten zeigen Ihnen genau die Stellen, an denen Sie selbst nachdenken müssen. Und behalten Sie im Kopf, dass die Modellauflistung eine Suchfunktion hat — so sehen Sie schnell, was Ihr Zugang wirklich bietet, samt Kostenangaben.

11:09 Worauf es hier ankommt: Es gibt vier Wege, und alle vier haben ihren Platz. Sie listen auf, was verfügbar ist. Sie sprechen ein Modell samt Denktiefe direkt an. Sie kombinieren Provider und Modell, wenn dieselbe Kennung mehrfach vorkommt. Und Sie hinterlegen zwei Muster, zwischen denen Sie im Betrieb hin- und herschalten.

11:28 Die letzte Variante ist im Alltag die unterschätzte: Wenn der Wechsel nur einen Tastendruck kostet, nutzen Sie ihn tatsächlich — statt aus Bequemlichkeit beim teuersten Modell zu bleiben.

Thinking Levels verstehen und einsetzen

11:39 Jetzt zu einem Regler, den es bei vielen Werkzeugen nicht so explizit gibt: der Denktiefe. Sie können einstellen, wie viel Nachdenken sich das Modell vor der Antwort erlaubt — und das kostet Zeit und Geld. Pi kennt sieben Stufen, von „aus" über minimal, niedrig, mittel, hoch und sehr hoch bis zum Maximum. Sie setzen die Stufe beim Aufruf, in der Kurzschreibweise am Modellnamen — oder dauerhaft als Standard in den Einstellungen.

12:06 Stellen Sie sich einen Kollegen vor, den Sie fragen: „Kurz überlegt oder gründlich durchgerechnet?" Beide Antworten sind legitim, sie kosten nur Unterschiedliches. Genau diese Frage stellen Sie hier explizit — und das ist ehrlicher als ein Werkzeug, das immer maximal denkt und Ihnen die Rechnung erst am Monatsende zeigt.

12:26 Höhere Stufen helfen nachweislich bei Entwurfsfragen, verschachtelter Fehlersuche und mehrstufigen Umbauten. Niedrige Stufen sind schneller und billiger für mechanische Arbeit — Umbenennen, Formatieren, Suchen. Wer es genau einstellen will, kann eigene Token-Budgets je Stufe hinterlegen. Und es gibt eine Option, die nur die Anzeige des Denkblocks ausschaltet, ohne das Denken selbst zu reduzieren; das ist nützlich, wenn Sie den Bildschirm ruhig halten wollen, aber die Qualität brauchen.

12:54 Verwechseln Sie diese beiden Dinge nicht. Das Prinzip hinter dieser Zuordnung ist ein Kosten-Nutzen-Verhältnis, kein Qualitätsranking. Mechanische Aufgaben gewinnen durch mehr Denken nichts — sie werden nur teurer. Normale Feature-Arbeit liegt gut in der Mitte. Bei Fehlersuche und Architekturfragen zahlt sich die höhere Stufe messbar aus, weil das Modell Alternativen abwägt statt die erste plausible Erklärung zu liefern.

13:18 Und die höchsten Stufen behalten Sie sich für die wirklich schwer eingrenzbaren Fälle vor. Meine Empfehlung: im Zweifel niedrig starten und gezielt erhöhen, nicht umgekehrt. Diese Übung liefert Ihnen eine eigene Erfahrungsgrundlage, statt meiner Empfehlung glauben zu müssen. Nehmen Sie eine echte Aufgabe und lassen Sie sie zweimal laufen — einmal mit niedriger, einmal mit hoher Denktiefe.

13:41 Notieren Sie drei Dinge: Unterschied im Ergebnis, Dauer und Tokenverbrauch. Das Lernziel ist ausdrücklich nicht, die höchste Stufe zur Gewohnheit zu machen, sondern den Effekt beurteilen zu können. Bei vielen Aufgaben werden Sie überrascht sein, wie klein der Unterschied ist — und genau das ist eine wertvolle Erkenntnis.

Globale Einstellungen versus Projektkonfiguration

14:00 Kommen wir zur Konfiguration selbst. Es gibt zwei Ebenen, und sie haben eine klare Vorfahrtsregel. Wer die kennt, spart sich lange Suchen nach dem Grund für unerwartetes Verhalten. Pi liest Einstellungen aus zwei Dateien: einer globalen im persönlichen Verzeichnis und einer projektlokalen im Projekt. Die Projektebene hat Vorrang.

14:21 Wichtig ist ein Detail: Verschachtelte Objekte werden zusammengeführt, nicht komplett ersetzt. Sie überschreiben also gezielt einzelne Werte, ohne den Rest zu verlieren. Das Bild: die globale Datei ist Ihre Grundeinstellung am Gerät, die Projektdatei ein Aufkleber am einzelnen Werkstück. Und weil die Projektdatei gewinnt, sollte klar sein: Sie gehört ins Review wie jede andere Datei im Repository.

14:46 Die Aufteilung ist im Grunde einfach. Persönliche Vorlieben — Farbschema, externer Editor — gehören global; sie interessieren Ihr Team nicht. Projektspezifisches wie Modellwahl, Werkzeugliste oder Compaction-Verhalten gehört ins Projekt. Beachten Sie aber: Projektdateien greifen erst, wenn Sie dem Projekt Vertrauen ausgesprochen haben — genau der Mechanismus, den wir im nächsten Modul auseinandernehmen.

15:11 Und wer die Projektdatei committet, teilt seine Vorgaben mit allen. Das ist ein Vorteil, wenn es Absicht ist, und ein Ärgernis, wenn es Zufall war. Worauf es in diesem Ausschnitt ankommt, ist nicht die Syntax, sondern die Auswahl der Schlüssel. Sie sehen einen Standardprovider, ein Standardmodell, eine Standarddenktiefe — die Antworten auf die Fragen, die Sie sonst jeden Morgen neu beantworten.

15:35 Dazu ein Compaction-Wert, der bestimmt, wie viel Verlauf ungekürzt bleibt, und eine Werkzeugliste. Die Fußzeile ist wichtig: Die Vertrauensvoreinstellung bleibt bewusst global — es wäre absurd, wenn ein Projekt selbst festlegen könnte, dass man ihm vertraut. Diese Trennung ist gut durchdacht.

Eine persönliche Pi Arbeitsumgebung aufbauen

15:53 Zum Abschluss fügen wir alles zusammen. Ziel dieses Kapitels ist eine Umgebung, die Sie nicht nur heute nutzen, sondern auf jeder neuen Maschine in Minuten wiederherstellen können. Drei Dateien tragen Ihre Umgebung: die Auth-Datei mit den Zugängen, die Modelldatei mit dem Katalog und die Einstellungsdatei mit dem Verhalten.

16:12 Dazu kommen Kleinigkeiten, die den Alltag angenehm machen: ein Farbschema, ein externer Editor für längere Prompts, ein ruhiger Startbildschirm. Denken Sie an die Werkstatt eines Handwerkers: Das Werkzeug ist überall dasselbe, aber die Anordnung ist persönlich — und genau die macht schnell. Wenn Sie diese drei Dateien sichern, nehmen Sie Ihre Arbeitsweise mit, nicht nur das Programm.

16:34 Reproduzierbarkeit ist der eigentliche Gewinn: neue Maschine, gleiche Umgebung, kein Nachdenken. Der externe Editor ist eine dieser unauffälligen Hilfen — längere Prompts schreibt man einfach lieber im gewohnten Werkzeug als in einer Terminalzeile. Farbschema und ruhiger Start klingen nach Kosmetik, entscheiden aber darüber, ob Sie die Oberfläche gern benutzen.

16:55 Und der wichtigste Punkt: Klare Standards ersparen Ihnen bei jedem Start dieselben Entscheidungen. Wer täglich zwei Entscheidungen weniger treffen muss, arbeitet messbar ruhiger. Der rote Faden dieser Schritte ist: von außen nach innen, vom Nachweis zur Bequemlichkeit. Erst der Zugang, geprüft durch echte Auflistung. Dann die Standards für Modell und Denktiefe, damit jeder Start sofort arbeitsfähig ist. Danach die Oberfläche nach Geschmack.

17:22 Erst dann kommen die Projektabweichungen — denn ohne solide Grundlage weiß man nicht, wovon man überhaupt abweicht. Und der letzte Schritt ist der ehrlichste: die Umgebung in einem zweiten Projekt gegenprüfen. Erst dort zeigt sich, ob Sie global und projektlokal richtig getrennt haben.

Umgebung steht

17:40 Halten wir fest: Installiert wird global, gestartet wird immer im Projekt. Ihre Zugänge liegen in der Auth-Datei, Ihr Modellkatalog in der Modelldatei, Ihr Verhalten in den Einstellungen — mit klarer Vorfahrt für die Projektebene. Und Modell wie Denktiefe sind bewusste Entscheidungen je Aufgabe, keine Einstellungen fürs Leben. Damit ist die Umgebung fertig.

18:01 Was jetzt noch fehlt, ist die unangenehmste und wichtigste Frage überhaupt: Was darf dieser Agent eigentlich tun? Genau damit beginnt Modul drei.