Claude tool use vs OpenAI function calling

Claude tool use vs OpenAI function calling is the practical decision most teams hit when they graduate from single-shot prompts to agentic workflows. Both let a model emit structured calls to external functions, but the wire format, streaming behavior, and failure modes differ enough to shape your orchestration code. This post compares them on the dimensions that actually matter in production.

Capabilities

Both APIs let the model decide when to call a function and with what arguments, but the control surfaces are not identical.

OpenAI exposes tools in the chat completions request and returns tool_calls attached to an assistant message. You can force a specific function with tool_choice={"type":"function","function":{"name":"..."}} or allow auto. Parallel calls are supported: a single assistant message can carry multiple tool_calls.

from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role":"user","content":"Book a flight and a hotel in SF"}],
    tools=[{"type":"function","function":{"name":"book_flight","parameters":{...}}},
           {"type":"function","function":{"name":"book_hotel","parameters":{...}}}],
    tool_choice="auto"
)
# resp.choices[0].message.tool_calls may contain two entries

Claude uses a tools array on the Messages API and returns tool_use content blocks. Its tool_choice accepts auto, any (force at least one call), or {"type":"tool","name":"..."}. It also supports disable_parallel_tools to prevent concurrent calls when your backend isn’t thread-safe.

import anthropic
client = anthropic.Anthropic()
resp = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    tools=[{"name":"book_flight","input_schema":{...}},
           {"name":"book_hotel","input_schema":{...}}],
    tool_choice={"type":"any"},
    messages=[{"role":"user","content":"Book a flight and a hotel in SF"}]
)
# resp.content contains tool_use blocks, possibly multiple unless disabled

When evaluating Claude tool use vs OpenAI function calling for multi-step agents, the any mode and parallel-disable flag are genuinely useful levers. OpenAI’s tool_choice is simpler but lacks a native “force at least one, any which” without naming it.

Streaming behavior

OpenAI streams tool_calls as delta fragments; you concatenate function.arguments strings. Claude streams content_block_start for a tool_use block, then input_json_delta chunks. Claude’s partial JSON is easier to pipe to a incremental parser because each delta is a discrete key/value fragment rather than a raw string append.

Cost Model

Neither provider charges a separate “function calling” fee. You pay per input and output token. The tool schema is part of the input context on every request, so a 2 KB JSON schema costs the same tokens each turn. Output tokens include the serialized arguments the model emits.

Claude meters by token with a separate rate for input and output; OpenAI does the same. If you loop a tool result back into the context, those result tokens also bill. There is no free lunch: verbose schemas or large observation payloads dominate cost more than the call mechanism itself.

Latency and Throughput

Measured end-to-end, both add roughly one network round trip plus generation time for the arguments. Claude’s larger default context (200K tokens on Sonnet-class models vs 128K on GPT-4o) can mean slightly more prefill time if you pack the context, but that is a model property, not a tool-use property.

In practice, the bigger latency lever is client-side: parse streams early. OpenAI’s argument string concatenation is trivial; Claude’s structured deltas let you start validating the schema before the block closes. Both services handle batched requests similarly.

Ergonomics

Schema and SDK differences

OpenAI nests the schema under function.parameters using JSON Schema draft-07. Claude uses input_schema at the tool top level. Both validate against JSON Schema, but Anthropic rejects additional properties by default unless you say otherwise; OpenAI is more permissive.

Anthropic requires an explicit max_tokens on every call, which forces you to think about output bounds—a good discipline for agents. OpenAI’s chat endpoint has a default but will error if the model exceeds it.

Error handling

OpenAI returns finish_reason: "tool_calls" when the model stops to call a function. You must then append the assistant message with tool_calls and your tool result messages. Claude returns a stop_reason: "tool_use" and expects you to append an assistant turn containing the tool_use blocks, then a user turn with tool_result content.

# Claude round-trip skeleton
messages = [{"role":"user","content":"..."}]
resp = client.messages.create(model="claude-3-5-sonnet-20241022", max_tokens=1024, tools=tools, messages=messages)
messages.append({"role":"assistant","content":resp.content})
tool_results = []
for block in resp.content:
    if block.type == "tool_use":
        tool_results.append({"type":"tool_result","tool_use_id":block.id,"content":run_tool(block.name, block.input)})
messages.append({"role":"user","content":tool_results})

The Claude shape is more explicit about the tool_use_id linkage; OpenAI uses id on each tool_call and matches via tool_call_id in the result message.

If you route through a gateway such as n4n.ai, both appear behind one OpenAI-compatible endpoint, and you get automatic fallback when a provider is degraded without rewriting the above loops.

Ecosystem

OpenAI function calling has been in the wild longer. LangChain, LlamaIndex, and most agent frameworks assume the tool_calls shape. Claude tool use is natively supported in Anthropic’s SDK and increasingly in those frameworks, but you may hit rough edges in older middleware.

For a greenfield service, either is fine. If your stack already speaks OpenAI’s wire format, swapping in Claude requires an adaptation layer unless you use a translation proxy.

Limits

Known constraints: GPT-4o supports 128K context; Claude 3.5 Sonnet supports 200K. Both cap the number of tools implicitly via context size—hundreds of tool definitions will eat tokens fast. Neither documents a hard cap on parallel calls, but your orchestrator should bound concurrency.

OpenAI limits messages array size by total tokens; Claude similarly. Both will reject malformed schemas at request time.

Comparison Table

Which to Choose

The Claude tool use vs OpenAI function calling decision should follow your constraints, not hype.

Choose OpenAI function calling if:

• You already run GPT-4o or older OpenAI models in production.
• Your agent framework (LangChain, etc.) assumes the tool_calls shape.
• You need the broadest community examples for debugging.

Choose Claude tool use if:

• You need 200K context to keep long tool histories without summarization.
• You want explicit control over parallel calls via disable_parallel_tools.
• You prefer structured streaming deltas for incremental validation.

Choose a mixed or routed approach if:

• You want fallback when one provider rate-limits; a unified gateway keeps your orchestration code unchanged.
• You benchmark both per task and switch on latency or quality.

For most teams shipping a first agent, start with the provider you already bill for. The wire differences are a day of adapter code, not a rewrite. The real cost is in schema design and context management, which neither API solves for you.