Skip to main content
Use background mode when a response may take a long time to complete, such as multi-step tool use or large generation tasks. The API returns immediately with a queued response, and you retrieve the result later by polling or streaming.

Create a background response

Set background to true and stream to false. The API creates the response, starts processing it asynchronously, and returns immediately with status: "queued".
Save the id to retrieve the result later.

Poll for the result

Call GET /responses/{response_id} until the status reaches a terminal state.
A response moves through these statuses as it is processed: Poll at a reasonable interval (for example, every two seconds) until the status is no longer queued or in_progress.

Stream events from a background response

If you want real-time updates instead of polling, retrieve the response with stream set to true. The API returns server-sent events as the response is processed.
Events arrive as they are produced. The stream closes after a terminal event such as response.completed or response.failed. If the response has already completed when you call this endpoint, you receive a single terminal event with the final response and the stream closes immediately.

Stream events at creation time

You can also stream events directly when creating a background response by setting both background and stream to true.
The first event is response.queued, followed by response.created, intermediate events such as response.output_text.delta, and finally a terminal event like response.completed. This is useful when you want to show progress in a UI while the work runs in the background. If the client disconnects, the response continues processing and can be retrieved later.

Cancel a background response

If you no longer need the result, cancel a queued or in-progress response.
The response status changes to cancelled. Responses that have already completed or failed cannot be cancelled.

Pause and wake

Add the sleep tool when a background response may need to wait, for example for a webhook it just triggered, or between checks on an outside job. The model calls sleep with either duration_seconds (1 to 1200) or wake_at (an ISO 8601 timestamp at most 20 minutes ahead), plus an optional reason. sleep only works with background: true. The gateway rejects a foreground request that lists it. To cut a sleep short, call the wake endpoint with follow-up input. The model receives that input as the tool’s result and continues from it. The sleep tool type and the wake endpoint are gateway extensions the OpenAI SDK does not know, and the mka1 CLI reference documents no responses wake command, so this section shows the MKA1 SDKs and curl.
While it sleeps, the response keeps status: "in_progress"; there is no separate sleeping status, so polling cannot tell you it is asleep. Stream its events as shown above and wait for response.sleep_call.sleeping, or call wake and retry on 409. A sleep appears in the stream as three events: response.sleep_call.in_progress with the model’s args, response.sleep_call.sleeping with the resolved wake_at, and response.sleep_call.completed with a status of woke, interrupted, or cancelled. The function_call_output on that last event is the JSON the model received. When the timer runs out, the model receives {"status": "woke", "slept_seconds": ..., "wake_at": ...}, plus reason if it gave one. When you wake it, the model receives {"status": "interrupted", "input": ..., "slept_seconds": ..., "wake_at": ..., "interrupted_at": ...}, again with reason if given. If the input was cut, the payload also carries input_truncated: true and original_input_length. Cancelling the response ends the sleep with status: "cancelled". The wake call returns one of two statuses: input is trimmed and must then be 1 to 20,000 characters, so whitespace-only input is rejected; the model sees the first 8,000. Wake calls are limited to 30 per minute for each API key and end user, and further calls are blocked for 10 seconds once you exceed that.

Next steps