What changed
SGLang v0.5.20 reached PyPI on September 18, 2026 3. Its OpenAI compatible /v1/responses endpoint no longer retains results in memory unless the server starts with --enable-response-store, and without that flag retrieval, previous_response_id chaining and background requests return 400, while a prefill/decode deployment cannot enable it at all 1. Background requests require store=true, so under the new default they have nowhere to land 2.
The field that still says store=true
The line worth reading twice sits in the pull request, not in the highlight. Foreground generation and streaming still accept the API default store=true and answer normally without retaining anything, and the store field in the reply keeps echoing what the client asked for while the server capability decides actual retention 2. So the request that should warn you succeeds, and the 400 arrives one turn later, when the loop comes back with previous_response_id. Chaining responses that way is how the upstream contract threads a conversation 4. I would rather a flag failed on the first call than on the second.
--enable-response-store # default off: retrieval, previous_response_id, background
Impact on your team
Grep the client, not the server. If previous_response_id or background appears in your agent loop, that path breaks on this version unless someone adds the flag to every replica. The migration notice gives the fix I would ship regardless: send explicit conversation history in foreground requests 2. It is also the only fix that survives a move to disaggregated serving, where prefill and decode stop sharing one engine 5 and the store is not on offer 1. If you were using the endpoint as a session store, the 400 is not the regression; the unbounded dict you were filling was. Hold your current version for a sprint if you chain today, and spend that sprint moving state into the request.