AlexsJones/llmfit

The central problem llmfit solves is embarrassingly common: you find a model you want to run, download several gigabytes, and discover it either won't load or crawls. llmfit inverts that sequence. It detects your RAM, CPU, GPU, and VRAM first, then scores every model in its catalog across four dimensions — memory fit, estimated speed, quality, and context length — before you touch a download button.

The speed estimates deserve scrutiny, and the README invites it. They come from a memory-bandwidth model grounded in runtime sampling and community measurements, and crucially, every estimate ships its inputs. Running llmfit info on any model shows exactly what assumptions produced the number and how to verify them on your own hardware. That's a meaningful commitment: most tools in this space present estimates as facts and offer no audit trail.

The benchmark contribution loop is the most interesting recent addition. You can measure real tokens-per-second and time-to-first-token against a running local provider, then submit those results as a pull request directly from the TUI — no gh CLI, no third-party account required. Merged submissions ship in the next release, so anyone on identical hardware gets measured results rather than estimates. The README marks these with a ✓ to distinguish them from modeled projections. It's a lightweight crowdsourcing mechanism that improves the tool's accuracy without requiring a centralized service.

Runtime provider support covers Ollama, llama.cpp, MLX, Docker Model Runner, and LM Studio. Multi-GPU setups and Mixture-of-Experts architectures are handled explicitly — the README notes this as a gap in at least one named alternative, which treats all models as dense and therefore overestimates memory requirements for sparse models like Mixtral or DeepSeek-V3.

The tool ships as a Rust binary with an interactive TUI as the default interface and a CLI mode for scripts and agents. The recommend --json output path is clearly designed for programmatic consumption — useful if you're building something that needs to select a model based on available hardware without human intervention.

Installation is covered across Scoop, Homebrew, MacPorts, a curl script, uv/pip, and Docker. The Python packaging path is a pragmatic choice for reaching developers who don't want to think about Rust toolchains.

The privacy stance is stated plainly: no data leaves the machine unless the user explicitly triggers a feature that requires it. For a tool that reads hardware specs and contacts external services for leaderboard data and downloads, that's worth stating and the README does.