Asynchronous tool calls in the Responses API let the model continue independent work while the application runs a slow tool. The application executes the background task and submits its result in a later request using the original call_id.
Suitable tasks: Slow external lookups, independent subtasks that can run in parallel, and application flows that need to keep working while waiting for a user's answer.
Unsuitable tasks: Hosted built-in tools run by OpenAI and Programmatic Tool Calling. In Multi-agent mode, do not combine async tools with parallel tool calls either.
Supported model versions: The compatibility section states, “GPT-6 Astra and later models.” It does not explicitly list GPT-6 Sol. This article's placement in the Sol directory does not confirm Sol compatibility; check the current API compatibility for the target model before implementation.
Supported client, agent, or API: Responses API; tools are executed by the application. Async tools do not hand execution over to OpenAI or manage the application's background tasks.
Recommended reasoning level and parameters: The source does not specify a fixed reasoning level. Add async: true to the tool definition for the specific function or custom tool.
Add async: true to a function or custom tool definition in the Responses API. For example:
{
"type": "function",
"name": "lookup_price",
"description": "Look up a product price in the background.",
"async": true,
"strict": true,
"parameters": {
"type": "object",
"properties": {"sku": {"type": "string"}},
"required": ["sku"],
"additionalProperties": false
}
}After receiving a complete function_call or custom_tool_call, have the application start the corresponding background task and save the response ID, original call_id, and task status. For streaming responses, wait until the complete tool-call item arrives before starting the task.
The model can continue producing an independent answer in the same response. The application can show that result first while the background task keeps running. If a new conversation turn occurs in between, update the latest response ID used for the continuation request, but retain the original tool call's call_id.
When the task completes, submit its output in a subsequent Responses request: use function_call_output for a function and custom_tool_call_output for a custom tool. Continue with the latest previous_response_id, and include tools and instructions again.
If the model needs to decide when to wait, add a regular synchronous wait_for_tasks function. Add task_handle to the async call's parameters, and have the application maintain a conversation-wide handle → original call_id / background-task registry. A handle cannot be reused, even after its task is complete.
When a wait call arrives, wait only for the specified tasks in the registry whose results have not yet been returned. First return newly completed results using each original call_id, then return the status using the wait call's own call_id. Wait only when the model's next step depends on the result; the application can also return the result as soon as the task completes, without a wait tool.
If an async tool asks the user for information, show the question in the application and return the user's answer as the result of the original call. Continue independent work while waiting; if the user cancels or times out, return an explicit no-answer result.
Setting async: true in a tool definition makes the returned call item include async: true. This means it can be handled asynchronously; it does not mean the application has started or completed the task.
The output item must use the original call's call_id. The wait tool is a regular application-defined function; neither wait_for_tasks nor request_user_input_async is a built-in Responses API tool.
For an async call that asks the user a question, the tool result should contain the user's actual answer. Merely confirming that the question was shown does not complete the call.
Async execution does not keep a Response open while waiting for a tool or user. The application must submit the tool result in a later request.
Async support applies to application-executed functions and custom tools, not hosted built-in tools. Programmatic Tool Calling should call tools directly and should not be configured as async.
In Multi-agent mode, do not combine async tools with parallel tool calls.
The official compatibility statement only says “GPT-6 Astra and later models”; the page does not explicitly state whether gpt-6-sol falls within that scope. This was not verified in a Sol-specific environment.
The weather, price, and user-answer examples are illustrative data or workflow examples, not results from actual services.
GPT-6 Sol