Skip to main content
The Responses API supports tool calling to give models access to external functions. Define tools in your request with a name, description, and JSON schema for parameters. When the model determines it needs a tool to answer the user’s question, it returns a function_call output with the tool name and arguments for you to execute.
The Responses API is best supported on the Enterprise plan. Use https://enterprise.blackbox.ai as the base URL for full model availability and production reliability. The API is also available on standard plans at https://api.blackbox.ai, where it is currently experimental.
Important — Tool Format: The Responses API uses a flat tool structure where name, description, and parameters are at the top level. This is different from the Chat Completions API which nests them under function. Using the Chat Completions nested format on the Responses API will result in an invalid_request_error.See the Chat Completions tool calling docs if you are using /chat/completions instead.

Basic Tool Calling

Tool Call Response

When the model decides to call a tool, the response includes a function_call output:
Parse the arguments and execute your function, then send the result back in a follow-up request:

Multi-Turn Tool Calling

In a multi-turn conversation, you build up the full history — user messages, model outputs (including function_call items), and tool results (function_call_output items) — and send it with each request. The Responses API is stateless, so every request must contain the complete conversation. This example walks through a two-turn exchange where the model calls a tool in the first turn, receives the result, then calls a second tool in the second turn before giving a final answer.
Codex models (gpt-5.3-codex, gpt-5.2-codex): These models always operate under Zero Data Retention (store: false), so include: ["reasoning.encrypted_content"] is always enabled — even if you do not provide it. Encrypted reasoning tokens are returned in every response and can be passed back in subsequent requests to maintain reasoning continuity without any server-side storage. See Zero Data Retention for details.
This section breaks down what happens at each turn so you can see exactly how messages flow.

Turn 1 — Initial request

Send the user’s message and tool definitions:

Turn 1 — Execute the tool and send the result back

Append the model’s function_call output and your function_call_output to the history, then make the next request:
If the model calls another tool (e.g. search_file), repeat the same pattern — append its function_call, execute it, append the function_call_output, and send again. When the model returns a message output with no further function calls, the conversation is complete.

Conversation history shape

After two tool calls, the input array you send looks like this:
Always include every function_call item from the model’s output array verbatim in the next request’s input. Omitting any item will cause the API to reject the conversation as malformed.

Multi-Turn with User Messages

After returning a tool result, you can append a new user message in the same request to continue the conversation. This lets the user ask follow-up questions based on the tool’s output without starting over.

Turn 1 — User asks a question

Turn 2 — Return tool result and add a follow-up user message

Append the model’s function_call, your function_call_output, and the new user message together in input:
The conversation history sent in Turn 2 looks like this:
The new user message goes after the function_call_output, not before it. The API processes the input array in order and expects tool results to appear immediately after their corresponding function_call.

Tool Choice Options

Control how the model uses tools with the tool_choice parameter:
ValueBehavior
"auto"The model decides whether to call a tool
"required"The model must call at least one tool
"none"The model cannot call any tools

Request Parameters

tools
array
required
Array of tool definitions. Each tool object contains:
  • type: Always "function"
  • name: The function name the model will use
  • description: Describes when and how to use this tool
  • parameters: JSON Schema object defining the function’s parameters
tool_choice
string | object
Controls tool usage. Set to "auto" (default), "required", or "none". To force a specific tool, pass {"type": "function", "name": "tool_name"}.
parallel_tool_calls
boolean
When true, the model may call multiple tools simultaneously. Default: true

Use Case: Coding Agent

A coding agent gives the model a set of file system and terminal tools and runs an agentic loop — calling the API, executing whatever tools the model requests, and feeding the results back — until the model returns a plain text response with no further tool calls. Define seven SWE tools:
Python
Then run the agentic loop:
Python
The agent loop continues until the model returns a response with no function_call outputs. Always set a max_iterations guard to prevent runaway loops.
Example tasks this agent handles:
  • "Read main.py and tell me what the entry point function does."
  • "Write a file /tmp/utils.py with a helper function for parsing JSON, then read it back to confirm."
  • "Search app.py for all lines containing 'TODO' and list their line numbers."
  • "Edit config.py: replace DEBUG = False with DEBUG = True, then verify the change."
  • "Run python3 tests/test_api.py and report any failures."
  • "List the project root and find all TypeScript files under src/."

Tool Calling with Encrypted Reasoning (ZDR)

Codex models (gpt-5.3-codex, gpt-5.2-codex) always operate under Zero Data Retention — store is enforced to false and no data is persisted between requests. To support stateless multi-turn tool calling, include: ["reasoning.encrypted_content"] is always enabled for these models, even if you do not provide it. This means every response includes reasoning output items with an encrypted_content field. When building multi-turn conversations, pass these reasoning items back verbatim in the next request’s input array. The encrypted content is decrypted in-memory for generating the next response and then securely discarded — no intermediate state is ever persisted.

Basic Example — Weather Tool with Encrypted Reasoning

Multi-Turn Agentic Loop with Encrypted Reasoning

For agentic workflows where the model may call multiple tools across several turns, use a loop that automatically handles encrypted reasoning items:
Always include all output items from each response — including reasoning items with encrypted_content — when building the input for the next turn. Omitting reasoning items will break the model’s chain of thought and may degrade response quality.

Next Steps

Text Generation

Learn the basics of the Responses API

Streaming

Stream tool calls in real time as they are generated

Best Practices

Tool call IDs, pairing tool results, reasoning signatures, and more

Zero Data Retention

Learn more about ZDR and encrypted reasoning for Codex models