Llama-macOS: a menu bar wrapper around llama.cpp's server
A cosy home for your LLMs.
At a glance
- What is it?
- Llama is a MIT-licensed Swift menu bar app that starts llama.cpp's server on localhost:9931 and manages GGUF models in the Hugging Face cache. It is a convenience layer, not a new inference engine, and its weakest point is the network exposure switch.
- Who is it for?
- Adopt Llama if you want llama.cpp's server running on a Mac without hand-writing launch commands, and you are comfortable editing ~/.config/llama/models.user.ini when the generated settings are wrong. Do not adopt it if you need authentication on a shared network, if your models live outside the Hugging Face cache, or if you want a GUI with per-conversation control.
- 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 1 day ago.
- What is it written in?
- Mainly Swift, 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 Llama fills between llama.cpp and a chat window
llama.cpp ships a server binary that speaks an OpenAI-compatible API. Running it on a Mac means deciding which GGUF to load, choosing a context size and KV cache type that fit your unified memory, remembering the flags, and keeping the process alive. Llama's contribution is to automate exactly that sequence. The README describes it as a macOS menu bar app for running local LLMs, and the feature list is explicit about the intended audience: people who want models to load when requested and unload when idle so they do not occupy memory between uses. That is a desktop-user concern, not a server-operator concern. If you already run llama-server under launchd with a fixed model and a known port, this app adds a second process manager you do not need. If you periodically want a local model available to an editor or a coding agent without thinking about flags, the app is aimed at you.
What actually happens when you start the app
The mechanism is a local HTTP server. According to the README, starting Llama runs a server at http://localhost:9931/v1. The app checks whether llama.cpp is installed and uses it if so; otherwise it installs a prebuilt binary for your Mac. Models already installed through llama.cpp appear in the app automatically. Models load on request and unload when idle. Custom settings are generated into a file called models.ini on every launch, which means anything you write there is overwritten, and the app reads a separate models.user.ini that it merges on top. That two-file split is the most interesting design decision in the project: the generated file is derived state, the user file is the only durable place for your edits. The README also states that a section for a model the app did not find is passed through as-is, which is how you point at weights or a draft model from another repository. So the app is not strictly a model manager. It is a config merger that happens to install models.
Installing it and pointing at your own weights
Installation is one Homebrew command: brew install --cask llama-app, or a download from the Releases page. Once running, the README gives two curl examples. To list installed models: curl http://localhost:9931/v1/models. To send a message, a POST to http://localhost:9931/v1/chat/completions with a JSON body containing a model field such as ggml-org/gpt-oss-20b-GGUF:MXFP4 and a messages array. The README points at the llama.cpp server docs for the complete API reference, which is worth noting: the app does not maintain its own API surface. For per-model overrides, edit ~/.config/llama/models.user.ini. The section header must match the app's own format, org/repo:QUANT, and keys are llama serve options without the leading dashes. The README's example sets temp = 0.7, ctx-size = 32768 and cache-type-k = q4_1. The README states that anything set in the user file wins over the app's own value, including settings derived from how much memory your Mac has, and that if a key cannot be applied the app ignores the file and the menu names the offending option. That failure behaviour is better than silently dropping your config.
The network switch is where the defaults stop protecting you
By default the server is reachable only from your Mac. The Settings option labelled Allow network access offers two modes. Tailscale binds the server to your Tailscale address, so other devices reach it from anywhere with Tailscale handling authentication and encryption, and the server stays invisible on the local network. The README recommends this for laptops and notes the option appears only when Tailscale is installed and signed in. The second mode, This network, binds all interfaces at 0.0.0.0. The README is blunt about the consequence: the server has no password, so it should be used only on a network you trust, and never together with agent mode on a network you do not own. That is the sharpest limitation in the project and it is stated by the maintainers, not inferred. There is a manual escape hatch for pinning an address the app does not offer, via defaults write app.llama.Llama exposeToNetwork -string "192.168.1.50", with a fallback to localhost when the address is not on any interface. If you need an API key, the README's experimental section shows how to append server flags the app does not expose: defaults write app.llama.Llama extraServerArgs -string "--api-key secret". Those arguments are appended after the app's own flags, so they only override where the server honours the later occurrence, and they take effect on the next server start.
Where the app gets in the way
Three constraints deserve attention before you commit. First, storage. The README describes models as living in the Hugging Face cache, shared with llama.cpp and other tools. That is a standard location, but it means the app's model list is tied to that cache and to what llama.cpp has registered. The README says models already installed via llama.cpp show up automatically; it does not describe an arbitrary folder-scanning mode, and the documented workaround for weights elsewhere is a pass-through section in models.user.ini with an explicit model = /path/to/file.gguf. Second, configuration is file-based and unversioned in the app's eyes. The app regenerates models.ini on every launch, so any edit there is lost by design. Third, memory-derived defaults are opaque. The README says models are auto-configured with optimal settings for your Mac and that user values override even settings derived from memory size, but it does not document the derivation. If a model loads with a context size you did not expect, your only lever is to state the value yourself in models.user.ini. The menu tells you which option failed when a key cannot be applied, which helps, but it does not tell you what the app would have chosen.
Compared with running llama-server directly
The honest alternative is llama.cpp's own server binary, which this app wraps. The difference is not inference quality, since the README states the app is built on llama.cpp and developed alongside it, and the API is documented in the llama.cpp server docs rather than in this repository. The difference is lifecycle management and defaults. Running llama-server yourself gives you an explicit command line, a process you control, and no generated config file that resets on launch. Llama gives you on-demand loading, idle unloading, one-click model installation from a curated list, and per-machine defaults you did not have to compute. The trade is transparency for convenience. A second alternative worth naming is any editor or chat client that bundles its own llama.cpp integration: those keep the model inside one application, whereas Llama's value is the shared endpoint at localhost:9931 that multiple tools can point at. If only one app will ever talk to your model, the wrapper earns less.
Maintenance, licence and what to check first
The project is MIT-licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive licence and imposes no copyleft obligation on your own code. It says nothing about the licences of the GGUF models you download, which are set by their publishers and vary. On maintenance, the repository is not archived and shows a steady release cadence through 2026, with 0.42.0 titled Reach your models from other devices, 0.41.0 titled Build an API request, and 0.40.0 titled Quick prompt. Those titles suggest active work on the network and API surfaces, which are the parts most likely to change under you. The upgrade cost is low if you stay on the Homebrew cask, since brew upgrade handles the app binary. It is higher if you have built habits around models.ini, because that file is regenerated; keep every customisation in models.user.ini and treat the generated file as read-only. Before installing, confirm the cask resolves on your macOS version, confirm nothing else holds port 9931, and confirm your existing models are visible in the app's list. If they are not, you are in pass-through territory and should write the section header and model path by hand.
Editorial conclusion
Adopt Llama if you want llama.cpp's server running on a Mac without hand-writing launch commands, and you are comfortable editing ~/.config/llama/models.user.ini when the generated settings are wrong. Do not adopt it if you need authentication on a shared network, if your models live outside the Hugging Face cache, or if you want a GUI with per-conversation control. Before installing, verify three things: that Homebrew resolves the llama-app cask on your macOS version, that port 9931 is free, and that the models you already have are visible in the app, since the README says only models installed through llama.cpp appear automatically.
Community notes