gptme: ein Agent im Terminal, der Dateien schreibt und Befehle ausführt

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

Ein Assistent, der Code schreibt, aber die Ausgabe nicht selbst ausführen kann, verlagert die Arbeit nur. gptme setzt genau dort an: laut README ist es ein persönlicher Agent, der überall dort läuft, wo ein Terminal läuft, also auf dem Laptop, in ssh-Sitzungen, in tmux, auf headless Servern und in CI-Pipelines. Der Agent bekommt Shell, Python, Web und Vision als Werkzeuge und arbeitet damit direkt im Dateisystem und auf der Kommandozeile.

Die Zielgruppe ist im README benannt: das Projekt versteht sich als guter Coding-Agent, aber allgemein genug für andere Wissensarbeit. Praktisch heißt das: Menschen, die bereits im Terminal leben, ihre Daten und Modelle aber nicht an einen Anbieter binden wollen. Das README nennt ausdrücklich Anthropic, OpenAI, Google, xAI, DeepSeek und OpenRouter sowie den lokalen Betrieb über llama.cpp. Wer einen Agenten für persistente, wiederkehrende Aufgaben sucht, findet zusätzlich das Repository gptme-agent-template, das laut README als Vorlage für dauerhaft laufende Agenten dient.

Bemerkenswert an der Einordnung ist der Zeitpunkt. Das README datiert den ersten Commit auf März 2023 und bezeichnet gptme als einen der ersten Agent-CLIs. Diese zeitliche Tiefe ist kein Qualitätsnachweis, aber sie erklärt, warum das Projekt inzwischen eine Plugin-Schicht, ein Lessons-System und eine Server-API besitzt, statt nur ein Chat-Frontend zu sein.

Werkzeuge, Plugins und die Grenze zwischen Kern und Ökosystem

Der Kern von gptme ist der Werkzeugkasten. Das README listet Shell, Python, Web und Vision als mitgelieferte Fähigkeiten, dazu kam laut News-Einträgen im März 2025 ein tmux-Tool und im August 2025 ein morph-Tool für schnelle Edits. Diese Werkzeuge sind der Grund, warum der Agent in einer tmux-Sitzung oder auf einem Server ohne grafische Oberfläche überhaupt sinnvoll arbeiten kann.

Erweiterbarkeit läuft über drei Schichten. Erstens Plugins, eingeführt laut Release-Notizen mit v0.30.0 im November 2025, zusammen mit Kontextkompression und einem Subagent-Planner-Modus. Zweitens das Lessons-System, das laut News-Eintrag von Oktober 2025 kontextuelle Hinweise an den Agenten liefert, ebenfalls mit v0.29.0 eingeführt. Drittens MCP und ACP als Integrationsschienen; MCP kam laut README mit v0.28.0 im August 2025, inklusive Discovery und dynamischem Laden nach v0.29.0.

Für die Bewertung ist wichtig, wo die Grenze verläuft. Der Kern liegt im Repository gptme/gptme unter MIT. Die Community-Plugins, darunter laut README Werkzeuge für Twitter/X, einen Discord-Bot, E-Mail und ein Multi-Agent-Konstrukt namens consortium, liegen im separaten Repository gptme-contrib. Wer diese Plugins einsetzt, muss deren Lizenzen getrennt prüfen; die MIT-Lizenz des Hauptprojekts erstreckt sich nicht automatisch darauf. Das ist keine Formalie, denn ein Plugin, das auf einen externen Dienst zugreift, bringt eigene Abhängigkeiten und eigene Bedingungen mit.

Installation und der erste Lauf

gptme wird als PyPI-Paket verteilt, der Paketname lautet gptme. Das README verlinkt auf eine Getting-Started-Seite unter gptme.org/docs/getting-started.html und auf eine Download-Seite; konkrete Installationsbefehle stehen im vorliegenden Material nicht, deshalb lässt sich hier kein Kommando sauber belegen. Wer die Installation plant, sollte diese Seite als erste Quelle nehmen, statt aus dem Repository-Namen auf einen Befehl zu schließen.

Belegbar ist dagegen der Zugang über die Oberfläche. Laut News-Eintrag von Juli 2026 gibt es zu v0.32.1 eine Desktop-App für Linux als AppImage sowie für macOS und Windows, jeweils mit Auto-Updates, herunterladbar über die Release-Seite. Wer den Agenten lieber im Browser steuert, findet mit gptme-webui ein separates Repository. Die CLI bleibt aber der Kern, und das README beschreibt sie als den Ort, an dem der Agent lebt.

