Claude Function Calling vs OpenAI Function Calling

Claude and OpenAI both let a model decide when to call a function instead of just generating text, but the implementations are not interchangeable. Anthropic calls this "tool use," OpenAI calls it "function calling" (and more recently folds it into the "tools" parameter too), and while the concepts overlap, the request/response shapes, forcing behavior, and streaming semantics differ enough that code written for one won't run against the other without changes.

If you're deciding which to build against, the short answer is: both are production-ready, both support JSON Schema for parameters, and both support multiple tool calls per turn. The differences show up in the details — how you force a specific tool, how parallel calls are represented, how results get fed back into the conversation, and how verbose the response payloads are. Below is a side-by-side breakdown.

How Tool Definitions Differ

Both APIs want a JSON Schema describing the function's inputs, but the field names and nesting differ.

OpenAI wraps the function inside a tools array with type: "function":

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get current weather for a city",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string" }
      },
      "required": ["city"]
    }
  }
}

Claude flattens that one level — name, description, and input_schema sit directly on the tool object:

{
  "name": "get_weather",
  "description": "Get current weather for a city",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}

Functionally equivalent, but if you're translating a tool definition programmatically, this is the first thing to normalize. SubToAPI's /v1/messages endpoint speaks the Claude tool format directly, so if you already have Anthropic-shaped tool schemas, nothing needs converting — see /docs/tools for the exact payload.

Forcing a Tool Call

Sometimes you don't want the model to choose freely — you want it to always call a specific function (common for structured extraction).

• OpenAI: tool_choice: { "type": "function", "function": { "name": "get_weather" } }
• Claude: tool_choice: { "type": "tool", "name": "get_weather" }

Both also support "auto" (model decides) and a way to disable tools entirely for a turn. Claude additionally has tool_choice: { "type": "any" }, which forces some tool call but doesn't pin it to one specific function — useful when you have several tools and want to guarantee structured output without biasing toward one of them. OpenAI doesn't have a direct equivalent; the closest workaround is listing only the relevant subset of tools for that call.

Parallel Tool Calls

Both models can request multiple tool calls in a single turn, but they represent it differently.

OpenAI returns an array of tool_calls on the assistant message, each with its own id and function.arguments as a JSON string:

"tool_calls": [
  { "id": "call_1", "function": { "name": "get_weather", "arguments": "{\"city\":\"Paris\"}" } },
  { "id": "call_2", "function": { "name": "get_weather", "arguments": "{\"city\":\"Lyon\"}" } }
]

Claude represents each tool request as a tool_use content block inside the content array, with input already parsed as an object (not a string you need to JSON.parse):

"content": [
  { "type": "tool_use", "id": "toolu_1", "name": "get_weather", "input": { "city": "Paris" } },
  { "type": "tool_use", "id": "toolu_2", "name": "get_weather", "input": { "city": "Lyon" } }
]

That pre-parsed input object is a small but real convenience — one less failure mode (malformed JSON strings) to handle in your tool-execution loop.

Feeding Results Back

Both APIs require you to send tool results back in a follow-up message before the model continues. OpenAI uses a role: "tool" message keyed by tool_call_id. Claude uses a user message containing a tool_result content block keyed by tool_use_id:

{
  "role": "user",
  "content": [
    { "type": "tool_result", "tool_use_id": "toolu_1", "content": "18°C, partly cloudy" }
  ]
}

This is also where SubToAPI stays transparent: since it's a pass-through API over your own Claude access, the request and response bodies are the standard Anthropic /v1/messages shape — the same tool_use/tool_result pattern, just behind your sub_live_ key instead of a raw Anthropic key. Full request examples are in /docs/messages.

Streaming Tool Calls

Streaming tool use is where the two diverge most in practice. OpenAI streams function arguments as incremental string deltas that you concatenate and parse once complete. Claude streams input_json_delta events inside content_block_delta, which you accumulate the same way — concatenate the partial JSON string, parse at the end. Neither API gives you a "live" partially-parsed object mid-stream; both expect you to buffer until the block closes. If you're building a streaming tool-use integration against SubToAPI, the event structure mirrors Anthropic's SSE format one-to-one — see /docs/streaming for the event types to handle.

Which Should You Use

If you're already standardized on one provider's SDK and prompt style, the function-calling differences alone rarely justify a switch — model quality, cost, and latency usually matter more. But if you're starting fresh:

• Claude's pre-parsed input objects and the tool_choice: "any" option make multi-tool agent loops slightly less fiddly to implement.
• OpenAI's ecosystem has more third-party examples and framework support simply due to longer market presence.
• If your product is built around giving teams clean, metered access to Claude specifically — with per-key usage tracking and seat management — a service like SubToAPI (plans from €9/month, see /pricing) sits in front of your existing Claude access and exposes the same tool-use contract over HTTPS, so your internal teams build against one stable API instead of juggling raw provider credentials.

Either way, write your tool-execution loop (dispatch → execute → return result → continue) as a provider-agnostic function internally, and keep only the request/response mapping provider-specific. That's the part that actually changes if you ever switch.

Questions

Does Claude support parallel function calls like OpenAI? Yes. A single Claude response can include multiple tool_use blocks in one turn, and you can execute them concurrently before sending all results back in one follow-up message, same as OpenAI's tool_calls array.

Is Claude's input_schema the same as OpenAI's parameters? They're both standard JSON Schema objects describing the function's arguments. The content and rules (types, required fields, enums) are identical — only the wrapping field name and nesting level differ between the two APIs.

Can I use Claude's tool-calling format through SubToAPI without rewriting code? Yes. SubToAPI's /v1/messages endpoint mirrors the Anthropic Messages API, including tool_use and tool_result blocks, so existing Claude tool-calling code works unchanged against your sub_live_ key — see /docs/quickstart to get started.