Closing the connection on a normal API language post endpoint call in "stream":true will terminate the generation. The model generates only when there is a connection to consume events.
If you want a call that can continue against network adversity, you will want to use the “background”: “true” parameter on the Responses API.
This allows you to set the job in motion and receive an initial object with the job ID and first status.
Then you can poll the response ID object for its status field and see when the API call is completed, retrieving the (non-stream) output over the get endpoint.
You will have use a specific mode; you cannot pick up a “stream” where you left off that has terminated, nor can you re-connect to a stream:false call that continues running and billing (although it also may continue running enough that a retrievable response ID is formed).
A response ID is primarly for re-use as ‘previous_response_id’ in the next call, to continue the conversation memory.
This is a different use case, I’m referring with both stream=true and store=true, as per the request. This does not terminate the generation — in fact if I wait for long enough, I see the response appearing 10 minutes after Closing the connection.