Problem
I am running Unsloth Studio on a headless Kubuntu server and accessing it remotely over LAN, mainly from a phone.
The inference itself works great on the server. However, there is one important limitation for this kind of setup:
If the browser/client disconnects while a generation is in progress, the generation is cancelled and the result is lost.
For example:
- I connect to Unsloth Studio from my phone over LAN.
- I start a long reasoning / Deep Research request.
- The model starts thinking and generating normally.
- I lock my phone or leave the browser in the background.
- The mobile browser eventually closes/loses the SSE connection.
- Studio reports a network/connection error and the generation is cancelled.
- When I return to the chat, there is no completed response.
This makes it impossible to use Studio as a true server-side AI service where I can submit a long-running task and come back later.
This is especially noticeable with reasoning models and Deep Research, where generation can take several minutes.
Expected behavior
I would like an option that makes the generation lifecycle independent from the browser/SSE connection.
For example, a setting such as:
Settings → Generation → Continue generation after client disconnect
When enabled:
the server should continue generating even if the browser disconnects;
the generation should be associated with the conversation/message rather than the current SSE connection;
when I reconnect or reopen the chat, Studio should retrieve the current/completed generation state;
if the generation finishes while I am disconnected, the completed response should simply be waiting in the conversation when I return.
The current behavior could remain the default for users who want disconnected clients to immediately cancel generation, so this could simply be an opt-in setting.
This would make Unsloth Studio much more suitable for:
- headless Linux servers
- remote access over LAN
- accessing Studio from mobile devices
- long-running reasoning models
- Deep Research / web-search tasks
- users who submit a task and want to return to it later
Open WebUI, for example, allows me to start a generation, close the browser on my phone, and return later to find the completed response. I would really like to use Unsloth Studio in the same way.
Possible implementation
I don't know the internals well enough to suggest the correct implementation, but conceptually this could work as:
client → create generation job → server-side generation → SSE/WebSocket only becomes a way to observe the job
rather than:
client → SSE stream → generation lifetime tied to SSE connection
A lightweight alternative could simply be a per-generation option such as:
- Continue generation if client disconnects
with the frontend reconnecting to the existing generation/message when the user returns.
Environment
OS: Kubuntu Linux
Access: LAN
Client: mobile browser
Unsloth Studio: v0.1.801-beta
Use case: local LLM inference, reasoning models and Deep Research
This is not a request to prevent cancellation entirely. I think the current cancellation behavior is useful and should remain available.
I would mainly like an opt-in "background generation / continue after disconnect" mode for server/headless use.
Thanks! Unsloth Studio has been working extremely well for me otherwise, especially the tool handling, web search and Deep Research. This is currently the main thing preventing me from treating it as a proper always-on local AI server.
Problem
I am running Unsloth Studio on a headless Kubuntu server and accessing it remotely over LAN, mainly from a phone.
The inference itself works great on the server. However, there is one important limitation for this kind of setup:
If the browser/client disconnects while a generation is in progress, the generation is cancelled and the result is lost.
For example:
This makes it impossible to use Studio as a true server-side AI service where I can submit a long-running task and come back later.
This is especially noticeable with reasoning models and Deep Research, where generation can take several minutes.
Expected behavior
I would like an option that makes the generation lifecycle independent from the browser/SSE connection.
For example, a setting such as:
Settings → Generation → Continue generation after client disconnect
When enabled:
the server should continue generating even if the browser disconnects;
the generation should be associated with the conversation/message rather than the current SSE connection;
when I reconnect or reopen the chat, Studio should retrieve the current/completed generation state;
if the generation finishes while I am disconnected, the completed response should simply be waiting in the conversation when I return.
The current behavior could remain the default for users who want disconnected clients to immediately cancel generation, so this could simply be an opt-in setting.
This would make Unsloth Studio much more suitable for:
Open WebUI, for example, allows me to start a generation, close the browser on my phone, and return later to find the completed response. I would really like to use Unsloth Studio in the same way.
Possible implementation
I don't know the internals well enough to suggest the correct implementation, but conceptually this could work as:
client → create generation job → server-side generation → SSE/WebSocket only becomes a way to observe the job
rather than:
client → SSE stream → generation lifetime tied to SSE connection
A lightweight alternative could simply be a per-generation option such as:
with the frontend reconnecting to the existing generation/message when the user returns.
Environment
OS: Kubuntu Linux
Access: LAN
Client: mobile browser
Unsloth Studio: v0.1.801-beta
Use case: local LLM inference, reasoning models and Deep Research
This is not a request to prevent cancellation entirely. I think the current cancellation behavior is useful and should remain available.
I would mainly like an opt-in "background generation / continue after disconnect" mode for server/headless use.
Thanks! Unsloth Studio has been working extremely well for me otherwise, especially the tool handling, web search and Deep Research. This is currently the main thing preventing me from treating it as a proper always-on local AI server.