oterm: ein Terminal-Client, der Ollama und pydantic-ai-Anbieter in einer TUI bündelt

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

Die README beschreibt oterm als Terminal-Client für Ollama, OpenAI, Anthropic und jeden von pydantic-ai unterstützten Anbieter. Der Ausgangspunkt ist also nicht ein neues Modell oder eine neue Inferenz-Engine, sondern die Oberfläche davor. Wer lokal mit Ollama arbeitet, kennt den Ablauf: Modell pullen, im Terminal einen Prompt absetzen, Antwort lesen, Kontext geht verloren, nächster Aufruf beginnt bei null. oterm setzt an dieser Stelle an und führt Chat-Sitzungen als persistente Einheiten in einer TUI. Der Nutzerkreis, den das Projekt adressiert, sind Entwickler und Systemadministratoren, die bereits im Terminal leben und für Modellaufrufe nicht in einen Browser oder eine Desktop-Anwendung wechseln wollen. Das Thema machine-learning in den Repository-Metadaten ist insofern irreführend, als oterm selbst nichts trainiert und nichts inferiert. Es ist ein Client. Die eigentliche Arbeit leisten Ollama oder der jeweilige gehostete Anbieter.

pydantic-ai als Provider-Schicht: was sich hinter der Oberfläche ändert

Der Wechsel auf pydantic-ai ist in den Release Notes als breaking markiert, und das ist keine Formalie. Vorher war oterm ein Ollama-Client mit einem Anbieter. Jetzt ist es eine TUI über einer Abstraktionsschicht, die laut README OpenAI, Anthropic, Google AI und Vertex, Groq, Mistral, Cohere, AWS Bedrock, DeepSeek, Cerebras, Grok, Hugging Face sowie OpenAI-kompatible Endpunkte wie vLLM, LM Studio, llama.cpp, OpenRouter und LiteLLM anspricht. Der Mechanismus, den die Dokumentation nennt, ist denkbar einfach: Der passende API-Key wird gesetzt, danach erscheint der Anbieter im Dropdown für neue Chats. Das bedeutet, die Anbieterauswahl ist keine Konfigurationsdatei-Einstellung, die man vorab pflegen muss, sondern eine Folge des Zustands der Umgebung. Für Nutzer ist das bequem. Für reproduzierbare Setups ist es ein Risiko, weil die sichtbare Anbieterliste davon abhängt, welche Variablen in der Shell gesetzt sind. Wer denselben Chat auf zwei Rechnern unterschiedlich konfiguriert hat, sieht unterschiedliche Dropdowns, ohne dass oterm das explizit meldet.

Installation und der speak-Extra als optionale Abhängigkeit

Der in der README gezeigte Installationsweg ist ein Einzeiler: uvx oterm. Damit startet oterm ohne vorherige Installation im Projekt. Für die Sprachnachrichten-Funktion nennt die README einen anderen Aufruf: uvx "oterm[speak]", mit der Bedingung Python 3.11 oder neuer. Die Formulierung in den Release Notes ist an dieser Stelle präzise und lesenswert: Die Basisinstallation bleibt unberührt, und die Fähigkeit erscheint erst, wenn das Extra vorhanden ist. Das ist ein sauberes Muster für optionale Abhängigkeiten, weil piper nicht in jede Installation gezwungen wird. Wer die GLaDOS-Stimme nicht braucht, lädt sie nicht herunter. Die Kehrseite: Wer speak nutzt, muss die Python-Version prüfen, und die README verweist für vollständige Installationsmethoden, Konfiguration und Nutzung auf die externe Dokumentationsseite unter ggozad.github.io/oterm. Das Repository allein enthält also nicht die vollständige Konfigurationsreferenz. Wer die Anbieter-Konfiguration oder die MCP-Einrichtung verstehen will, muss die Dokumentationsseite aufrufen.

MCP-Konfiguration: Schema-Wechsel mit Migrationsbedarf

Die Release Notes bezeichnen die MCP-Änderung als breaking und beschreiben den konkreten Vorgang: Der mcpServers-Block übernimmt das Standard-Schema von pydantic-ai, das laut Notes mit Claude Desktop und Cursor kompatibel ist. Für bestehende Installationen heißt das, dass ein zuvor funktionierender Konfigurationsblock nach dem Upgrade nicht mehr gelesen wird, wenn er im alten Format vorliegt. Die Notes verweisen für die vollständigen Migrationshinweise auf docs/mcp. Wer oterm in einer Umgebung mit mehreren Nutzern oder in einem versionierten Dotfiles-Repository betreibt, muss diesen Block also aktiv anfassen. Die Kompatibilität mit Claude Desktop und Cursor ist dabei ein Argument für das neue Schema, weil dieselbe Server-Definition in mehreren Werkzeugen verwendet werden kann. Der Preis ist ein einmaliger, aber verpflichtender Konfigurationsschritt. Wer diesen Schritt überspringt, verliert die MCP-Anbindung, ohne dass oterm das zwingend als Fehler sichtbar machen muss.

Streaming, Token-Anzeige und die Grenzen der UI-Änderungen

