Skip to main content
Lesson 5 of 12 · ChatGPT in 2026: From GPT-5.6 to GPT-6

Programmatic Tool Calling: Model-Orchestrated Tools

Lesson 5 of 12 Updated November 5, 2026 Intermediate
On this page
  1. What Changes
  2. Enabling It in the Responses API
  3. What Your Application Receives
  4. Identifying Tasks That Benefit
  5. Try It Yourself
  6. Key Takeaways

Status as of November 5, 2026. The GPT-6 family inherits the API capabilities of GPT-5.6, including Programmatic Tool Calling. The Agents API enables this by default (Lesson 10). OpenAI recommends checking the model card before enabling it.

To understand what Programmatic Tool Calling brings to the table, you first need to look at the cost of classic function calling. The model requests a tool execution, your code runs it, and the result goes back to the model, which reads it and decides the next step. One round trip isn’t a big deal. Ten round trips for a single task is a different story: each step adds latency, and every intermediate result—even if bulky or irrelevant to the final answer—passes back through the model’s context and gets billed in tokens. On tool-heavy tasks, these round trips dominate both latency and cost.

What Changes

Programmatic Tool Calling arrived with GPT-5.6 on July 9, 2026, in the Responses API. Instead of requesting tools one by one, the model writes a small JavaScript program to coordinate them. It can launch calls in parallel, use loops and conditions, and keep intermediate results within the execution environment. Only the reduced result—the one that matters for the next step—returns to the context.

Consider a paginated API. In classic function calling, every page of results traverses the context so the model can decide whether to request the next one. With Programmatic Tool Calling, the model writes a loop that iterates through the pages, sums up what needs summing, and reports back only the totals: fewer tokens, less latency, and less orchestration code for you to maintain.

OpenAI executes each program in a fresh, isolated V8 environment. There is no Node.js, no package installation, no direct network access, no general file system, and no state preserved between programs. The program interacts with the world only through the tools you expose to it. For the Responses API, this behavior is compatible with Zero Data Retention (ZDR), provided ZDR is enabled for the organization or project.

Enabling It in the Responses API

Two settings are sufficient. You add the hosted tool programmatic_tool_calling to the request, then specify who can call each eligible tool using allowed_callers: ["direct"] (the default behavior, where the model calls the tool itself), ["programmatic"] (only a program can call it), or both. The documentation also recommends describing the output of each function with output_schema so the generated code can rely on its fields.

from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "name": "read_stock",
        "description": "Returns an object with sku (text) and units (number).",
        "parameters": {
            "type": "object",
            "properties": {"sku": {"type": "string"}},
            "required": ["sku"],
            "additionalProperties": False,
        },
        "output_schema": {
            "type": "object",
            "properties": {"sku": {"type": "string"}, "units": {"type": "number"}},
            "required": ["sku", "units"],
            "additionalProperties": False,
        },
        "allowed_callers": ["programmatic"],
    },
    {"type": "programmatic_tool_calling"},
]

response = client.responses.create(
    model="gpt-5.6-terra",
    input="Check stock for SKUs A12, B07, and C33 and flag those under 10 units.",
    tools=tools,
)

Tool types that can be called from a program include functions and custom tools, MCP tools, apply_patch, local or hosted shell, and the code interpreter. For an MCP tool subject to approval, the program pauses until you grant consent.

What Your Application Receives

The response remains a standard Responses object with three types of elements to recognize. A program element contains the generated JavaScript. function_call elements correspond to your function calls made by that program; their caller field identifies the calling program. Finally, a program_output element delivers the program’s final result, with a status of completed or incomplete.

Your application never executes the JavaScript; OpenAI runs that. You only execute your own functions, then return each result in a function_call_output by copying the caller field unchanged so the correct program can resume. You loop like this until the response contains no more calls to execute.

Who executes what Three steps: the model writes a JavaScript program that OpenAI executes in an isolated environment; your application executes the function calls from that program and returns the results with the caller field intact; the program delivers a reduced result in program_output. PROGRAMMATIC TOOL CALLING Who executes what 1 Program Written by the model 2 Your functions Executed by you 3 Result Reduced program_output JavaScript runs at OpenAI, never on your side. Sensitive writes remain direct calls.
Based on the Programmatic Tool Calling guide in the OpenAI API documentation (November 2026).

Identifying Tasks That Benefit

Not every tool integration benefits from migrating. OpenAI’s guide offers a clear rule: Programmatic Tool Calling suits steps where the flow is predictable and the code can return a smaller, structured result. It is designed to filter, join, sort, deduplicate, aggregate, or validate multiple results, or to chain dependent calls where the data flow is predictable. Direct calling remains preferable for a single search or action, for adaptive searches where each result must guide the next decision, and for final citation validation. It also remains the default choice for writes and actions requiring approval to maintain a clear authorization boundary.

The decision criterion boils down to one question: where does your agent spend its time? If the answer is “waiting for tool round trips,” Programmatic Tool Calling is the first area to evaluate. If your tool calls are rare and their results short, keep your current architecture and focus your efforts elsewhere.

Try It Yourself

Identify a candidate. Take a flow in your agent that calls multiple tools. For each step, note the number of calls, the size of intermediate results, and whether it is a read or a write. Classify each step using the rule above. For the most promising step, write a prompt that specifies the allowed tools, the expected result format, the stopping condition, the maximum number of retries, and what remains a direct call.

Official Sources: Programmatic Tool Calling · Using GPT-6 (OpenAI API documentation) · GPT-5.6 Announcement (OpenAI, July 9, 2026)

Key Takeaways

  • The model writes and executes JavaScript to coordinate its tools in an isolated environment managed by OpenAI
  • Enable it with the programmatic_tool_calling tool and the allowed_callers field on each tool
  • Your application executes only its functions and returns the caller field intact
  • Prefer it for filtering, aggregating, or chaining predictable calls; direct calling remains the rule for writes and approvals