A better first question than which model is best
Local model advice often begins with model quality and ends with an unpleasant memory error. llmfit reverses the order. It inspects RAM, CPU cores, GPU identity, VRAM, backend, and multi-GPU layout, then asks which model and quantization make sense on that actual machine. Results are ranked for general use, coding, reasoning, chat, multimodal work, or embeddings.
The default terminal interface shows fit, estimated speed, quality, and context together. Classic commands expose the same data as tables or JSON. You can inspect one model, simulate different hardware, cap the intended context, or ask what hardware a specific model requires. A REST service makes the analysis available to schedulers, while the source includes a standard-input MCP server and an OpenClaw advisor skill for agents. This breadth is useful because model choice is rarely only an interactive desktop question.
The estimates are unusually inspectable
The project does not present its ranking as magic. It embeds a catalog sourced from Hugging Face, identifies mixture-of-experts architectures, and tries quantizations from higher quality to more compressed until one fits. Memory scoring considers the model and context, with a second attempt at half context when necessary. Quality includes size, family reputation, quantization cost, use-case alignment, and curated family-level benchmark data.
Speed begins with a bandwidth model. For a recognized GPU, llmfit divides memory bandwidth by model size and applies an efficiency factor plus runtime adjustments. Its documentation names the default factor, explains the fallback constants for unknown hardware, and lets users tune assumptions. llmfit info exposes the inputs behind a number. That transparency is the project's strongest editorial feature: a prediction can be challenged instead of accepted as a mysterious score.
Predictions remain predictions. Prompt processing, cache length, runtime kernels, offload policy, model architecture, background load, and quantization implementation all affect observed performance. The right use is to eliminate obviously unsuitable downloads and produce a shortlist, not to promise an exact token rate.
It closes the loop with real measurements
The benchmarking workflow makes that limitation manageable. llmfit can discover models served through Ollama, llama.cpp, MLX, or vLLM, run three inference passes, and record token generation speed plus time to first token. Local results replace estimates on your machine and can calibrate other dense models on the same hardware.
Sharing is optional. When enabled, the tool uses GitHub's device flow or an environment token, forks the repository, writes result files, and opens or updates a pull request. Merged measurements ship with later releases, so an identical hardware profile can receive a community number before running its own test. The documented trust order puts personal results first, then matching community data, then external medians, then the formula. That hierarchy is sensible.
There is one operational distinction to understand. llmfit can download GGUF files and can launch an installed llama-cli or llama-server, but it is not a universal inference engine. Benchmarking requires a live provider, and Ollama, LM Studio, MLX, Docker Model Runner, and vLLM keep their own installation and serving responsibilities. Think of llmfit as the selection and verification layer across runtimes.
Hardware detection has real edge cases
Platform coverage is broad: Linux, Windows, Intel Mac, Apple Silicon, and CPU-only operation are documented. NVIDIA detection uses nvidia-smi, AMD uses rocm-smi, Intel relies on sysfs or lspci, and Apple unified memory comes from system_profiler. Overrides for VRAM, RAM, and core count let users model another machine or correct a failed probe.
The open issue tracker shows why verification matters. One current report demonstrates that the discrete-GPU path grades against total VRAM while CPU paths use available RAM. On the reporter's occupied 24 GB card, a model needing nearly the full card was labeled marginal even though roughly 1 GB was free. Until that is resolved, close GPU workloads or check free memory yourself before trusting a fit label.
Another open request covers Ryzen AI NPUs and hybrid runtimes that llmfit does not support. The platform guide also says Android GPU detection normally fails, with memory overrides serving only as a scoring simulation. Provider name mapping is maintained data, not a universal truth: an open Gemma issue shows an installed Ollama tag that does not map back to its catalog entry. None of these faults ruins the core workflow, but each marks a boundary around the automatic result.
Healthy, fast-moving, and worth installing
The repository was pushed on August 14, 2026, and version 1.1.9 was released on August 9. That release fixed Windows hardware detection, model ID mapping, mixture-of-experts speed estimation, plan consistency, and an unwanted dashboard side effect. Issue and pull-request activity continued through August 16, including hardware fixtures, community measurements, dependency work, and new model formats. The open count of 69 combines issues and pull requests.
Documentation is excellent. Separate guides explain the scoring formulas, platform boundaries, provider behavior, automation interface, custom models, and full benchmarking journey. More than 31,000 stars and nearly 2,000 forks are backed by visible maintenance rather than popularity alone.
Install llmfit before shopping for a local model or new GPU. Use it to compare plausible combinations, inspect why they ranked, and choose what to test. Then run the actual model at your intended context and concurrency. That final check is not a criticism of llmfit. It is exactly the workflow the project is designed to make cheaper.