Die Release Notes nennen mehrere UI-Änderungen: ein randloses Layout, ein automatisch wachsender Prompt, Inline-Token für Bildanhänge im Format [Image #N], einen einklappbaren Denkbereich und eine Token-Nutzungsanzeige in der Fußzeile anstelle eines Spinners. Die technisch interessanteste Änderung betrifft das Streaming: Markdown wird laut Notes beim Eintreffen von Deltas aktualisiert, statt bei jedem Token neu gerendert zu werden. Das ist eine Rechenlast-Verschiebung, die bei langen Antworten relevant wird, weil das Neu-Rendern des gesamten Markdown-Blocks pro Token quadratisch mit der Antwortlänge wächst. Die Notes behaupten, dass lange Antworten das Terminal nicht mehr verlangsamen, wenn sie wachsen. Ein Benchmark oder eine Messung wird nicht genannt. Wer diese Verbesserung überprüfen will, muss sie selbst nachmessen. Eine Einschränkung, die aus dem Material nicht auflösbar ist: Ob die Token-Nutzungsanzeige für alle Anbieter funktioniert oder nur für solche, die entsprechende Metadaten liefern, geht aus der README nicht hervor. Genau das ist aber der Punkt, an dem Multi-Provider-Clients in der Praxis auseinanderfallen, weil nicht jeder Anbieter dieselben Zähler zurückgibt.

Wann oterm das falsche Werkzeug ist

oterm ist ein interaktiver Client. Wer LLM-Aufrufe in eine Pipeline einbetten, Ergebnisse in eine Datenbank schreiben oder Prompts versioniert und reproduzierbar über viele Läufe ausführen will, braucht kein Terminal-Interface, sondern eine Bibliothek oder ein Skript. pydantic-ai selbst ist genau das und liegt ohnehin unter oterm. Ein zweiter Fall: Wer eine grafische Oberfläche mit Datei-Upload, Bildvorschau und mehreren Panes benötigt, wird mit einer TUI nicht glücklich. Die Inline-Token [Image #N] deuten darauf hin, dass Bildanhänge unterstützt werden, aber die Darstellung bleibt textbasiert. Drittens: Wer eine stabile, über Monate unveränderte Konfigurationsoberfläche braucht, ist bei einem Projekt falsch, das zwischen 0.23.0 und 0.24.0 zwei breaking changes gleichzeitig einführt, nämlich die Multi-Provider-Umstellung und das MCP-Schema. Das ist keine Kritik an der Entscheidung, sondern eine Aussage über den Reifegrad der Schnittstellen. Die Release-Kadenz deutet auf aktive Entwicklung hin, und aktive Entwicklung bedeutet bewegliche Konfigurationsformate.

Alternative: direkt gegen pydantic-ai oder Ollama arbeiten

Die naheliegende Alternative ist, pydantic-ai direkt zu verwenden, ohne oterm davor. Der Unterschied liegt nicht im Funktionsumfang der Modellaufrufe, sondern in der Sitzungsverwaltung. pydantic-ai liefert die Anbieter-Abstraktion, die Nachrichtenhistorie und die Werkzeugaufrufe. oterm liefert die persistente Chat-Sitzung, die Anbieterauswahl per Umgebungsvariable und die TUI. Wer nur einen einzelnen Prompt absetzen will, gewinnt durch oterm nichts. Wer regelmäßig zwischen Anbietern wechselt und den Verlauf behalten will, gewinnt die Sitzungsverwaltung, die er sonst selbst schreiben müsste. Die zweite Alternative ist Ollama direkt, also ohne pydantic-ai dazwischen. Das ist der schlankere Weg, wenn ausschließlich lokale Modelle verwendet werden. Der Unterschied: Ollama direkt spricht nur Ollama. oterm mit pydantic-ai spricht jeden Anbieter, für den pydantic-ai einen Adapter hat, und das ist der eigentliche Grund, warum der Wechsel in 0.24 vollzogen wurde.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

oterm steht unter der MIT-Lizenz. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange der Copyright-Hinweis und der Lizenztext beibehalten werden. Eine Copyleft-Klausel gibt es nicht, und es besteht keine Verpflichtung, Änderungen offenzulegen. Wer oterm in ein internes Werkzeug einbettet, muss die Lizenztexte von oterm und der mitgelieferten Abhängigkeiten prüfen, insbesondere piper, das laut Release Notes unter der Bezeichnung piper1-gpl geführt wird. Der Name legt eine GPL-Komponente nahe, und das ist relevant, sobald speak installiert wird. Ob das für die eigene Weitergabe Konsequenzen hat, hängt davon ab, wie piper eingebunden wird. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, wo vor einem Rollout nachgefragt werden sollte. Beim Wartungsaufwand ist die Release-Historie der belastbarste Anhaltspunkt: drei Releases zwischen Ende Juli und Anfang September 2026, mit zwei breaking changes in diesem Fenster. Wer oterm einführt, sollte die Konfiguration versionieren und die Migrationshinweise unter docs/mcp vor jedem Upgrade lesen. Die README verweist für Konfiguration und Nutzung ohnehin auf die externe Dokumentation, das Repository allein reicht als Referenz nicht aus.

Redaktionelles Fazit

Wer LLM-Sitzungen im Terminal führen will und bereits Ollama oder einen pydantic-ai-Anbieter nutzt, findet in oterm einen schlanken Einstieg über uvx oterm. Wer eine stabile, eingefrorene MCP-Konfiguration über mehrere Teams hinweg pflegt, sollte vor dem Upgrade auf 0.24 die Migrationshinweise unter docs/mcp lesen, weil der mcpServers-Block auf das pydantic-ai-Schema umgestellt wurde. Vor dem Produktiveinsatz zu prüfen: ob der eigene Anbieter in der Dropdown-Liste erscheint, sobald der passende API-Key gesetzt ist.

Offizielle Quellen

1. ggozad/oterm on GitHub
2. Issues
3. License: MIT
4. README
5. Releases