Essentials Recap
General questions belong in community forums. Reproducible bugs belong in GitHub issues with full version and hardware details. Self-service troubleshooting covers the most common problems. For site-specific matters, email hello@lmstudio.co.com.
Community forums and Discord
Community channels are the fastest route for questions about model choice, prompt templates, and workflow ideas — active users often respond within minutes during peak hours.
The LM Studio community maintains active discussion spaces where users at every skill level share configurations, compare model performance, and troubleshoot together. If you have a question that is more exploratory than definitive — which model quantization to pick for a 16 GB laptop, how to write a system prompt for a coding assistant, whether a given model format is supported — community forums are the right first stop. Responses there come from practitioners who have already worked through the same questions.
Discord servers focused on local LLM tooling are particularly useful for real-time back-and-forth. Describing a problem in a thread and getting clarifying questions answered in the same session is often faster than any formal support queue. That said, Discord messages disappear into scroll history quickly — if your issue turns out to be a genuine bug, move it to GitHub where it can be tracked.
Etiquette matters in community spaces. Include your LM Studio version and OS upfront, describe what you have already tried, and give the model file name and quantization level. A complete question gets a faster answer than a vague one. Per guidance from sources like MIT's open-source community resources, clear bug reporting benefits the whole community, not just the individual reporter.
GitHub issues guidance
GitHub issues are the right channel for reproducible bugs — crashes, model load failures, API errors, and UI problems that happen consistently under specific conditions.
Before opening a new issue, search the existing open and closed issues using keywords from your error message. Many problems have already been reported, discussed, and either fixed in a later release or documented with a workaround. Duplicate issues split the conversation and slow down resolution.
A good issue report includes: the exact LM Studio version from the About screen, your operating system and version, GPU make and driver version, the model file name and quantization suffix (for example, llama-3-8b-instruct.Q4_K_M.gguf), the exact steps to reproduce the problem, what you expected to happen, and what actually happened. Paste the relevant section of the application log file rather than describing it — the raw text is far more useful to the people working on the fix.
What makes a useful bug report
Five pieces of information turn a vague complaint into something actionable: version, OS, GPU, model file, and reproduction steps.
- LM Studio version number (visible in the About dialog)
- Operating system name and version (e.g. Windows 11 22H2, macOS 14.4, Ubuntu 24.04)
- GPU model and driver version, or "CPU only" if GPU offload is disabled
- Model file name including quantization suffix
- Minimal steps to reproduce — the fewer variables the better
Self-service troubleshooting
The troubleshooting page on this site covers the ten most common failure modes, each with a specific diagnosis step and a verified fix.
Most problems that new LM Studio users encounter fall into a small number of categories: a model that fails to load because the system is out of RAM, an API client that can't connect because the server tab wasn't activated, a slow inference rate that improves after adjusting the GPU layer count, or a crash caused by an incompatible model format. The troubleshooting page works through each of these in order of frequency, with exact UI steps for each fix.
Application logs are stored in a platform-specific directory and contain timestamped entries for every model load, inference call, and error the application encounters. Checking the log before posting to a forum or filing an issue often reveals the root cause immediately.
Issue types and support channels
The table below maps common issue types to the right channel and a realistic response window.
| Issue type | Recommended channel | Typical response time |
|---|---|---|
| General how-to questions | Community forum or Discord | Minutes to a few hours |
| Reproducible application bugs | GitHub issue tracker | 1–5 business days for initial triage |
| Model load failures | Troubleshooting page first; then community forum | Self-service immediate; forum same-day |
| API or server-mode errors | GitHub issue with log excerpt and client code snippet | 2–7 days depending on complexity |
| Site content corrections | Email hello@lmstudio.co.com | 2 business days |
Contact the editorial team for urgent matters
The editorial team at this reference site can be reached by email for corrections, partnership questions, or urgent site-related matters — not for upstream LM Studio application bugs.
If you find an error on one of these pages — a wrong system requirement, an outdated API endpoint, a broken link — email hello@lmstudio.co.com with a brief description and the URL of the affected page. The team reviews every message and applies verified corrections promptly. For a full breakdown of inquiry types and response windows, see the contact team page.
The team at this site is not affiliated with the LM Studio development project and cannot relay bug reports to upstream developers. For application bugs, the GitHub issue tracker is the correct and direct path.