llmfit is a Rust terminal tool that answers a narrow but persistent question for anyone running models locally: which of these will actually run well on this machine? It is MIT-licensed, published by Alex Jones, and has reached 33,588 stars and 2,099 forks in the six months since it went public on 15 February 2026. The current release is v1.1.10, shipped on 17 August 2026, with ten point releases since v1.1.0.

The workflow is a single command. llmfit opens an interactive TUI that detects the host's RAM, CPU, and GPU/VRAM, then scores every model in its catalog across four dimensions: memory fit, estimated speed, quality, and context. A classic CLI mode covers the scripted cases — llmfit fit prints the ranked table, llmfit recommend --json emits top picks for agents and scripts to consume, llmfit info "<model>" breaks down a single model, and llmfit doctor dumps a hardware-detection report for bug filing.

What distinguishes llmfit from a spec calculator is that it takes MoE architectures seriously. The README calls this out directly in its comparison to the alternative tool llm-checker, which treats every model as dense — meaning memory estimates for Mixtral- or DeepSeek-V3-class models reflect total parameter count rather than the much smaller active subset. For a field that has moved decisively toward sparse activation, getting that distinction right is the difference between a useful estimate and a misleading one. llmfit also handles multi-GPU setups and dynamic quantization selection, and it reads live state from local runtime providers: Ollama, llama.cpp, MLX, Docker Model Runner, and LM Studio.

The more interesting recent direction is measurement replacing estimation. Speed numbers come from a memory-bandwidth model grounded in runtime sampling and community measurements, and every estimate ships its inputs — llmfit info shows what a number assumes and the exact commands to verify it. On top of that, llmfit bench measures real tok/s and TTFT against a running provider, saves the run locally, and can open a PR contributing the result back to the project from inside the TUI, with no gh CLI and no third-party account. Merged submissions ship in the next release, so anyone on identical hardware sees a measured ✓ instead of an estimate before ever running a benchmark. This is a sensible answer to the credibility problem that dogs hardware-fit tools, though it does mean coverage quality is uneven — popular hardware accumulates real numbers, unusual configurations stay on estimates.

Distribution is unusually thorough for a project this young: scoop on Windows, Homebrew (both a project tap and homebrew-core) and MacPorts on macOS/Linux, an install script, uv tool install / uvx, a crates.io package, and a ghcr.io container that prints recommend JSON by default. Windows release binaries are Authenticode-signed through SignPath.io under a SignPath Foundation certificate, with signing restricted to artifacts built by the repository's own GitHub Actions pipeline — a supply-chain detail most tools at this scale skip. The README also states the privacy posture plainly: llmfit contacts external services only when the user invokes a feature that needs one, such as model downloads, provider queries, or the community leaderboard.

The main caveat is inherent to the category. A fit score is a prediction, and predictions drift as runtimes, quantization formats, and drivers change underneath them. llmfit's response — publish the assumptions, provide the verification command, and let measured data overwrite the guess — is about as honest as the genre allows, but users chasing an exact throughput figure should still run llmfit bench rather than trust the table.