Is your feature request related to a problem? Please describe.
With POST /v1/responses using foreground streaming, queueing and prompt prefill can take a very long time before LocalAI sends response headers or SSE data. Reverse proxies may time out during this silent period.
Foreground streaming is otherwise desirable because disconnecting the client cancels the LocalAI request. Using background: true avoids the timeout, but can leave stale jobs running when a client disconnects or restarts.
Describe the solution you'd like
Add optional SSE keepalive comments for foreground streaming Responses requests, for example:
POST /v1/responses?sse_keepalive=15s
LocalAI would flush an initial SSE comment after synchronous request validation, then periodically send comments while waiting for the first real event:
These should probably remain transport-level comments, not synthetic Responses events. The inference request should remain attached to the HTTP request context so disconnects continue to cancel it.
Describe alternatives you've considered
- Increasing reverse-proxy timeouts to an hour or more, but this can get ridiculous, complicate reverse proxy config, and won't necessarily work across all network scenarios.
- Using background Responses and explicitly canceling them, but this can leave a mess if clients are stateless and have no way to know a response needs to be canceled after a restart.
- Adding a separate proxy that sends heartbeats while holding the foreground LocalAI request open, but it adds significant complexity and risk, and at this point it's silly not to try to upstream the fix first.
Additional context
SSE comments are intended for connection keepalives and should be ignored by conforming clients. Making the feature opt-in would avoid compatibility problems with clients that parse SSE imperfectly.
The heartbeat writer should be serialized with normal stream writes, stop on cancellation or write failure, and preferably stop once the first real event is emitted.
Is your feature request related to a problem? Please describe.
With
POST /v1/responsesusing foreground streaming, queueing and prompt prefill can take a very long time before LocalAI sends response headers or SSE data. Reverse proxies may time out during this silent period.Foreground streaming is otherwise desirable because disconnecting the client cancels the LocalAI request. Using
background: trueavoids the timeout, but can leave stale jobs running when a client disconnects or restarts.Describe the solution you'd like
Add optional SSE keepalive comments for foreground streaming Responses requests, for example:
LocalAI would flush an initial SSE comment after synchronous request validation, then periodically send comments while waiting for the first real event:
These should probably remain transport-level comments, not synthetic Responses events. The inference request should remain attached to the HTTP request context so disconnects continue to cancel it.
Describe alternatives you've considered
Additional context
SSE comments are intended for connection keepalives and should be ignored by conforming clients. Making the feature opt-in would avoid compatibility problems with clients that parse SSE imperfectly.
The heartbeat writer should be serialized with normal stream writes, stop on cancellation or write failure, and preferably stop once the first real event is emitted.