Für den Modellzugang nennt das README die Provider Anthropic, OpenAI, Google, xAI, DeepSeek und OpenRouter sowie den lokalen Pfad über llama.cpp. Welche Konfigurationsschlüssel für welchen Provider nötig sind, geht aus dem vorliegenden Ausschnitt nicht hervor. Das ist eine echte Lücke für die Bewertung: Die Provider-Vielfalt ist ein Versprechen, die Zuordnung von Provider zu Konfiguration muss man in der Dokumentation nachschlagen.

Autonome Läufe, Guardrails und was das für den Betrieb bedeutet

Das README führt autonome Agenten als eigenen Abschnitt und verweist auf das Template gptme-agent-template, dessen Version 0.4 laut News-Eintrag autonome Laufschleifen und eine verbesserte Kontexterzeugung mitbringt. Als Referenzfall nennt das README den Agenten Bob, der laut Eintrag von Oktober 2025 mit GitHub-Überwachung begann und laut Eintrag von Januar 2026 ausgiebig als autonomer Agent gelaufen ist. Solche Angaben stammen aus der Projektdokumentation und sind keine unabhängige Messung.

Für den Betrieb relevanter sind die Guardrails, die das README als eigenen Abschnitt auflistet. Ein Agent, der Shell-Befehle ausführt und Dateien schreibt, braucht Grenzen, sonst ist der Radius eines Fehlers das gesamte Dateisystem des Nutzers. Wie diese Guardrails konkret greifen, ob über Bestätigungsdialoge, Pfadbeschränkungen oder eine Positivliste von Befehlen, geht aus dem vorliegenden Material nicht hervor. Genau diese Frage sollte man vor einem unbeaufsichtigten Lauf klären.

Hinzu kommt die Kostenfrage. Mit v0.31.0 im Dezember 2025 kamen laut README Background Jobs, ein Formular-Werkzeug, Cost Tracking und Content-Addressable Storage. Cost Tracking ist bei einem Agenten, der in einer Schleife läuft und dabei Werkzeugaufrufe produziert, kein Komfortmerkmal, sondern die Voraussetzung dafür, einen Lauf überhaupt zu genehmigen. Wer den Agenten gegen einen kostenpflichtigen Provider laufen lässt, sollte dieses Tracking vor dem ersten langen Lauf aktivieren.

Wann gptme das falsche Werkzeug ist

Der naheliegende Einwand gegen einen Terminal-Agenten ist die Umgebung. Wer in einer IDE mit grafischer Oberfläche arbeitet, für den ist ein Agent, der in tmux und ssh zu Hause ist, kein Vorteil, sondern ein Umweg. Das README positioniert gptme ausdrücklich als Alternative zu Claude Code, Codex, Cursor und Warp, aber diese Werkzeuge sind nicht deckungsgleich. Cursor und Warp sind an einen Editor beziehungsweise ein Terminalprodukt gebunden; gptme ist an ein Terminal gebunden, aber nicht an ein bestimmtes.

Der zweite Einwand betrifft die Qualität der Ergebnisse. Ein Agent, der Shell-Befehle ausführt, kann einen falschen Befehl nicht nur falsch beantworten, sondern ausführen. Das README behandelt Guardrails als eigenes Thema, was die Autoren selbst als relevanten Punkt markieren. Wer keine Zeit hat, diese Grenzen zu konfigurieren und zu testen, sollte den Agenten nicht unbeaufsichtigt laufen lassen.

Der dritte Einwand ist die Modellabhängigkeit. Weil gptme provider-agnostisch ist, hängt die Qualität der Werkzeugaufrufe am gewählten Modell. Ein lokales Modell über llama.cpp mag datenschutzfreundlich sein, aber ob es mehrstufige Werkzeugketten zuverlässig plant, ist eine andere Frage. Das README macht dazu keine Angaben, und aus dem vorliegenden Material lässt sich keine Aussage darüber ableiten, welche Modelle welche Aufgaben bewältigen. Wer lokal fahren will, muss das selbst austesten.

Was gptme von Claude Code, Codex, Cursor und Warp unterscheidet

