Breaking News on LM Studio: Difference between revisions
Created page with "= Breaking News on LM Studio = While testing LM Studio 0.4.25+1 with the standalone '''llmster''' service, I found that LM Studio deliberately refuses to start its desktop application when llmster is already running. The interesting part is that LM Studio already contains a built-in way around this restriction. The internal experiment flag is named: <syntaxhighlight lang="text"> allowCoexist </syntaxhighlight> From my perspective, this restriction seems unnecessarily..." |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
= Breaking News on LM Studio = | = Breaking News on LM Studio = | ||
Why can't the LM Studio GUI be started with LLMSTER running 'headless' or as a Service? | |||
The interesting part is that LM Studio already contains a built-in way around this restriction. The internal experiment flag is named: | No good reason, so why not fix that pesky issue with that stupid warning dialogue box. | ||
While testing LM Studio 0.4.25+1 with the standalone '''llmster''' service, it was found that LM Studio deliberately refuses to start its desktop application when llmster is already running. | |||
The interesting part is that LM Studio already contains a built-in way around this restriction that isn't published or documented. The internal experiment flag is named: | |||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
| Line 9: | Line 13: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Seems kind of unnecessarily and unfriendly to the end user. LM Studio is provided free of charge, so it is certainly understandable that the developers can do whatever they want in regards with their product and goals. But come on guys, make it a feature that you get if you purchase the software. Don't be all secretive about it. It just seems odd that there's an explicit 'coexistence mechanism', for lack of a better term that prevents users from setting things up more like a service than an application. | |||
== The Fix == | == The Fix == | ||
| Line 19: | Line 23: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
In the the '''developer''' section; | |||
<syntaxhighlight lang="json"> | <syntaxhighlight lang="json"> | ||
| Line 25: | Line 29: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
to: | change to: | ||
<syntaxhighlight lang="json"> | <syntaxhighlight lang="json"> | ||
"experimentFlags": [ | "experimentFlags": ["allowCoexist"] | ||
] | |||
</syntaxhighlight> | </syntaxhighlight> | ||
LM Studio | LM Studio will probably reformat the JSON when it starts, but the setting stays intact. | ||
With '''allowCoexist''' enabled, is will allow LM Studio to start normally while the standalone llmster service is already running without the stupid warning dialogue that says it can't start. | |||
== Consipiracy == | |||
This really smells like the 'experimental' feature of the Chrome Web Browser with 'Tab Mute'. Really Google? Experimental? Seems kind of simple. Firefox and other Browsers have had it for years, and it seems to work fine. Oh, wait! Perhaps it's so people can't easily mute commercials. Could that be it? Makes sense. Who knows for sure? | |||
Anyway, this smells a LOT like that 'mute thing' from Google. | |||
== Windows Service == | == Windows Service == | ||
The following WinSW service configuration starts llmster at boot while still allowing LM Studio's desktop application to | One more cool thing. The below Service allows the LM Studio GUI to 'interact' and even reflect the stop / start state of the Service. | ||
The following WinSW service configuration starts llmster at boot while still allowing LM Studio's desktop application to interact with the backend. Kind of how it should be. | |||
Files are stored in: | Files are stored in: | ||
Latest revision as of 15:34, 6 October 2026
Breaking News on LM Studio
Why can't the LM Studio GUI be started with LLMSTER running 'headless' or as a Service?
No good reason, so why not fix that pesky issue with that stupid warning dialogue box.
While testing LM Studio 0.4.25+1 with the standalone llmster service, it was found that LM Studio deliberately refuses to start its desktop application when llmster is already running.
The interesting part is that LM Studio already contains a built-in way around this restriction that isn't published or documented. The internal experiment flag is named:
allowCoexistSeems kind of unnecessarily and unfriendly to the end user. LM Studio is provided free of charge, so it is certainly understandable that the developers can do whatever they want in regards with their product and goals. But come on guys, make it a feature that you get if you purchase the software. Don't be all secretive about it. It just seems odd that there's an explicit 'coexistence mechanism', for lack of a better term that prevents users from setting things up more like a service than an application.
The Fix
Edit:
C:\Users\Administrator\.lmstudio\settings.jsonIn the the developer section;
"experimentFlags": []change to:
"experimentFlags": ["allowCoexist"]LM Studio will probably reformat the JSON when it starts, but the setting stays intact.
With allowCoexist enabled, is will allow LM Studio to start normally while the standalone llmster service is already running without the stupid warning dialogue that says it can't start.
Consipiracy
This really smells like the 'experimental' feature of the Chrome Web Browser with 'Tab Mute'. Really Google? Experimental? Seems kind of simple. Firefox and other Browsers have had it for years, and it seems to work fine. Oh, wait! Perhaps it's so people can't easily mute commercials. Could that be it? Makes sense. Who knows for sure?
Anyway, this smells a LOT like that 'mute thing' from Google.
Windows Service
One more cool thing. The below Service allows the LM Studio GUI to 'interact' and even reflect the stop / start state of the Service.
The following WinSW service configuration starts llmster at boot while still allowing LM Studio's desktop application to interact with the backend. Kind of how it should be.
Files are stored in:
C:\ProgramData\LMStudio\llmster-service\Start-llmster-service.ps1
$env:USERPROFILE='C:\Users\Administrator'
$env:HOME='C:\Users\Administrator'
$env:HOMEDRIVE='C:'
$env:HOMEPATH='\Users\Administrator'
$Lms='C:\Users\Administrator\.lmstudio\bin\lms.exe'
$StopFlag='C:\ProgramData\LMStudio\llmster-service\stop.request'
$Log='C:\ProgramData\LMStudio\llmster-service\service-runner.log'
Remove-Item $StopFlag -Force -ErrorAction SilentlyContinue
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Service runner starting." |
Add-Content $Log
& $Lms daemon up 2>&1 |
Add-Content $Log
Start-Sleep 3
& $Lms server start --port 1234 --bind 0.0.0.0 2>&1 |
Add-Content $Log
Start-Sleep 3
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Original startup sequence complete." |
Add-Content $Log
while (-not (Test-Path $StopFlag)) {
Start-Sleep -Milliseconds 250
}
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Service runner exiting." |
Add-Content $LogStop-llmster-service.ps1
$env:USERPROFILE='C:\Users\Administrator'
$env:HOME='C:\Users\Administrator'
$env:HOMEDRIVE='C:'
$env:HOMEPATH='\Users\Administrator'
$Lms='C:\Users\Administrator\.lmstudio\bin\lms.exe'
$StopFlag='C:\ProgramData\LMStudio\llmster-service\stop.request'
$Log='C:\ProgramData\LMStudio\llmster-service\service-runner.log'
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Service stop requested." |
Add-Content $Log
& $Lms server stop 2>&1 |
Add-Content $Log
$StatusRaw = (& $Lms daemon status --json 2>$null | Out-String).Trim()
try {
$Status = $StatusRaw | ConvertFrom-Json
if ($Status.status -eq 'running' -and $Status.isDaemon -eq $true) {
& $Lms daemon down 2>&1 |
Add-Content $Log
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Standalone llmster stopped." |
Add-Content $Log
}
else {
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Desktop LM Studio backend detected; leaving LM Studio running." |
Add-Content $Log
}
}
catch {
"$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Could not parse daemon status: $StatusRaw" |
Add-Content $Log
}
New-Item $StopFlag -ItemType File -Force |
Out-NullLMStudioLLMServer.xml
<service>
<id>LMStudioLLMServer</id>
<name>LM Studio llmster Server</name>
<description>LM Studio llmster API server</description>
<executable>powershell.exe</executable>
<startarguments>-NoProfile -ExecutionPolicy Bypass -File "C:\ProgramData\LMStudio\llmster-service\Start-llmster-service.ps1"</startarguments>
<stopexecutable>powershell.exe</stopexecutable>
<stoparguments>-NoProfile -ExecutionPolicy Bypass -File "C:\ProgramData\LMStudio\llmster-service\Stop-llmster-service.ps1"</stoparguments>
<workingdirectory>C:\ProgramData\LMStudio\llmster-service</workingdirectory>
<env name="USERPROFILE" value="C:\Users\Administrator"/>
<env name="HOME" value="C:\Users\Administrator"/>
<env name="HOMEDRIVE" value="C:"/>
<env name="HOMEPATH" value="\Users\Administrator"/>
<serviceaccount>
<username>LocalSystem</username>
</serviceaccount>
<startmode>Automatic</startmode>
<stoptimeout>30 sec</stoptimeout>
</service>The result is a boot-time LM Studio API service on port 1234, while the desktop application remains usable and can reflect/control the same backend after it is started. The key that makes the previously blocked startup possible is allowCoexist.