You've found a self-hosted LLM tool. The marketing site says it runs on 4 GB RAM and works offline. You download it, set it up, and hit a wall: it needs 16 GB, or it requires a network call at startup, or the docs contradict each other. You've lost hours to claims that weren't verified against reality.
This guide walks you through the five places to check—in order—so you trust the specs before you build.
Open the tool's GitHub repository. Look for a LICENSE or COPYING file in the root directory. Read it. This is the only source of truth for what you can and cannot do with the software. Marketing pages skip licenses or soften them. The file doesn't lie.
Common licenses you'll see: MIT (permissive, use anywhere), Apache 2.0 (permissive, explicit patent grant), GPL (requires derivative works to stay open), and commercial/proprietary (restricted use). If the repo has no LICENSE file and the site claims a license, that's a red flag.
In the same repo root, open README.md or the docs/ folder. Search for "RAM", "memory", "GPU", "VRAM", "requirements", or "system". Copy the exact numbers. If the README says "tested on 8 GB" but the marketing site says "4 GB minimum", the README is closer to truth because it comes from the builders.
Write down the context: "tested on" is not the same as "will fail below". "Minimum" is aspirational. If it says "8 GB recommended", budget 12 GB in practice.
Search the repo's Issues tab for keywords: "out of memory", "RAM", "minimum", "won't start", "segfault". Read 5–10 real user reports. Users will say things like "I tried 4 GB and it died after 100 tokens" or "works great on 6 GB with quantization". This is ground truth.
Look at the dates. If all the RAM complaints are from two years ago and closed with "fixed in v2.1", the current version may have improved. If they're recent and the maintainer hasn't responded, assume the spec is still broken.
Find the startup script or main.py. Search for these patterns: HTTP requests, "download", "api.openai", "huggingface.co", "cloud". If the tool makes any outbound call at startup (to fetch a model list, check for updates, or phone home), it is not truly offline without a network stub.
Look for environment variables that disable network calls, like OFFLINE_MODE or SKIP_UPDATE_CHECK. If they exist, offline mode is real. If not, or if the flag is undocumented, test it yourself in an air-gapped environment before trusting the claim.
Click "Commits" in the repo. If the last commit was this week, the tool is active. If it was two years ago, the tool is unmaintained. Check the commit messages for fixes, not just version bumps. If all recent commits say "update dependencies" or "security patch", the tool is stable and still cared for. If commits say "experimental", the specs are still in flux.
Also check the number of open vs. closed issues. A tool with 200 open issues and 40 closed ones is drowning. A tool with 12 open and 500 closed is healthy.
This process takes 15–20 minutes per tool. It saves you hours of installation, debugging, and restarting with wrong hardware. The directory referenced in the lead saves this work for 40 tools at once—every spec manually cross-checked against repo docs and issues rather than copied from marketing copy.