Synchronous, Streaming, and Asynchronous Requests

Execution mode describes when and how a model result is delivered. It is independent from the model manufacturer: the selected endpoint and model capabilities determine which modes are available.

Synchronous requests

A synchronous endpoint keeps the HTTP request open until it can return the final response. Use it for short operations and clients that do not need incremental output. Apply a timeout appropriate for the selected model rather than assuming every synchronous request completes quickly.

Streaming requests

Streaming endpoints return incremental events, usually over Server-Sent Events. Process events as they arrive, preserve partial output, and distinguish a normal terminal event from a disconnected or quota-truncated stream.

Usage produced before a disconnect can still be billed. Check request logs for the terminal status and final amount.

Asynchronous tasks

An asynchronous endpoint accepts work and returns a platform task ID. Store that ID, then use the query endpoint defined by the selected protocol until the task succeeds, fails, is canceled, or expires.

Poll with a bounded interval and backoff. Where supported, provide callback_url to receive the terminal task snapshot instead of polling continuously. Delivery is at least once, so deduplicate by platform task ID. Until a signed verification contract is published, include an unguessable token in the callback URL and verify it on receipt.

Results and retries

Generated media URLs can expire, so transfer assets you need to retain. Read Data and Result Retention for storage expectations.

Do not blindly retry a model-creation request when you cannot tell whether it was accepted; a duplicate request can create duplicate billable work. See Errors, Limits, and Retries for retry guidance.