llmfit: A Rust CLI That Matches LLMs to Your Actual Hardware

The problem: model size vs. your actual memory

Local LLM users face a recurring question: will this model fit in my RAM and VRAM? The answer is rarely obvious. A 70B-parameter model needs far more memory than a 7B one, but quantization, MoE architectures, and context length change the real footprint. llmfit addresses this by detecting your hardware and scoring models against it. The documentation says it detects RAM, CPU, GPU/VRAM, and backend, then scores every model in its catalog across memory fit, estimated speed, quality, and context. This is for people who run Ollama, llama.cpp, MLX, or similar runtimes and want to avoid downloading a model that will swap or crash. It is also for those who need a quick, scriptable answer, since the CLI can output JSON for agents and automation.

How llmfit estimates fit and speed

The core mechanism is a memory-bandwidth model grounded in runtime sampling and real community measurements, according to the README. Speed estimates are not random guesses; each estimate ships its inputs, so `llmfit info` shows exactly what a number assumes and how to verify it on your machine. This transparency is a strong point. The tool scores models across four dimensions: memory fit, estimated speed, quality, and context. For MoE architectures, the estimates use the active parameter subset rather than the total, which matters for models like Mixtral or DeepSeek-V3. The README notes that `llmfit fit` gives a table of all models ranked by fit, and `llmfit recommend --json` gives top picks for scripts. The TUI shows your detected specs at the top and every model scored. This design means the tool is only as good as its catalog and its estimation formulas, which is why the project added a benchmarking loop.

Getting it running: install options and first commands

Installation is straightforward across platforms. On Windows, `scoop install llmfit`. On macOS and Linux, you can use Homebrew with `brew install AlexsJones/llmfit/llmfit` for a prebuilt binary, or `brew install llmfit` from homebrew-core. There is also a quick install script: `curl -fsSL https://llmfit.axjns.dev/install.sh | sh`. For Python users, `uv tool install -U llmfit` or `uvx llmfit` works. Docker is supported too: `docker run ghcr.io/alexsjones/llmfit` prints JSON from the `recommend` command. After install, the basic usage is `llmfit` for the TUI, `llmfit fit` for a ranked table, `llmfit recommend --json` for JSON output, `llmfit info "<model>"` for a single model's analysis, and `llmfit bench` to measure real tok/s and TTFT against your running provider. The CLI also has a `doctor` command that produces a hardware detection report for bug reports.

The benchmark loop: replacing estimates with your own numbers

A notable feature is the community benchmark system. The README describes it as a way to contribute real numbers back to the project. You download a model, serve it, and measure real tok/s on your hardware. The results are saved locally first, then you can submit them as a PR directly from the TUI, with no `gh` CLI or third-party account needed. Once merged, your measurements replace estimates in the fit table for everyone on identical hardware. This turns the tool into a collaborative measurement database. The value is clear: if you have a common GPU, you might see a checked mark before you ever run a benchmark. But this also means the estimates are only as good as the community's submissions. For rare hardware, you will rely on the estimation model, which may be less accurate.

Limitations and when llmfit is the wrong tool

The biggest limitation is that llmfit is an estimator, not a runner. It does not pull or run models itself; it tells you what should run well. The README's alternative, llm-checker, actually runs models via Ollama to measure real performance. If you need actual benchmarks on your specific machine before committing to a model, llmfit's estimates might not be enough. Also, the catalog is finite. The project welcomes contributions of new models, but if you use a niche or very new model, it may not be listed. The tool also depends on accurate hardware detection, and while there is a `doctor` command for bug reports, detection may fail on unusual setups. For users who already have Ollama and want to test real-world performance directly, llm-checker might be a better fit, though it lacks MoE support, treating all models as dense.

Alternatives: llm-checker and the hands-on approach

The README explicitly names llm-checker as an alternative. It is a Node.js CLI tool with Ollama integration that can pull and benchmark models directly. The key difference is that llm-checker takes a hands-on approach by actually running models on your hardware via Ollama, rather than estimating from specs. This is useful if you have Ollama installed and want real-world performance numbers. However, llm-checker does not support MoE architectures, so memory estimates for models like Mixtral or DeepSeek-V3 will reflect total parameter count rather than the smaller active subset. That is a significant gap for users of MoE models. llmfit's estimation approach, while less direct, handles MoE correctly and can work without a runtime installed. The choice depends on whether you prefer measurement over estimation, and whether MoE support matters to you.

Maintenance, licensing, and what to verify first

The project is actively maintained, with recent releases in August 2026, and it is not archived. The license is MIT, which permits commercial use and modification with attribution. Windows binaries are code-signed via SignPath.io, which is a good sign for enterprise adoption. The release pipeline is automated, and contributions are welcome, especially new models. Before relying on llmfit, you should verify the estimate basis for your specific model and hardware using `llmfit info`. You should also run `llmfit bench` against your provider to get measured numbers, and consider submitting them back to improve the community data. The tool's accuracy depends on the catalog and the estimation formulas, which the benchmark loop is designed to refine. If you need a quick filter, llmfit is solid. If you need precise numbers on exotic hardware, you may need to benchmark manually.

Editorial conclusion

Adopt llmfit if you run local LLMs and want a quick, spec-based filter before downloading multi-gigabyte models, especially on multi-GPU or MoE setups where naive memory math fails. Skip it if you prefer hands-on benchmarking from the start, or if you need a GUI. Before relying on its scores, verify the estimate basis with `llmfit info` for your specific model and hardware, and run `llmfit bench` against your provider to replace estimates with measured tok/s. The tool's value depends on the accuracy of its catalog and speed model, which the community benchmark loop is designed to improve.

Official sources

1. Official README
2. Project repository
3. Release notes