Die vier genannten Alternativen teilen einen gemeinsamen Zug: Sie kommen von einem Anbieter oder sind an dessen Produkt gebunden. Claude Code und Codex sind an die Modelle des jeweiligen Herstellers gekoppelt, Cursor an eine Editor-Umgebung, Warp an ein Terminalprodukt. gptme dreht das um: Der Agent ist das Produkt, das Modell ist austauschbar, und die Oberfläche ist ein Terminal, das man ohnehin schon benutzt.

Der zweite Unterschied ist die Erweiterbarkeit. Cursor und Warp erweitert man innerhalb der Regeln des jeweiligen Produkts. gptme setzt auf Plugins, ein Lessons-System und MCP, also auf Schichten, die außerhalb des Kerns liegen und von der Community im Repository gptme-contrib gepflegt werden. Das ist offener, verschiebt aber auch Verantwortung: Die Qualität eines Plugins ist nicht die Qualität des Kerns.

Der dritte Unterschied ist das Alter. Das README datiert den ersten Commit auf März 2023 und ordnet gptme damit in die Frühphase der Agent-CLIs ein. Diese Kontinuität erklärt die Breite der Funktionen, von MCP über Subagent-Planner bis zu Content-Addressable Storage. Sie erklärt aber nicht, ob die Funktionen für einen konkreten Anwendungsfall ausgereift sind. Wer zwischen gptme und einem herstellergebundenen Werkzeug wählt, wählt zwischen Anbieterunabhängigkeit und einem vorhersagbaren, von einem großen Team getragenen Funktionsumfang.

Wartung, Release-Kadenz und Lizenzfragen

Die Release-Liste im vorliegenden Material zeigt drei Einträge innerhalb von zwei Wochen: v0.33.1.dev20260903, v0.33.1.dev20260831 und v0.33.1.dev20260827. Alle drei tragen das Suffix dev und eine Datumsangabe im Versionsstring. Das ist ein Hinweis auf eine Entwicklungslinie, in der Zwischenstände veröffentlicht werden, nicht auf eine Reihe abgeschlossener Stabilisierungsreleases. Wer gptme produktiv einsetzt, muss mit häufigen Aktualisierungen rechnen und damit, dass sich Verhalten zwischen zwei Versionen ändern kann.

Dasselbe Muster zeigt die Funktionshistorie. Zwischen Oktober 2025 und Dezember 2025 kamen laut README das Lessons-System, MCP-Discovery, Token-Awareness, Background Jobs, ein Formular-Werkzeug, Cost Tracking und Content-Addressable Storage hinzu. Eine solche Dichte bedeutet, dass Dokumentation und Verhalten auseinanderlaufen können. Für die Wartung heißt das: Version pinnen, das Changelog unter gptme.org/docs/changelog.html verfolgen, und vor einem Upgrade prüfen, ob genutzte Plugins oder das Lessons-System betroffen sind.

Lizenzseitig ist der Kern klar: MIT. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung des Urheberrechtshinweises und des Lizenztextes. Was der Kern nicht abdeckt, sind die separaten Repositories, allen voran gptme-contrib mit seinen Plugins sowie gptme-webui, gptme-rag, gptme.vim und gptme-agent-template. Für diese ist aus dem vorliegenden Material keine Lizenzangabe ableitbar. Wer Plugins einbindet, muss die Lizenz jedes einzelnen Repositories prüfen, bevor er sie in einen kommerziellen Ablauf integriert. Ob eine bestimmte Kombination zulässig ist, lässt sich hier nicht beurteilen, und das ist auch keine Rechtsberatung.

Redaktionelles Fazit

Wer einen Agenten braucht, der in einer ssh-Sitzung, in tmux oder in einer CI-Pipeline läuft und dessen Werkzeugkasten nicht auf Coding beschränkt ist, findet in gptme einen Kandidaten, der sich ohne Cloud-Zwang betreiben lässt. Wer eine stabile, langsam getaktete Plattform mit herstellergebundener Toolchain sucht, sollte sich die Release-Kadenz aus dem Changelog ansehen, bevor er produktiv geht. Vor dem Einsatz zu prüfen sind drei Dinge: ob das Modell hinter dem gewählten Provider die Tool-Aufrufe zuverlässig beherrscht, wie die Guardrails für Shell- und Dateioperationen konfiguriert sind und welche Lizenzen die optionalen Plugins aus gptme-contrib mitbringen.

Offizielle Quellen

1. gptme/gptme on GitHub
2. License: MIT
3. Project website
4. README
5. Releases