**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.