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. The same Qwen2.5-VL 72B calls tools cleanly on one of our providers but is refused with a 400 on another — even though it is the same model. 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 we run on every model we add — 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

Every chat-and-reasoning model in our current catalog is served with tool calling verified on its lane. It is a curated selection, not the whole market, and the exact list is public on the model catalog. It spans Qwen (235B, Qwen3.5 397B, Qwen3 32B, Qwen3 Coder 30B), GLM-5.2, DeepSeek V4 Flash, Llama 3.3 70B, GPT-OSS 120B/20B, Mistral Small 3.2 24B, and the fast-access Kimi K3 lane.

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 works on one provider and fails 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 Kimi K3 lane is under non-EU control and is labeled accordingly, never advertised as 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 that stops at zero, and no non-EU jurisdiction in the loop.

FAQ