Gollama: a TUI for cleaning up an Ollama model directory
Go manage your Ollama models
At a glance
- What is it?
- Gollama is a Go terminal interface for listing, inspecting, copying, deleting and pushing Ollama models, plus a vRAM estimator. The README is candid that the author now rarely uses Ollama, and that changes what you are adopting.
- Who is it for?
- Adopt Gollama if you already run Ollama on macOS or Linux, keep a model directory you want to prune, and prefer a keyboard-driven TUI over ollama list piped through shell scripts. Do not adopt it as a replacement for llama.cpp or llama-swap serving, and do not assume the LM Studio workflow still exists, because the README states it was removed in v2.0.1.
- 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 57 days ago.
- What is it written in?
- Mainly Go, 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 is model directory rot, not model serving
Ollama accumulates models. Pulls leave tags you no longer use, quantisation variants of the same family sit side by side, and the only built-in view is a flat list. Gollama targets that specific mess. The README describes it as a macOS and Linux tool for managing Ollama models, with the author noting he finds it useful "especially for cleaning up old models". That sentence is the honest scope statement. This is not an inference server, not a proxy, and not a runtime.
The audience follows from that. If you run Ollama locally and want to see size, quantisation level, model family and modified date in one sortable screen, Gollama is aimed at you. If you serve models to other machines, or you need request routing, the tool does nothing for that. It sits in front of the Ollama API and the models directory, and its useful actions are destructive or organisational: delete, copy, rename, push, edit the Modelfile.
What the TUI actually does with a keystroke
The interface is a single list of models with modal actions bound to keys. Space selects, Enter runs the model through Ollama, i inspects, t shows running models, D deletes, e edits the Modelfile, c copies, U unloads all models, p pulls an existing model, ctrl+p pulls a new one, P pushes, and q quits. Sorting is bound to single letters: n for name, s for size, m for modified, k for quantisation, f for family, B for parameter size. Rename is bound to r and the README marks it as work in progress, which is worth taking literally rather than treating as a normal feature.
The split between p and ctrl+p is the one design detail that suggests the author hit a real annoyance. Pulling an existing model and pulling a new model are different operations in practice, because re-pulling a model you already have can overwrite local configuration. The README lists ctrl+k as pull model and preserve user configuration, which names the second hazard explicitly. If you have hand-edited a Modelfile, that distinction matters more than any of the sorting keys.
Deletion is not a soft delete. D removes the model. There is no staging area described in the material, so the safety net is your own backups or the ability to pull the model again.
Running it without the TUI
The recommended install is go install github.com/sammcj/gollama/v2@latest. The README also documents a curl install script and a manual path: download the release archive, extract the binary, and move it somewhere on your PATH. The author states he does not recommend the curl method because it is harder to update, which is a reasonable position given that go install handles version resolution for you.
The CLI flags let you skip the interface entirely. gollama -l lists models and exits, which makes it scriptable. gollama -e my-model opens the Modelfile for editing. gollama -s takes a search term, and the README documents two operators: gollama -s 'my-model|my-other-model' returns models matching either term, while gollama -s 'my-model&instruct' returns models matching both. That is a small feature, but it is the kind of thing that decides whether a tool survives in a shell history.
Connection and path settings are exposed as flags: -h or --host for the Ollama API, -H as a shortcut for http://localhost:11434, and --ollama-dir for a custom models directory. Logging is controlled with --log or --log-level, accepting debug, info, warn and error. There is also --no-cleanup, which the README describes as not cleaning up broken symlinks. That flag tells you the default behaviour: Gollama removes broken symlinks in the models directory unless you tell it not to. If your model storage is on a removable volume or a network mount that is sometimes absent, that default deserves a second look before you run the tool against it.
The vRAM estimator is the most opinionated part
Gollama ships a memory estimation mode that goes beyond listing. The --vram flag accepts an Ollama model such as llama3.1:8b-instruct-q6_K or qwen2:14b-q4_0, and the README also shows a HuggingFace identifier in the form NousResearch/Hermes-2-Theta-Llama-3-8B. Two further flags shape the calculation: --fits takes available memory in GB (the example is 6 for 6GB), and --vram-to-nth or --context sets the maximum context length to analyze, with examples written as 32k or 128k. A --quant flag overrides the quantisation level, with examples like Q4_0 and Q5_K_M.
That set of inputs is the interesting part, because it shows the estimate is context-length dependent rather than a single number per model. Anyone who has tried to fit a model onto a laptop GPU knows the failure mode: the weights fit, the KV cache does not, and the model spills or refuses to load at the context length you wanted. A flag that takes both available memory and a target context is aimed squarely at that.
The README calls this a comprehensive feature and describes the output as approximate. Treat it as a planning aid. The material does not document the formula, the overhead assumptions, or how it accounts for KV cache quantisation, so you cannot audit the number from the README alone. Verify it against one model you actually run before you use it to decide a purchase.
LM Studio linking is gone, and the README says why
The clearest limitation is stated by the author rather than discovered by a user. A dated update in the README records that as of the v2.0.1 release, LM Studio linking is no longer available. The reasoning given is maintenance cost: changes in both upstream applications and the variety of local user configurations meant more time than the feature was worth, for something the author rarely used.
The same note is more uncomfortable for prospective adopters. The author writes that he is "simply not dog-fooding with Ollama enough", that development has slowed, and that he has mostly moved to llama.cpp with llama-swap for model serving, LM Studio on his laptop, and oMLX for MLX models. The README also carries the phrase "Has some cool bugs" in the feature list, and elsewhere says the project is in active development with bugs and missing features.
Read together, those statements describe a tool in maintenance rather than growth. The release history is consistent with that: v2.0.5 in June 2026, then v2.0.4 and v2.0.3 both in December 2025. You are adopting a working utility whose author has publicly reduced his own use of the underlying platform. That does not make it broken. It does mean you should not expect the Ollama feature surface to be chased quickly, and any new Ollama capability may go unrepresented for a while.
Where Gollama is the wrong tool, and what to use instead
Gollama assumes Ollama is your runtime. The author's own stated alternative is llama.cpp with llama-swap, which he describes as well maintained, easier to configure, with many more features and significantly better performance. That is a different architecture, not a different front end: llama-swap manages model serving and swapping, and llama.cpp runs the weights directly, so there is no Ollama daemon and no Ollama model store for Gollama to read. If you move to that stack, Gollama has nothing to manage. The same applies to LM Studio, which the author uses for local serving with MLX and GGUF models.
The practical consequence is a fork in the road. Choose Ollama and Gollama gives you a keyboard-driven view of the model directory with delete, copy, push and Modelfile editing in one place. Choose llama.cpp with llama-swap and you get a serving setup the author now prefers, but you give up the TUI and the vRAM estimator, and you take on configuration yourself. There is no version of Gollama that manages a llama.cpp model directory.
A second wrong-tool case is automation. The TUI is interactive, and the CLI surface is narrow: listing, searching, editing, unloading, version, host and directory flags, plus vRAM estimation. If you need scheduled pruning with policy rules, Gollama is not that. The -l and -s flags give you parseable output to build on, but the deletion logic lives behind the TUI.
Licence, maintenance and what to check first
Gollama is MIT licensed. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are retained. This is a description of the licence text, not legal advice, and if you are redistributing a modified binary you should read the full MIT terms yourself.
Maintenance cost is the real question, and the README answers it indirectly. The author states development has slowed and that he no longer dog-foods with Ollama. For a single-binary Go tool installed via go install, the upgrade path is trivial: run the same go install command with @latest and you get the newest tagged release, and the tags show a cadence of roughly two releases in the second half of 2025 followed by one in mid 2026. The cost is not in upgrading. It is in the possibility that an Ollama change breaks an action such as pull, push or Modelfile editing and the fix arrives slowly.
Before committing, check three things against your own setup. Confirm the binary connects to your Ollama API, using -H for the default local endpoint or -h for a remote host, since the README treats the host as configurable and your daemon may not be on the default port. Confirm what lives in your models directory before you let the default broken-symlink cleanup run, or pass --no-cleanup on the first invocation. And run --vram against one model you have already loaded, comparing the estimate with the memory you actually see, because the README describes the output as approximate and does not document the calculation.
Editorial conclusion
Adopt Gollama if you already run Ollama on macOS or Linux, keep a model directory you want to prune, and prefer a keyboard-driven TUI over ollama list piped through shell scripts. Do not adopt it as a replacement for llama.cpp or llama-swap serving, and do not assume the LM Studio workflow still exists, because the README states it was removed in v2.0.1. Before installing, verify two things: that go install github.com/sammcj/gollama/v2@latest resolves to a binary that talks to your Ollama API host, and that the --vram estimate for one model you actually run matches the memory you observe when that model is loaded.
Community notes