Strict function calling in the OpenAI API guarantees one thing well: the arguments a model emits conform to the schema you supplied, on supported models and within a supported subset of JSON Schema. It does not guarantee that the values are correct, or that the call was appropriate. Most LLM tool calling limitations sit in that gap.
What strict mode guarantees
OpenAI’s function-calling guide describes strict mode as making calls reliably adhere to the function schema rather than being best effort. Strict mode requires additionalProperties set to false and every property marked as required. The guide frames the guarantee as structural.
The help center narrows it. According to OpenAI’s help article, the guarantee applies only on supported models and configurations, and only when the schema uses the supported JSON Schema subset. “Strict” is a property of a specific model and schema pair, not of the API as a whole.
Shape versus meaning
A schema-valid argument can still carry a hallucinated value: an order ID that does not exist, or a date in the wrong year. Structural validity tells the application that the call parses. It says nothing about whether the parameters are true, so application-side validation is still required. This is the author’s reading of the guide’s framing, which a GMI Cloud explainer also states.
How constrained decoding enforces shape
A secondary explainer from GMI Cloud describes constrained decoding as masking invalid tokens at each generation step, so that only grammar- or schema-legal continuations remain possible. An arXiv preprint (2609.23742) frames it the same way, as restricting allowable tokens at each step to conform to a grammar or schema. I have not independently checked that preprint’s method. The mechanism here rests on these two accounts and the vendor’s description of its guarantee.
Cost is poorly quantified. One source notes that complex schemas can add initialisation latency. A commonly quoted overhead figure is said to come from early implementations. I could not find a current measured figure, so none is given here.
Provider differences in enforced features
Vendors do not enforce the same keyword set. Secondary write-ups report that Anthropic’s structured-output grammar does not enforce numeric minimum and maximum, string length bounds, or array bounds beyond minItems of 0 or 1. Another reports that Claude’s strict mode rejects recursive schemas, minimum and maximum, string length constraints and external $ref. These reports differ in detail, and I could not confirm either against Anthropic’s primary documentation. Treat them as unverified and check current provider docs before relying on any keyword list.
Format constraints and reasoning quality
The most-cited study here is “Let Me Speak Freely?” (arXiv 2408.02442). Its authors report that format restrictions significantly reduced reasoning performance, and that stricter constraints generally caused greater degradation. The models were older: GPT-3.5, Gemini 1.5 Flash and LLaMA-3-8B. Parse errors were near zero even where scores fell, so the harm is not only parse failure. JSON mode helped on some classification tasks. Secondary summaries attribute part of the effect to key ordering that places the answer before the reasoning, which removes chain-of-thought. I have not verified that mechanism against the paper’s text. I have also left out the GSM8K drop figures in a secondary overview, because I could not check them against the paper.
ExtractBench (arXiv 2602.12247) gives a contrasting data point. Using each provider’s structured-output API reduced overall validity from 51% to 37%, compared with prompt-based extraction, and lowered the best-model pass rate from 6.9% to 5.5%. This is a single benchmark on complex extraction.
What the evidence does not show
I found no frontier-model replication of the format-reasoning result in the material reviewed. ExtractBench is one benchmark. Neither study shows that constraint is harmful in general. They show that, for some tasks and models, enforcing output format has cost accuracy.
Behavioural limits: prompt injection
Prompt injection success cannot be reduced to one rate. Published figures depend on the setup, the attack budget and whether the agent executes actions automatically.
- arXiv 2511.15759 reports 73.2% average attack success on a baseline, falling to 8.7% with a full defence framework.
- The AIShellJack study (arXiv 2509.22040) reports attack success for executing malicious commands on GitHub Copilot and Cursor ranging from 41% to 84%.
- arXiv 2407.20859, a malfunction-amplification study on an agent setup, reports that prompt injection raised average task failure to 32.1%. Adversarial perturbations had almost insignificant effects on GPT-4 failure rates.
Indirect injection, hidden in data an agent reads, is reported as the larger channel: 27.1% average success against 5.7% for direct attacks. The figures come from a challenge reported as 1.8 million attacks on 22 agents. I have only seen them through a StingrAI blog citing arXiv 2507.20526, which I have not opened.
A smaller reference point comes from arXiv 2610.23254. On AgentDojo, a frontier reference agent had 4 of 949 attacks succeed (0.4%), with 96.6% of failures classed as genuine refusals. The authors present this as a single run, not a scaling result. They also warn that low injection success can hide agents that simply fail to finish tasks, which is why they separate “ignored” from “refused” outcomes.
Why the numbers diverge
Attack budget (one attempt versus many), auto-execution, benchmark construction and model generation all differ between studies. In my reading, these differences explain most of the spread. A single percentage without its setup cannot be compared with another.
Judge-based guardrails and sequencing
OpenAI’s Guardrails framework uses LLM-based judges to flag jailbreaks and prompt injections, including tool calls that do not align with the user’s goal. HiddenLayer, a security vendor with a commercial interest in the question, argues that a judge running on a model vulnerable to the same injection can itself be compromised, and reports a bypass. I found no verified OpenAI response to that claim. The evidence on judge guardrails is contested, and I draw no general conclusion from it.
A 2025 preprint (arXiv 2512.23738) argues that existing guardrails rely on ad-hoc techniques and LLM validators, and lack formal guarantees for tool-call sequencing. It proposes checking the sequence against a specification and then constraining the model. Its example allows a call only if an authentication tool ran earlier. This is a single preprint, and its method has not been independently replicated in the material reviewed.
Practical controls and open questions
Practitioner guidance from promptessor and Wiz Academy converges on placing permissions outside the prompt: in the tool itself, the runtime, the identity system and OAuth scopes. This is vendor and blog consensus, not research. In practice, that means validating every argument server-side, enforcing authorisation in code, and treating even a well-formed call as possibly wrong or injected.
Three questions remain open. Does the format-reasoning effect hold for current frontier models? What are the current per-provider enforcement limits, which need confirming from primary documentation? And what is the measured grammar-compilation latency on current systems?