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.