Breaking News on LM Studio: Difference between revisions

wiki.TerraBase.info
Jump to navigation Jump to search
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 =


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.
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>


From my perspective, this restriction seems unnecessarily unfriendly to the end user. LM Studio is provided free of charge, so I certainly understand the developers having their own product and architectural goals. However, since the software already contains an explicit coexistence mechanism, preventing normal users from using it seems like an odd limitation.
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>


Under the existing '''developer''' section, change:
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"]
  "allowCoexist"
]
</syntaxhighlight>
</syntaxhighlight>


LM Studio may automatically reformat the JSON when it starts. That is normal.
LM Studio will probably reformat the JSON when it starts, but the setting stays intact.


Do '''not''' make this change in:
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.


<syntaxhighlight lang="text">
== Consipiracy ==
C:\Users\Administrator\.lmstudio\apps\bionic\settings.json
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?
</syntaxhighlight>


With '''allowCoexist''' enabled, LM Studio can start normally while the standalone llmster service is already running.
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 take over the backend later. When the service is started while LM Studio is already running, LM Studio reflects the server state in its GUI.
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:

allowCoexist

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

Edit:

C:\Users\Administrator\.lmstudio\settings.json

In 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 $Log

Stop-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-Null

LMStudioLLMServer.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.