Open-source models with tool calling (measured)

What tool calling actually is

Tool calling (a.k.a. function calling) is the mechanism behind every agent framework. You declare the available functions — with names, descriptions, and JSON schemas for their arguments — and when the model decides it needs to act, it emits a structured tool_calls object instead of plain text. The runtime executes the function and feeds the result back; the model then continues. That loop — model → tool → result → model — is the entire foundation of agents, API integration with external services, and workflows that touch the outside world.

A model that cannot do this reliably cannot be an agent; it can only chat. So the question “which open-source model supports tool calling” is really “which models can I build an agent on, and which lanes actually serve that ability”.

It is a property of the serving stack

Here is the part that surprises people who only read model cards: tool calling is not fully determined by the weights. It depends on whether the serving framework and the provider have wired up the tool-calling path — the special tokens, the schema parser, the tool_calls response contract. A provider can refuse the feature, return it malformed, or simply not support it on a given deployment.

We have concrete evidence of this in our own routing. Qwen2.5-VL 72B is built for agent use — its model card says it “can reason and dynamically direct tools” — yet OVHcloud, which serves it for us, refused tool calls with a 400 (“feature 'tool calls' is not currently supported”, measured on 6 August 2026), so on our catalog it was live without tool calling (it has been paused since 20 October 2026, OVHcloud being unavailable to us). Pixtral 12B, the vision model Scaleway serves for us in its place, does answer tool calls (measured on 20 October 2026). That is why, on our catalog, toolCalling is a per-entry field measured by a real call on the lane that actually serves it, never assumed from the weights or copied between providers.

How to verify it in one call

You do not need a benchmark to know whether a lane serves tool calling. Run one small real call:

1. Declare a trivial function — say get_weather(city) with a JSON schema.
2. Send a prompt that clearly requires it, e.g. “What's the weather in Paris?”.
3. Inspect the response: you want a valid tool_calls array with a well-formed arguments JSON object.

That is exactly the test behind every tool-calling flag in our catalog — our registry notes even record the city used (a get_weather on Paris for DeepSeek V4 Flash, Lyon for Llama 3.3 70B on OVHcloud). A clean, parseable tool_call with correct JSON is the difference between an agent that works and a string of text that happens to look like a function call.

Failure modes in practice

When tool calling is not actually wired through the serving stack, the failure is rarely a hard error — it is a subtle degradation that looks like the feature is working. Three patterns dominate.

The argument-as-string trap. A model returns a tool_call whose arguments is a quoted blob or a prose description instead of a parseable JSON object. The call “succeeds”; your parser, expecting JSON.parse, throws. This is the single most common production failure and the reason we check for well-formed JSON in every verification, not just for the presence of a tool_calls key.

The silent text fallback. When it genuinely cannot call the tool, a model may decide to answer in prose — “I don't have a weather tool” — instead of emitting a tool_call. In an automated loop that quietly halts the workflow rather than erroring, which is harder to catch than a crash.

The hallucinated tool name. The model invokes a function that was never declared, or one with the wrong signature. The runtime rejects it, and unless your agent re-sends the request, that single turn is lost.

Each of these is why a benchmark that checks “did it occasionally return a tool_call” is not enough. The useful test is the one we run per lane: a required call, a strict check on name and parseable arguments and correct values. That is the bar an agent actually depends on.

Which models we route with tool calling

25 of the 25 live models in our catalog are served with tool calling verified by a real call on their lane. It is a curated selection, not the whole market, and the exact list is public on the model catalog.

Among those verified models, on the EU-sovereign lane (18 models): Qwen3 235B, Qwen3.5 397B, GLM-5.2, DeepSeek V4 Flash 0731, Llama 3.3 70B, Qwen3.6 35B A3B, Qwen3 Coder 30B, Pixtral 12B, GPT-OSS 120B, Mistral Small 3.2 24B, Mistral Large 4, Apertus v1.5 70B, Qwen3.8 27B, GLM-5.3, DeepSeek V4.1 Flash, Gemma 4 26B, Kolibri 1 and Mistral Small 4 119B. On fast access, served by US companies (7 models): Kimi K3, Muse Spark 1.1, Muse Spark 1.2, GLM-5.3 Flash, Qwen3.8 Flash, DeepSeek V4 Pro and Gemma 3 27B. Qwen3.6 27B, Qwen3.5 9B and GPT-OSS 20B, measured with tool calling, have been temporarily paused since 20 October 2026 on the provider side (OVHcloud): not callable for now, and back unchanged once the route is restored.

All of them are billed the same way — per token from prepaid credit, no subscription — so building a small agent to test tool calling costs fractions of a euro. You do not commit to a contract to find out whether a model can use tools; you measure it for cents.

Why this matters for agents

For agentic work, tool calling is not a checkbox — it is the core loop, and the failure modes are specific:

• Malformed arguments. A model that returns arguments as a string inside the wrapper, or with a schema mismatch, breaks every downstream parser.
• Missing tool_calls. A model that answers in text when you asked for a tool call silently breaks the loop.
• Lane-dependent behaviour. The same model can work on one provider and fail on another — exactly why capability must be verified on the lane you serve from.

So the practical advice mirrors our own process: pick the model, but verify tool calling on the provider lane you will actually use, with one cheap real call, before you wire an agent around it.

Tool calling on EU-sovereign infrastructure

Agentic workloads often touch sensitive data — a tool call can read an internal database or an inbox. If that data must stay under EU jurisdiction, you want a lane whose operator is outside non-EU control, not just a model that can call tools. All our tool-calling models that run on EU-owned operators are labeled sovereign; the fast-access lanes (Modal, OpenRouter) are under non-EU control and are labeled accordingly, never advertised as sovereign. A model labeled sovereign never leaves the sovereign lane unless you explicitly opt in, and every response says which provider served it (x-routed-provider, x-sovereign).

The combination you would actually want — open-source weights, verified tool calling, and EU-sovereign hosting — is exactly what the sovereign lane of the catalog exists to provide: one OpenAI-compatible call, a prepaid balance, and an EU-controlled inference provider. Calls are refused once the balance reaches zero (a call already running can take it slightly below; the difference comes off your next top-up). One caveat we state everywhere: the gateway itself runs on Vercel's Paris region, and Vercel is a US company — prompts and responses pass through it in transit and are never stored there (see our privacy policy).

FAQ