Quick Reference
This site is an editorially independent reference: no affiliation with the LM Studio upstream project, no sponsored content, and no advertising revenue shaping what gets covered or how.
Who runs this site
A small team of practitioners who work with local LLM tooling day-to-day built and maintain this reference — not a marketing department, not a reseller, and not the LM Studio development group.
The people behind these pages use LM Studio regularly for prompt engineering, application prototyping, and offline research workflows. That practical context shapes every editorial call: topics get covered when they surface real friction for real users, not when they fill a content calendar slot. The team profile page has more detail on individual contributors and their areas of focus.
The site is funded through the editorial team's own resources. There are no banner ads, no affiliate links to model vendors, and no sponsored placement deals. That funding model is a deliberate constraint: the moment a page's conclusions can be traced back to who paid for it, the page loses its reason to exist.
Editorial scope
Coverage concentrates on installation, configuration, the local API, model selection, performance tuning, and comparisons to alternative runtimes — the topics users most often search for when they are stuck.
Every page on this site addresses a specific user question or task. The quickstart walks through the first ten minutes of the application. Platform pages cover the Windows installer, the macOS disk image, and the Linux AppImage separately because the friction points differ by OS. The API and server pages explain how LM Studio's local endpoint works and how to connect clients to it. The alternatives page compares LM Studio to other runtimes without declaring a winner — the right tool depends on the workflow.
What does not get covered: speculative roadmap material, promotional features the team has not tested, and content derived entirely from press releases. If an LM Studio capability cannot be verified by loading the application and exercising the feature, it does not appear here as established fact.
What we cover and what we don't
The site documents the desktop application, the local server, and the model ecosystem — not cloud services, not third-party integrations the team hasn't tested, and not the internal engineering decisions of the upstream project.
Coverage is intentionally narrower than a wiki. Each page answers one coherent question. The troubleshooting page lists the errors that come up most often with actionable fixes; it doesn't attempt to enumerate every edge case. The model library page explains how the in-app browser works; it doesn't maintain a live index of every available model weight. Keeping the scope bounded is what keeps the quality high.
Sourcing methodology
Primary sources are the application itself, official release notes, and the public issue tracker — supplemented by public academic and standards-body material when the topic warrants it.
Before a factual claim appears on a page, the team checks it against one of three source types. First preference is hands-on verification: loading the relevant LM Studio version, exercising the feature, and capturing what actually happens. Second preference is official release documentation or the public changelog. Third preference is a credible secondary source — typically a public repository, a standards body publication, or peer-reviewed research. Opinion and personal experience are labelled as such and kept separate from factual description.
External links go to sources where the editorial team has no commercial relationship. Government standards bodies, university research groups, and open-source project repositories are the most common destinations. See, for example, guidance from NIST's AI Risk Management Framework on evaluating AI system trustworthiness. Linking out to another vendor's product page or an affiliate-monetised review aggregator is not done.
Editorial principles vs. typical vendor sites
The table below maps this site's editorial commitments against what users typically find on product-vendor documentation pages and promotional microsites.
| Principle | This site | Typical vendor site |
|---|---|---|
| Funding model | Self-funded editorial team; no ads, no sponsors | Funded by the product company; costs recovered through sales |
| Scope of coverage | Includes limitations, known issues, and competitor comparisons | Emphasises strengths; limitations minimised or omitted |
| Source transparency | Claims linked to primary sources or labelled as opinion | Claims may be unlinked marketing assertions |
| Update trigger | Triggered by verified changes in the application or user feedback | Triggered by release cycles and marketing calendars |
| Conflict of interest | No revenue from the product being documented | Revenue directly tied to the product's commercial success |
Contact and corrections
Errors get corrected quickly — reach the team by email and expect an acknowledgement within two business days.
If you spot a factual error, an outdated screenshot, or a claim that no longer matches the current version of LM Studio, the fastest path to a fix is email. The contact team page has the address and a breakdown of what information to include in a correction request. The team does not maintain a public comments section, but every email gets read and substantive corrections are applied to the relevant pages.