parllama: a Textual TUI that puts Ollama model management and multi-provider chat in one terminal window
TUI for Ollama and other LLM providers
At a glance
- What is it?
- parllama is a Python TUI built on Textual and Rich that wraps Ollama model operations and chat sessions, and can also talk to OpenAI, Anthropic, Groq, XAI, OpenRouter, Deepseek and LiteLLM. It is a good fit if you already live in a terminal and want one interface for pulling, quantizing and chatting; it is a poor fit if you need a stable scripting surface or a headless service.
- Who is it for?
- Adopt parllama if you run Ollama locally and want a terminal interface for pulling, copying, creating and quantizing models alongside chat, session export and custom prompt libraries. Skip it if you need a headless service, a stable Python API you can script against, or a non-interactive batch runner.
- 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 11 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 gap parllama fills between ollama CLI and a browser chat window
Ollama ships a command line for pulling and running models and an HTTP API for everything else. What it does not ship is a persistent, navigable interface for the operations you repeat: browse local models, check what is installed, pull a new one, copy or create a variant, delete what you no longer want, and then hold a conversation with the result. The README describes parllama as a TUI designed for easy management and use of Ollama based LLMs, and that phrasing is accurate about the scope. The model management features listed are pull, delete, copy, create and quantize, with what the README calls native Ollama support. Chat sits in the same process, so switching from managing a model to talking to it does not mean changing tools.
The audience is narrower than the feature list suggests. This is for someone who already has Ollama installed and running, is comfortable in a terminal, and wants session history and prompt libraries that survive between runs. The prerequisites section is explicit: install and run Ollama, and install Python 3.11 or newer. If you do not already run Ollama, parllama is not the thing that gets you there. It is also not a replacement for the Ollama HTTP API if you are building automation. It is an operator's console, not a library.
Textual, Rich and par_ai_core: the stack underneath the interface
The README states the application was built with Textual and Rich, plus a separate project by the same author called PAR AI Core. That third dependency is the interesting one. Provider abstraction, model caching and the chat plumbing most likely live in par_ai_core rather than in the TUI itself, which means the list of supported providers is bounded by what that core library implements. The README names Ollama, OpenAI, Anthropic, Groq, XAI, OpenRouter, Deepseek and LiteLLM. LiteLLM is itself a routing layer, so the practical reach is wider than eight names, but the README does not enumerate what sits behind it and I am not going to guess.
The architecture claims are async operations, a fully typed codebase, and hot reload in development mode. The async claim matters for a TUI because model pulls and long generations block otherwise. The README also describes per-provider model caching with configurable durations, which is the mechanism that keeps the model list responsive when a remote provider's catalogue endpoint is slow. None of this is verifiable from the README alone. What is verifiable is the dependency chain: Textual for the widget tree, Rich for rendering, par_ai_core for provider work. If you are evaluating long-term maintenance, that chain is what you are actually adopting.
Installing parllama with pipx, uv, or a dev checkout
The README offers three installation paths. The recommended one for a tool you just want to run is pipx, which the table of contents lists as its own section. For a managed Python environment, uv is the second option, and the README points at a Using uv section that also covers installing uv itself. The third path is dev mode, which is what you want if you intend to touch the code, and it is the only path where hot reload applies.
The runtime requirements are Ollama running somewhere reachable and Python 3.11 or newer. On Windows the README suggests Scoop as a way to install and manage Python, with the command given as scoop install python. There is a separate prerequisites section for Hugging Face model quantization, which is worth reading before you assume quantize just works: that path has dependencies beyond the base install. The README also documents running against a remote instance and running under Windows WSL, each with its own section, so the local-Ollama-on-localhost assumption is not baked in.
Configuration lives in a reference document linked from the README as docs/reference/configuration.md. Command line arguments and environment variables each get their own section, and there is a Secrets Vault subsection under environment variables for API keys. The README does not reproduce the key names in the material I have, so I cannot list them here. Read the configuration reference before wiring up cloud providers.
Custom prompts, Fabric patterns and the memory system
Three features distinguish parllama from a thin chat wrapper. The first is custom prompts: create, import and manage a library of system prompts and templates. The second is Fabric integration, which imports Fabric patterns as reusable prompts. If you already keep a Fabric pattern collection, that import path saves you from maintaining two prompt libraries.
The third is the memory system, described in the README as persistent user context that remembers information across all conversations with AI-powered updates. This is the feature I would think hardest about. Persistent context that updates itself means the model is deciding what to retain about you, and that retained state follows you into every subsequent conversation, including conversations with third-party providers if you have them enabled. The README frames this as a capability, not a risk. Whether that is acceptable depends on your threat model and on whether the memory store is local and inspectable. The README does not say where it is stored or how to clear it, so treat that as an open question to resolve before enabling it with cloud providers.
Template execution is the other feature that deserves scrutiny. The README calls it a secure code execution system with configurable command allowlists and customizable security patterns. Allowlists are a real control, and the README's framing suggests the default is restrictive. But an allowlist is only as good as its configuration, and a TUI that can execute commands is a different risk category from one that only chats. The README does not document the default allowlist contents in the material I have.
Session handling, vision models and slash commands in practice
Sessions can be saved, loaded, organized and exported, with export producing Markdown files. The README also lists auto-naming, where an LLM generates the session title. That is a small convenience with a real cost: naming a session requires a model call, which on a local model means a few seconds of GPU time for something you could type yourself. It is the kind of feature that is pleasant until you are on a slow machine.
Vision support is documented for models like LLaVA and GPT-4 Vision, with a quick start workflow for image chat in the table of contents. There are separate quick start sections for the Ollama chat workflow, the image chat workflow, and the OpenAI provider chat workflow, which is a sensible split because the setup differs. Slash commands provide what the README calls an extensive command system for quick actions and navigation, and there is a screen help document linked from the table of contents rather than inlined, so the actual command list lives outside the README.
Themes are dark and light modes plus custom themes via JSON configuration. Provider management covers enabling and disabling providers, managing API keys and configuring endpoints. That last part matters: if you want parllama to talk to a self-hosted OpenAI-compatible endpoint, endpoint configuration is the path, and the README treats it as a first-class setting rather than an environment variable hack.
Where parllama is the wrong tool
The clearest limitation is the one implied by the project's own description. A TUI is an interactive interface. There is no documented headless mode, no documented batch runner, and no documented Python API for scripting against parllama's own session or prompt stores. If your workflow is a shell script that runs a prompt across fifty inputs, parllama does not help, and the Ollama CLI or the HTTP API directly is the better answer. The README's export feature produces Markdown for documentation, not structured data for downstream processing.
The second limitation is provider depth. The README lists eight providers plus LiteLLM, but a TUI that supports many providers tends to support the common subset of their features. Provider-specific capabilities like tool calling, structured output schemas, or prompt caching are not mentioned anywhere in the README's feature list. If you depend on those, verify they exist before assuming parity with a provider's own SDK.
The third is the dependency surface. Textual, Rich and par_ai_core are all moving projects. Textual in particular has changed its API across versions. A TUI built on it inherits that churn, and the release cadence visible here (v0.9.0, v0.9.1 and v0.9.2 within roughly a week in July 2026) suggests active iteration rather than a frozen interface. Pinning a version is the sane move for anyone who needs reproducibility.
How parllama differs from Open WebUI and from the Ollama CLI
The obvious alternative for someone who wants model management plus chat is Open WebUI, which serves a browser interface backed by a server process. The difference in approach is architectural, not cosmetic. Open WebUI is a service: you run it, you reach it over HTTP, and multiple people or machines can use the same instance with accounts and shared state. parllama is a process you start in your own terminal, tied to your user account and your local files. If you want a shared team instance, parllama is the wrong shape entirely. If you want something that starts in under a second and never opens a port, parllama is the right one.
The other alternative is not installing anything: use the ollama CLI for model operations and a separate chat client, or curl against the API. That combination is more work to set up but has no dependency on Textual, Rich or par_ai_core, and it composes with shell tooling. The trade is session persistence and prompt libraries, which parllama provides and a shell pipeline does not. If you have never wanted persistent chat history in a terminal, the CLI is sufficient and you should not add a TUI layer.
A third comparison worth naming is against editor-integrated chat, since many people already have an LLM plugin inside their editor. Those tools are scoped to code in the current buffer. parllama is scoped to models and conversations, with image chat and Fabric patterns as first-class inputs. The overlap is smaller than it looks.
Licence, maintenance and what to check before pinning a version
parllama is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. That is the whole of the licence story as far as this material goes. I am not a lawyer and this is not legal advice; if you redistribute parllama or bundle it into a product, read the MIT text and your own organisation's policy. The README shows a Buy Me A Coffee link, which indicates the project is funded by its author rather than by a company with a support contract. That is a maintenance consideration, not a defect, but it does mean there is no commercial backstop if the author stops.
The maintenance cost is the dependency chain plus the configuration surface. Configuration lives in a separate reference document, environment variables and a secrets vault hold credentials, and template execution has an allowlist you are expected to tune. Each of those is a thing that can drift when you upgrade. The release history shows three releases in the v0.9.x line inside a month, so the upgrade path is real and not theoretical. Before pinning, read the CHANGELOG entries for v0.9.0 through v0.9.2 to see what changed, and check whether the configuration reference documents a migration path for settings that moved. If your environment requires reproducible installs, pin the version in your pipx or uv invocation rather than tracking latest.
Editorial conclusion
Adopt parllama if you run Ollama locally and want a terminal interface for pulling, copying, creating and quantizing models alongside chat, session export and custom prompt libraries. Skip it if you need a headless service, a stable Python API you can script against, or a non-interactive batch runner. Before committing, verify three things against your own machine: that your Ollama endpoint is reachable from the TUI (including the remote-instance path if Ollama runs on another host), that the template execution allowlist matches the commands you actually intend to run, and that you are comfortable with the memory system writing persistent user context across conversations. Check the CHANGELOG for the v0.9.0 through v0.9.2 window before pinning a version.
Community notes