Tool-call format compatibility across 31 cloud models · V1
Tool-Calling Compatibility
- structured JSON
- 24
- XML / text
- 5
- other failure
- 4
- compatible rate
- 77%
Where the agentic boundary breaks
| Model | Status | Failure mode |
|---|---|---|
| cogito-2.1:671b-cloud | FAIL · XML | Emits XML instead of JSON tool_calls |
| deepseek-v3.2:cloud | FAIL · XML | XML tool-call syntax |
| gemma3:4b-cloud | FAIL · XML | Text-format tool syntax |
| gemma3:12b-cloud | FAIL · XML | Text-format tool syntax |
| gemma3:27b-cloud | FAIL · XML | Text-format tool syntax |
| glm-4.6:cloud | FAIL · other | Wrapper preflight failure |
| glm-5:cloud | FAIL · other | Stuck in wait-loop (Codex sub-agent) |
| qwen3-coder-next:cloud | FAIL · other | 429 / preflight |
| qwen3-vl:235b-cloud | FAIL · VL-only | Vision-only routing |
Observed compatibility differences
Format is not a bug
It's a training decision
The XML-tool-call models (cogito-2.1, deepseek-v3.2, all gemma3 variants) were trained on a different function-calling format than the OpenAI-shape JSON that wrappers parse. The fix is upstream — a function-calling finetune on the OpenAI schema — not at the wrapper.
VL-only is structural
Visual-language models don't fit text-agent loops
qwen3-vl:235b is image-first; in text-only agentic loops it fails the routing pass before tool selection. Not a tool-call bug — a use-case mismatch.
Wait-loop is wrapper-side
glm-5 + Codex's wait() pattern
GLM-5 stuck Codex in an infinite wait() loop — Codex spawned 6 sub-agents that all returned but the parent never recognized completion. Not GLM-5's fault — a Codex sub-agent state machine bug surfaced by GLM-5's particular response shape.
77% baseline
Most modern models pass
The Ollama-cloud ecosystem has converged on OpenAI-shape tool calls. Outliers exist but the median is compatible. New deployments can assume tool-call compatibility — but should sanity-check each model in a 30-second smoke run before committing.