Swama: an MLX inference runtime in Swift, with a menu bar app and an OpenAI-compatible server
High-performance MLX-based LLM inference engine for macOS with native Swift implementation
At a glance
- What is it?
- Swama wraps Apple's MLX Swift bindings in a CLI, a macOS menu bar app and an OpenAI-compatible HTTP surface. It is a macOS-only tool for people who want local LLM, VLM and ASR inference without a Python stack, and its model alias table is the most opinionated part of the design.
- Who is it for?
- Adopt Swama if you are on Apple Silicon with macOS 15 or later, you want local inference driven from Swift or from an OpenAI-shaped HTTP client, and you are comfortable with the alias table deciding which quantised weights you get. Do not adopt it if you need Linux, CUDA, or a server you can run in a container, because the README lists macOS 15.0 and Apple Silicon as hard requirements.
- 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 problem Swama targets: local inference without a Python environment
Running a quantised model on a Mac usually means installing a Python environment, pulling a separate inference package, and keeping that stack in sync with the model weights. Swama removes that layer. The README describes it as a machine learning runtime written in pure Swift, built on Apple's MLX framework, and distributed as a Homebrew formula, a .dmg, and a source build. The audience is narrow and clearly stated: macOS 15.0 or later on Apple Silicon, with Xcode 16.0+ and Swift 6.2+ if you compile it yourself. There is no Linux target and no CUDA path. If your inference runs on a rented GPU box, this project is not addressing your problem. If your inference runs on the laptop in front of you, the pitch is that you install one binary and type one command.
Three artifacts, one core: SwamaKit, the CLI and the menu bar app
The README splits the project into SwamaKit, described as the core framework library holding all business logic, the Swama CLI, and Swama.app, the menu bar application with a graphical interface and background services. That split matters when you decide how to consume it. The CLI is the automation surface: it manages models and runs inference from a shell. The app is the interactive surface, and it also installs the CLI. The README instructs you to open Swama from the menu bar and click "Install Command Line Tool..." to add the swama command to your PATH, which means the GUI is the supported route to a working CLI for non-developers. The Homebrew formula is the third route and skips the app entirely. Because SwamaKit is a library, a Swift application can in principle link the core directly, though the README does not document that API surface, so treat it as an internal boundary rather than a published interface.
Model aliases and auto-download: the part that shapes daily use
Swama does not ask you to paste repository identifiers. It ships an alias table, and the README's examples show both forms working: swama run qwen3 "Hello, AI" and swama run mlx-community/Llama-3.2-1B-Instruct-4bit "Hello, how are you?". The aliases map to specific mlx-community or lmstudio-community repositories at specific quantisations. qwen3 resolves to mlx-community/Qwen3-8B-4bit at 4.3 GB and is labelled the default. llama3.2 resolves to the 3B Instruct 4-bit build at 1.7 GB, while llama3.2-1b is the 1B build at 876.3 MB and is described as fastest. Larger entries include qwen3-235b at 123.2 GB and qwen3.5-397b-a17b at roughly 220 GB. Those sizes are the README's own figures and they are the practical constraint: the alias table quietly encodes a recommendation about which quantisation you should run, and you inherit it unless you pass a full model name instead. Auto-download means the first invocation of an alias fetches weights before it answers, so a command that looks instant on a warm cache is a long download on a cold one. The README states that models are cached for future use and that swama list shows what you already have, which is the command to run before you assume an alias is local.
Getting it running: Homebrew, the .dmg, and the source build
The shortest path in the README is brew install swama. The second path is downloading Swama.dmg from the releases page, dragging Swama.app into Applications, and launching it. The README warns that macOS may show a security prompt on first launch and tells you to use System Preferences > Security & Privacy > General and click "Open Anyway", or to right-click the app and choose Open. The third path is a source build, and the README's commands are specific: git clone the repository, cd swama, run swift build -c release, then mv .build/release/swama .build/release/swama-bin. The macOS app build is separate and needs Xcode: cd ../swama-macos/Swama followed by xcodebuild -project Swama.xcodeproj -scheme Swama -configuration Release. Note the rename step in the CLI build. It is in the README, so it is presumably required by the layout, but the README does not explain why, and a reader following it blindly will end up with a binary named swama-bin rather than swama. Once installed, the documented surface is swama run for inference, with -i /path/to/image.jpg for image input, and swama list for cache inspection.
The OpenAI-compatible endpoints and what tool calling implies
Swama exposes /v1/chat/completions, /v1/embeddings, /v1/audio/transcriptions and, marked experimental in the README, /v1/audio/speech. Tool calling is listed alongside the chat completions endpoint. The value of this shape is that existing clients which speak the OpenAI wire format can be pointed at a local port instead of a hosted service, with no client rewrite. Two caveats follow from the material. First, the README labels only the speech synthesis endpoint as experimental, which suggests the others are considered stable, but it does not publish a compatibility matrix, so how closely the request and response schemas track the upstream specification is not something the README answers. Second, tool calling is claimed as a feature without a documented example of the request format or the model support matrix, so if your application depends on function calling, that is the first thing to probe against a real model rather than assume from the feature list.
Multimodal and audio coverage, and where the README stops
The feature list separates text and image input, local audio transcription powered by Qwen3-ASR and other MLX ASR models, and embedding generation for semantic search and RAG. The alias tables mirror that split: a VLM table with gemma3, qwen3-vl and the qwen3.5 family, and an audio table that the supplied README truncates mid-entry, so the full set of transcription aliases cannot be confirmed from this material. The claim that transcription needs no cloud is the interesting one, because it is the part of the stack that is hardest to replace with a hosted API on privacy grounds. What the README does not give is a per-model accuracy or latency figure for any of these paths, and it does not state which ASR models are supported beyond naming Qwen3-ASR. Anyone whose workload depends on transcription quality should treat the alias list as a starting point and evaluate the output themselves.
Limitations: platform lock-in, alias opacity and the streaming claim
The hard constraint is the platform. macOS 15.0 or later, Apple Silicon only, per the requirements section. There is no documented Linux build and no way to run this on a non-Apple accelerator, so a team standardising on containers or on a mixed fleet cannot use Swama as its single inference layer. The second limitation is the alias indirection. When you type swama run qwen3 you get a specific 4-bit build chosen by the project, and if a newer or differently quantised checkpoint appears upstream, the mapping is whatever the release ships. The README lists versions v2.4.0, v2.3.0 and v2.2.0 with roughly two-month gaps, so the alias table is maintained, but pinning behaviour means naming the full repository. Third, streaming is listed as a feature without a stated transport detail, and the README's own example, swama run qwen3 "Hello, AI", is a one-shot invocation. If you need token-by-token output in a client, verify it against the running server rather than the feature bullet.
How this compares with llama.cpp and Ollama
The obvious alternative on the same hardware is llama.cpp, usually through Ollama or LM Studio. The difference is the substrate rather than the feature list. llama.cpp implements its own inference kernels in C and C++, with GGUF as the weight format, and it runs on macOS, Linux and Windows across CPU, Metal, CUDA and ROCm backends. Swama does not implement kernels. It is a Swift runtime over Apple's MLX framework, and the README's model table points exclusively at MLX-format repositories, so the weights are not GGUF and are not interchangeable with a llama.cpp setup. That is the trade: Swama inherits MLX's optimisation for Apple Silicon and inherits its platform boundary at the same time. If you already have a GGUF library and a Linux box, moving to Swama means re-downloading weights in a different format and giving up the portability. If your entire deployment is Macs and you prefer Swift over Python tooling, the reverse argument holds.
Licence, releases and what maintenance costs you
Swama is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it is the same one used by many inference runtimes, so it is unlikely to be the deciding factor. It does not, on its own, settle the licence of the model weights you download through the alias table, which come from separate mlx-community and lmstudio-community repositories and carry their own terms. Check those separately. On maintenance, the release cadence visible here is three tagged versions between June and September 2026, with v2.4.0 and v2.3.0 two weeks apart, which suggests active work rather than a frozen snapshot. Upgrading via Homebrew or by replacing the .dmg is cheap; the cost sits in the alias table, because an upgrade can change which quantisation an alias resolves to. Pin the full model identifier in any script you care about. Building from source adds a Swift 6.2 and Xcode 16.0 toolchain requirement that you will have to keep current.
Editorial conclusion
Adopt Swama if you are on Apple Silicon with macOS 15 or later, you want local inference driven from Swift or from an OpenAI-shaped HTTP client, and you are comfortable with the alias table deciding which quantised weights you get. Do not adopt it if you need Linux, CUDA, or a server you can run in a container, because the README lists macOS 15.0 and Apple Silicon as hard requirements. Verify three things before committing: that the alias you intend to use points at the quantisation you actually want, that the /v1/audio/speech endpoint is still marked experimental in the release you install, and that the model you need is present in the alias tables rather than only on HuggingFace.
Community notes