GPT-5.2 Chat's Responses, Reasoning, and Tool-Calling Configuration

One-sentence takeaway

For multi-turn Agents, prefer the Responses API to preserve state across turns, explicitly set reasoning and verbosity, and use allowed_tools to limit the tools available in the current turn. This is usually easier to control than hard-coding every tool and call sequence into the prompt.

Use cases

• Suitable tasks: Multi-turn retrieval, code/file processing, and Agents that need pre-tool-call explanations and auditing.

• Unsuitable tasks: Chat that only needs a single short-text response; in that case, Chat Completions or a lower-cost model may be simpler.

• Applicable model versions: gpt-5.2, gpt-5.2-pro, and gpt-5.2-chat-latest on the official page; check parameter support against the endpoint.

• Applicable clients, Agents, or APIs: OpenAI Responses API; when migrating from Chat Completions, recheck the mapping of message and tool parameters.

• Recommended reasoning levels and parameters: For low latency, start with reasoning: {"effort":"none"}; for complex tasks, try medium/high/xhigh incrementally; text.verbosity defaults to medium, and should be adjusted to the purpose of the output.

Ready-to-use content

The following is a minimal Responses configuration skeleton organized from the official examples. It does not guarantee that every capability in the Chat version is available; schema-check it with the target model before deployment.

{
  "model": "gpt-5.2",
  "input": "After completing the task, provide verifiable results. State the purpose in one sentence before calling a tool; after each write, state where the change was made and verify it.",
  "reasoning": { "effort": "none" },
  "text": { "verbosity": "medium" },
  "tools": [
    {
      "type": "function",
      "name": "search_docs",
      "description": "Search the approved document corpus and return source IDs. Validate input and never invent results."
    },
    {
      "type": "function",
      "name": "write_record",
      "description": "Write one validated record. Return the exact record ID and path after success."
    }
  ],
  "tool_choice": {
    "type": "allowed_tools",
    "mode": "auto",
    "tools": [
      { "type": "function", "name": "search_docs" }
    ]
  }
}

If a tool needs the model to send raw text (such as SQL, code, or a DSL), the official API also supports custom tools; the server must still perform injection, permission, and syntax checks:

{
  "type": "custom",
  "name": "code_exec",
  "description": "Executes only sandboxed Python code; reject filesystem, network, and credential access."
}

Testing/workflow steps

1. Register the complete tool set in the Responses API first; place only read-only tools in allowed_tools according to the current stage.

2. Run none and medium separately on the same task, recording completion rate, number of tool calls, latency, tokens, and error types.

3. Make each tool description clearly state its purpose, when to call it, and its return value; after a write, the server must return the ID/path and reread it for verification.

4. Save response state for multi-turn tasks; when the context approaches its limit, compress it according to the official compaction approach and rerun key assertions after compaction.

5. When migrating from Chat Completions, keep the task prompt unchanged for the baseline, then change the API, reasoning level, and tool restrictions separately.

Original evidence and data

• Official guidance recommends gpt-5.2 for complex reasoning and multi-step Agents, gpt-5.2-chat-latest for ChatGPT-aligned behavior, and gpt-5.2-pro for harder questions where a longer wait is acceptable.

• The official documentation states that none is GPT-5.2's lowest reasoning level and default starting point, and recommends gradually increasing to medium when more thinking is needed.

• The official documentation explicitly says that allowed_tools can restrict the callable subset for the current turn from the full tool list, with auto or required as the available modes.

• OpenAI says that named apply_patch reduced the failure rate by 35% in its tests, but it has not disclosed the complete harness, task set, or confidence interval, so this cannot be generalized as a guarantee for all applications.

• OpenAI says that the Responses API can pass reasoning context across turns and reduce repeated reasoning tokens; the specific benefit depends on the application's state management and request implementation.

Applicability boundaries

• This skeleton combines official API examples with security constraints; its tool names, permissions, and validation logic are examples, not the default security policy for OpenAI-hosted tools.

• The gpt-5.2-chat-latest model page is currently marked deprecated, and Chat Completions has different context and output limits from gpt-5.2; do not copy all Responses parameters directly.

• temperature/top_p/logprobs are officially supported for GPT-5.2 only when reasoning.effort=none; for other levels, use reasoning, verbosity, max output, and other controls.

• Custom tools can send free-form text, but OpenAI emphasizes that the server must validate it and must not give the model direct access to an unsandboxed shell, network, or credentials.

Source excerpt or observation (compliance short quote only)

The official guide recommends that tool descriptions be “concise, explicit” and requires the server to validate free-form output; this is the most important security boundary when configuring tool-using Agents.