When you build an agent that orchestrates external APIs, the protocol-level differences in GPT-5 vs Claude vs Gemini 3 function calling dictate how you write your orchestration loop, handle partial failures, and budget latency. All three support tool use, but the wire format, streaming behavior, and constraints diverge enough that a naive abstraction will bite you in production.
Capabilities
All three models accept a list of tool schemas and can emit calls during generation. OpenAI’s GPT-5 returns tool_calls attached to an assistant message; Claude returns one or more tool_use content blocks; Gemini emits function_call parts inside a candidate. Parallel invocation is supported by each: GPT-5 can pack multiple tool_calls in one turn, Claude can emit multiple tool_use blocks, Gemini can yield several function_call parts.
Where they differ is strictness. Claude’s tool use is opinionated about JSON Schema subset—it rejects additionalProperties and demands type on every node. OpenAI is more lenient but still validates against a subset. Gemini accepts OpenAPI-ish declarations but historically flattens some complex nested structures. For agents that need guaranteed parseable args, Claude’s rigidity helps; for quick prototyping, GPT-5’s leniency reduces friction.
Streaming tool calls is non-negotiable for responsive agents. OpenAI streams tool_calls deltas with index and function.arguments fragments. Claude streams tool_use with incremental input JSON. Gemini streams function_call with partial args. All three require you to buffer and concatenate before parsing.
# OpenAI streaming tool call fragment
# chunk.choices[0].delta.tool_calls[0].function.arguments -> '{"lat":'# Claude streaming tool_use input fragment
# chunk.delta.partial_json -> '{"lat":'# Gemini streaming function_call args
# chunk.candidates[0].content.parts[0].function_call.args -> partial dictPrice and cost model
None of the three charges a separate “tool call” fee. You pay for input tokens (including the schema sent each request) and output tokens (including the emitted function name and arguments). The schema repetition can dominate cost in high-frequency agent loops. A 200-line JSON Schema sent 100k times per day is real money; minimize by caching schemas or using shorter descriptions.
GPT-5 vs Claude vs Gemini 3 function calling all count tool definitions as context, so context caching matters. Claude supports prompt caching on the system and tool prefix; Gemini has implicit cached context for repeated prefixes; OpenAI supports prompt caching on the tools block if stable. If you front requests with a gateway that honors provider cache-control hints, you keep the savings without per-provider code.
Latency and throughput
Measured p50 time-to-first-tool-call varies with model size and region. Smaller Claude variants typically return tool_use faster than the largest GPT-5 tier; Gemini’s distributed inference often yields low inter-token latency but occasionally batches function calls at turn end. For agent loops where you need to dispatch a tool within 300ms, benchmark your own traffic—don’t trust marketing.
Throughput under concurrency is provider-dependent. OpenAI’s tier limits are documented; Anthropic’s rate limits scale with trust; Gemini’s paid tier handles bursty agent fan-out. If a provider degrades, having automatic fallback at the gateway layer prevents agent stalls.
Ergonomics
The developer experience splits along SDK lines. OpenAI’s tools array is the de facto standard; many frameworks target it first. Claude’s input_schema is nearly identical but uses a different key and returns blocks instead of a message attribute. Gemini’s function_declarations mirrors the structure but nests under tools with a different envelope.
// OpenAI / GPT-5
{"tools":[{"type":"function","function":{"name":"get_weather","parameters":{}}}]}// Claude
{"tools":[{"name":"get_weather","input_schema":{}}]}// Gemini
{"tools":[{"function_declarations":[{"name":"get_weather","parameters":{}}]}]}Error handling ergonomics: OpenAI gives tool_call_id to map results; Claude requires you to echo tool_use_id in the tool_result block; Gemini expects you to feed back a function_response part. The round-trip shape is similar but not interchangeable without a translation layer.
If you standardize on the OpenAI schema and route through an OpenRouter-class gateway like n4n.ai, you get one OpenAI-compatible endpoint addressing 240+ models, and the gateway translates to Claude or Gemini wire formats while honoring your routing directives. That removes most ergonomic friction for multi-model agents.
Ecosystem
OpenAI’s tool ecosystem is largest: every major agent framework emits tools natively. Claude’s ecosystem is strong in TypeScript and Python SDKs with first-class tool_use typing. Gemini’s function calling is tightly coupled to Vertex AI and Google SDKs; if you’re already in GCP, the integration is smooth.
Community schemas: OpenAI’s community shares JSON Schema snippets widely; Claude’s docs enforce stricter examples; Gemini’s samples lean on protobuf-derived types. For an agent that must switch models at runtime, keep your schema to the common subset (no default, no nullable unions) to avoid rejection.
Limits
Context windows: Claude handles 200K tokens standard, Gemini sustains 1M+ context, GPT-5 tier-dependent but generally 128K–256K. Tool schema size eats into this. Max tools per request: OpenAI allows 128, Claude ~32 practical, Gemini 64. Parallel calls per turn are unbounded in theory but watch output token limits.
Rate limits: all three enforce requests-per-minute and tokens-per-minute; exceeding them triggers 429 with retry-after. Implement exponential backoff and jitter. Gemini may return RESOURCE_EXHAUSTED; Claude returns rate_limit_error; OpenAI rate_limit_error with type.
Comparison table
| Dimension | GPT-5 | Claude | Gemini 3 |
|---|---|---|---|
| Wire format | tools[].function + tool_calls |
tools[].input_schema + tool_use blocks |
tools[].function_declarations + function_call |
| Parallel calls | Yes (multiple tool_calls) |
Yes (multiple blocks) | Yes (multiple parts) |
| Streaming | Delta tool_calls |
Partial JSON in tool_use |
Partial args in function_call |
| Schema strictness | Lenient subset | Strict (no additionalProperties) |
OpenAPI-ish, flattens nested |
| Context window | 128K–256K | 200K | 1M+ |
| Max tools | 128 | ~32 practical | 64 |
| Ecosystem | Largest, framework-native | Strong TS/Py SDKs | Vertex/GCP coupled |
| Cost basis | Input+output tokens | Input+output tokens | Input+output tokens |
Which to choose
Latency-sensitive agent with simple tools: Use GPT-5 or a small Claude variant. If you need sub-second tool dispatch and have cached schemas, GPT-5’s lenient parsing reduces retry loops. Claude’s strictness adds a validation step but improves arg quality.
Long-context retrieval agent: Gemini 3 wins on context length. Feeding a 500K-token doc plus 20 tool schemas is trivial for Gemini; Claude will truncate; GPT-5 will cap. Use Gemini when the tool call depends on massive prior context.
Strict enterprise schema enforcement: Claude’s rejection of loose schemas forces your team to write correct JSON Schema. That pain upfront prevents malformed tool args in production. Pair with a gateway that caches the prefix.
Multi-model fallback requirement: Standardize on OpenAI tools shape and route via a compatible gateway. This lets you shift traffic between GPT-5 vs Claude vs Gemini 3 function calling without rewriting orchestration when one provider is degraded or rate-limited.
Cost-constrained high-volume loop: Minimize schema size, use prompt caching, and pick the smallest model that meets accuracy. Gemini’s throughput on paid tiers often yields lower cost per tool call at scale, but measure with your own traces.
Pick based on where the protocol leak hurts least: schema rigidity, context size, or SDK fit. The model that matches your existing orchestration code usually wins over marginal quality gains.