oterm: a terminal chat client that speaks to Ollama and any pydantic-ai provider
the terminal client for LLMs
At a glance
- What is it?
- oterm is a Python TUI for talking to LLMs from a terminal. The README positions it as the client for Ollama plus OpenAI, Anthropic and anything pydantic-ai supports, and version 0.24.0 adds spoken replies through piper. The interesting question is not whether it looks good, but whether its provider layer and its MCP config schema survive contact with your existing setup.
- Who is it for?
- Adopt oterm if you already live in a terminal and want one interface across Ollama and hosted pydantic-ai providers, and if you are willing to re-check your mcpServers block against the pydantic-ai schema. Do not adopt it if you need a stable, non-breaking config surface across upgrades, or if you are looking for a GUI with visual diffs and file trees.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem oterm picks: one terminal, many model endpoints
Running local models through Ollama is easy. Running them alongside a hosted model, in the same session, with the same keybindings, is where terminal users usually end up writing shell aliases and switching tools. oterm's stated scope is that gap. The README describes it as the terminal client for Ollama, OpenAI, Anthropic, and any pydantic-ai-supported provider, and the 0.24.0 notes list Google (AI and Vertex), Groq, Mistral, Cohere, AWS Bedrock, DeepSeek, Cerebras, Grok, Hugging Face, and OpenAI-compatible endpoints such as vLLM, LM Studio, llama.cpp, OpenRouter and LiteLLM. That is a wide net for a single TUI. The audience is narrower than the provider list suggests: people who are comfortable in a terminal, who already have API keys in their environment, and who would rather type a slash command than click through a settings dialog. If your workflow depends on dragging files into a chat window, oterm is not aimed at you.
How the provider layer actually works
The architecture visible in the README is a thin terminal front end over pydantic-ai. oterm does not implement its own HTTP clients for each vendor. It hands provider selection to pydantic-ai and lets that library own the request format. The practical consequence is that adding a provider is not an oterm feature request, it is a pydantic-ai feature that oterm inherits. The README states that setting the matching API key makes the provider appear in the new-chat dropdown, which suggests provider discovery is driven by environment variables rather than a config file listing endpoints. That is a real design choice with real effects: your shell environment becomes part of your oterm configuration, and a key exported for another tool will silently add a provider to the dropdown. The release notes call the multi-provider change breaking, which tells you the previous versions were Ollama-only and that anything built around that assumption may need revisiting.
Install commands and the config keys you will touch
The README gives one command for a no-install run: `uvx oterm`. The spoken-response capability is a separate extra, installed as `uvx "oterm[speak]"`, and the README states it needs Python 3.11 or newer. The base install is described as untouched, and the capability appears only once the extra is present, so the speech dependency is genuinely optional rather than a default cost. The README points to ggozad.github.io/oterm for full install methods, configuration and usage, and does not enumerate config keys inline. The one config key named in the material is `mcpServers`, which the 0.24.0 notes say now adopts pydantic-ai's standard schema, described as compatible with Claude Desktop and Cursor. That is the key to check on upgrade. The README does not print a sample `mcpServers` block, so the full migration notes at ggozad.github.io/oterm/mcp/ are the only place to confirm the exact shape before editing your file.
The MCP schema change is the upgrade cost worth budgeting for
Two entries in the 0.24.0 notes are marked breaking: multi-provider support and the MCP rewrite. The MCP one is the more disruptive of the two because it changes a file you wrote by hand. Adopting pydantic-ai's schema means an existing `mcpServers` block written for an older oterm will not necessarily load, and the README explicitly directs readers to the migration notes rather than describing the old and new formats side by side. If you maintain MCP server definitions across several tools, the upside is that the same block can move between oterm, Claude Desktop and Cursor. The downside is that oterm's config is now tied to an external library's schema, so future pydantic-ai schema changes become your problem at upgrade time. That is a maintenance cost, not a bug, but it is the kind of cost that catches people who pin nothing and upgrade on a whim.
What the chat UI changes do and do not fix
The refreshed UI is described in concrete terms: a borderless accent-driven layout, an auto-growing prompt, inline `[Image #N]` attachment tokens, a collapsing thinking section, and a live token-usage footer replacing the spinner. The token-usage footer is the most useful of these for anyone watching cost on a hosted provider, since it puts a number on screen instead of an animation. The streaming change is described as updating Markdown as deltas arrive rather than re-rendering on every token, with the stated reason that long responses do not slow the terminal as they grow. That is a plausible fix for a real TUI problem, but the README offers no measurement, and I have not run it, so treat the speed claim as the project's description of intent rather than a verified figure. The collapsing thinking section matters only if your chosen model emits reasoning content; on models that do not, it is inert.
Spoken replies, the piper dependency, and the wrong-tool case
The `speak` capability reads replies aloud through piper as they stream, in what the README calls the GLaDOS voice. The README is clear that this is opt-in and that the base install is unaffected. The obvious limitation is the Python 3.11 floor, which is higher than some long-term-support distributions ship by default. The less obvious limitation is that speech is a poor fit for the way many terminal users work: piping output, grepping transcripts, or running oterm inside tmux on a remote host where audio goes nowhere useful. If your sessions are headless, the extra adds a dependency tree for a feature you cannot hear. The same reasoning applies more broadly: oterm is a chat client, not an agent runner or a batch tool. If you need to script a hundred prompts against a local model and collect the results, a TUI is the wrong shape, and the README does not present oterm as anything else.
How it differs from a plain Ollama CLI session
The nearest alternative for many readers is Ollama's own command line, which is already installed if you run local models. The difference in approach is the provider abstraction. Ollama's CLI talks to the Ollama daemon and nothing else; oterm routes through pydantic-ai, so the same chat surface can point at a local Ollama model or a hosted Anthropic model without changing tools. The second difference is the MCP layer. oterm ships an `mcpServers` configuration block, which the README says follows pydantic-ai's schema and is compatible with Claude Desktop and Cursor, so tool servers defined once can be reused. A bare Ollama session has no equivalent. If you only ever run local models and never touch MCP servers, the abstraction buys you little and costs you a dependency on both pydantic-ai and oterm's release cadence.
Licence and the practical upgrade picture
oterm is MIT licensed, and the README links to the LICENSE file without adding terms or exceptions. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; that is the standard reading, and I am not giving legal advice, so confirm with your own counsel if the distinction matters to your organisation. The release cadence visible in the material is roughly monthly, with 0.23.0 on 31 July 2026, 0.23.1 on 6 August, and 0.24.0 on 2 September. Two of the three most recent releases carry breaking changes, which is the number that should drive your upgrade policy. Pin a version, read the release notes before moving, and treat the `mcpServers` block as the first thing to verify after any upgrade. The project is not archived and the last push matches the 0.24.0 release date, so the maintenance signal is current rather than dormant.
Editorial conclusion
Adopt oterm if you already live in a terminal and want one interface across Ollama and hosted pydantic-ai providers, and if you are willing to re-check your mcpServers block against the pydantic-ai schema. Do not adopt it if you need a stable, non-breaking config surface across upgrades, or if you are looking for a GUI with visual diffs and file trees. Before installing, confirm your Python version (3.11 or newer for the speak extra), confirm which API keys are set in your environment, and read the migration notes at ggozad.github.io/oterm/mcp/ to see whether your existing MCP server definitions need rewriting.
Community notes