llm-checker: Hardware-Aware Model Selection for Local Ollama Stacks
Advanced CLI tool that scans your hardware and tells you exactly which LLM or sLLM models you can run locally, with full Ollama integration.
At a glance
- What is it?
- llm-checker is a Node.js CLI that scans your machine, scores catalog models on Quality, Speed, Fit and Context, and prints ranked pull or run commands. The concept is sound and the packaging is unusual; the licence is the part to read before you deploy it anywhere.
- Who is it for?
- Adopt llm-checker if you run Ollama on a single known machine and want a ranked shortlist instead of guessing at tags, and if the NPDL-1.0 badge in the README is something your legal review can clear. Do not adopt it as a dependency of a commercial product, or on a fleet of heterogeneous hosts, until the licence file is read in full and the calibration fixtures are checked against your own hardware.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is tag soup, not model quality
Anyone who has run Ollama locally knows the failure mode. You pick a model by name recognition, pull several gigabytes over a slow connection, and discover that the quantization you chose does not fit in VRAM, or that it fits but generates tokens slowly enough to be unusable for interactive work. The tag space is the problem: the same base model ships at many quantization levels, and the right one depends on memory bandwidth, available VRAM, and whether you are willing to trade context length for speed. llm-checker targets that decision. It reads the machine, scores candidate models, and prints a ranked list with the commands to act on it. The README frames the audience directly: people asking what to run on this exact machine right now. That is a narrower and more useful question than which model is best in the abstract, and it is the question the tool is built around.
How the scoring and the registry actually fit together
The mechanism described in the README has three layers. First, hardware detection: Apple Silicon, NVIDIA CUDA, AMD ROCm, Intel Arc, plain CPU, plus integrated and dedicated inventory visibility, and multi-GPU. Second, a packaged multi-source registry, described as roughly 33,700 exact installable or downloadable artifacts from Hugging Face, Ollama and GPT4All, with per-source commands and runtime targeting, alongside a synced Ollama SQLite catalog of 200 or more models that can be refreshed on demand. Third, a scoring engine that rates every compatible model across four dimensions (Quality, Speed, Fit, Context) with weights that shift by use case, so a coding recommendation and a general chat recommendation do not rank the same way. Memory estimation uses a bytes-per-parameter formula that the README says is calibrated against real Ollama sizes, and there is a separate calibration workflow documented in docs/fixtures/calibration. The interesting design choice is that the registry is packaged rather than fetched live. That keeps the tool fast and offline-friendly, but it means the snapshot ages, which is why sync exists as a distinct command rather than something that happens implicitly.
Getting it running: the two-minute path and the optional dependency trap
Installation is a global npm install or a one-off npx invocation. The README's start-here flow is five commands: npm install -g llm-checker, then llm-checker hw-detect, then llm-checker recommend --category coding, then llm-checker sync to refresh catalog references, then llm-checker ai-run --category coding --prompt "Write a hello world in Python" which also reports tokens per second next to the output. If you have already calibrated routing, ai-run takes a --calibrated flag. One packaging detail deserves attention before you file a bug: sql.js is declared as an optional dependency, and the README states that database commands will report sql.js missing if your package manager skips optional dependencies. The stated fix is npm install -g llm-checker --include=optional. There is also a distribution trap. The scoped GitHub Packages mirror @pavelevich/llm-checker may lag, and the README explicitly tells you to install the unscoped llm-checker from npm for the newest builds, with npm uninstall -g @pavelevich/llm-checker, npm install -g llm-checker@latest, hash -r, llm-checker --version as the recovery sequence. Termux on Android is supported through pkg install ollama followed by the npm install. Node.js 18 or newer is required, with 18, 20 and 22 named as tested release lines.
Content filtering is on by default, and that is a deliberate constraint
Recommendation and auto-selection commands exclude models labelled uncensored, abliterated or heretic unless you pass --include-uncensored. The README notes that ai-run requires the same flag before it will select or launch one of those installed models. This is a filtering policy baked into the selection layer rather than a user preference you set once. For most people it changes nothing, since those tags are a small slice of any catalog. For anyone whose work involves running fine-tuned variants in that family, it means the tool will silently omit candidates until you remember the flag, and the omission will look like a ranking result rather than a filter. That is a defensible default, but it is worth knowing that the default is doing work you did not ask for.
Where this is the wrong tool
The calibration fixtures live in docs/fixtures/calibration, and the memory model is a bytes-per-parameter formula validated against Ollama sizes. A formula of that shape cannot see your driver version, your thermal headroom, or whether another process is holding VRAM. On a machine where the GPU is already busy, or on a laptop that throttles under sustained load, the Fit score is an estimate derived from nominal hardware, not a measurement of your session. There is also a structural limit: the tool is built around Ollama. The multi-source registry covers Hugging Face and GPT4All artifacts and emits per-source commands, but the ai-run path and the tokens-per-second metrics are Ollama integration. If your inference stack is vLLM, llama.cpp built from source, or a hosted endpoint, most of the value evaporates and you are left with a hardware report. And the registry is a snapshot. The README's own flow puts llm-checker sync before ai-run, which tells you the packaged catalog is a starting point, not a source of truth about what Ollama currently serves.
llmfit and the difference that matters
The README addresses llmfit directly and is honest that the two solve related but different problems. llm-checker's stated focus is hardware-aware model selection for local inference, and its typical output is ranked recommendations, compatibility scores, and pull or run commands. llmfit is described as LLM workflow support and model-fit evaluation from another angle, with a different optimization workflow and selection heuristics. The practical distinction is the shape of the answer. llm-checker returns a shortlist tied to one machine and one moment, with commands attached. A workflow-oriented tool returns something you plug into a pipeline. If your question is which tag to pull right now, the ranking-plus-command output is the more direct fit. If you are comparing fit across several candidate setups or wiring selection into automation, the README's own suggestion is to use both, and it does not claim llm-checker replaces that.
MCP, ModelVet, and what shipped recently
Version 3.8.1, released 2026-08-04, is titled ModelVet verification and MCP integration. The README credits ModelVet, created by Tetsuo AI, as the structural verification behind the verify command, ai-run --verify, structural policy validation, and the MCP verify_model tool, and states that llm-checker ships its WebAssembly integration under ModelVet's MIT license. There is a Claude Code MCP section linked from the top navigation, so the tool can be exposed to an MCP client rather than only driven from a shell. Version 3.7.0, from 2026-06-20, is the release that introduced the multi-source registry with the roughly 33,700 artifact snapshot and per-source commands. The repository was last pushed 2026-09-06 and is not archived. Treat the ModelVet credit as a dependency note rather than a feature list: the verification path is a third-party component wrapped in WebAssembly, and its behaviour is not documented in the material available here.
Licence status and the cost of keeping it current
The repository metadata reports NOASSERTION, and the README's badge points to NPDL-1.0. Those two signals do not agree, and the README's own licence link resolves to a LICENSE file whose contents are not reproduced in the material available here. That is the single largest open question about this project. NPDL is not a licence identifier most engineering teams will recognise, and a badge is not a licence text. Read LICENSE before you install this anywhere that matters, and treat any conclusion about redistribution or commercial use as unresolved until you have. On maintenance: the release cadence visible here is roughly two months between tagged versions, with 3.7.0 and 3.7.4 both landing on 2026-06-20 and 3.8.1 following in August. The upgrade cost is mostly catalog freshness rather than API churn. Every stale recommendation is fixed by running llm-checker sync, and every new machine is fixed by running llm-checker hw-detect again. Neither is expensive. The expensive part is the licence review, which is a one-time cost that gates everything else.
Editorial conclusion
Adopt llm-checker if you run Ollama on a single known machine and want a ranked shortlist instead of guessing at tags, and if the NPDL-1.0 badge in the README is something your legal review can clear. Do not adopt it as a dependency of a commercial product, or on a fleet of heterogeneous hosts, until the licence file is read in full and the calibration fixtures are checked against your own hardware. Verify three things first: the contents of LICENSE, whether sql.js installed (llm-checker sync and other database commands need it), and whether the packaged catalog is stale enough that you must run llm-checker sync before trusting any recommendation.
Community notes