If we turn on “Strict=True” in the function calling schema, then we have to list all of our fields under “Required”. This is a rule that Open AI API forces us to follow. It causes issues in application development. Does anybody have any idea? Why do we have to list all fields under “Required”
How would you expect strict mode to work? 
Disabling it is always an option. If you struggle with instruction adherence, it might be a good idea to refine your prompt.
Another idea would be simplify your function signature (schema). Is that an option?
The closest alternative is to use JSON mode, where you suggest a JSON schema to the model but do not always get valid JSON in return. Structured outputs, on the other hand, essentially guarantees that the output adheres to a specific schema.
If you want to develop using structured outputs, a possible workaround is to allow the model to return a null value for fields that are not required for you at a given point in time.
https://platform.openai.com/docs/guides/structured-outputs#all-fields-must-be-required
The requirement comes down to:
- strict means all objects and keys are indeed required and no extra keys can be added by the AI;
- a standard JSON schema is used, instead of a proprietary construct, with methods that can directly translate to other schema generators such as Pydantic or Zod that actually make your programming easier;
- the schema you give is directly placed to the AI context also, leveraging the AI’s understanding of JSON and JSON schema validation, instead of an internal format (like function call specification namespace) that relies on new post-training.
Why doesn’t OpenAI fill in any missing “required” fields or place “additionalProperties” for you? Because that is a leap: you might actually be using a schema generator wrong, in a way that would not validate the AI’s output. You might have misplaced expectations, intending that the AI could optionally choose to use just some keys, or generate its own objects, but that is not possible.
The JSON schema is much more than just an instruction to the AI though. It programmatically generates an enforcement mechanism so the AI can writing nothing else but that JSON and its allowed keys.
I was unable to make the AI read my mind of what I wanted to write and save me work, but here’s some technical background that might interest you, informing why it is important to provide a validating JSON schema and what is done with it when “strict”.
Structured Outputs – a feature designed to ensure that model responses strictly adhere to a given JSON format or schema. Internally, OpenAI employs a constrained decoding mechanism to enforce the schema. In OpenAI’s own documentation, this is described as constructing a schema artifact based on the developer-provided JSON Schema and using it to constrain the model’s token generation process. In other words, the model’s output distribution is dynamically restricted so that it can only produce tokens that keep the output valid according to the specified schema. This goes beyond mere prompting or the model’s learned formatting skill – it’s a low-level enforcement at the logit (pre-softmax score) level, often referred to as grammar-based constrained decoding.
Grammar-Based Logit Masking Implementation
How it works: OpenAI converts the supplied JSON Schema into an internal context-free grammar (CFG) representation. This CFG defines all allowed sequences of tokens that constitute a valid JSON document under the given schema rules. Before generation, the API preprocesses the schema into a fast, cached data structure (the “schema artifact”) that can be consulted during decoding. At inference time, after each token the model generates, the decoding engine evaluates the partial output against the grammar to determine which tokens are valid next. All tokens that would violate the JSON syntax or schema (e.g. producing a comma in the wrong place, an invalid field name, an extra bracket, etc.) are masked out – essentially their probabilities are forced to zero. This dynamic logit masking ensures that every next token sampled must be one that keeps the output JSON valid and schema-conformant. OpenAI explicitly describes this approach as “constrained sampling”, where the model “only [selects] tokens that would be valid according to the supplied schema”. By continuously updating the valid-token set after each token, the system prevents any deviation from the required JSON format at every step.
This implementation is fundamentally a form of grammar enforcement at decode time. It functions like a parser guiding the generator: the grammar acts as a guardrail, and the model’s free-form text generation is constrained within those rails. If the model, for example, tries to output a natural language apology or any text outside the JSON (which would normally be possible from a purely learned standpoint), the grammar-based filter would block those tokens entirely. The result is that even if the model “wants” to stray, the decoding process won’t allow invalid tokens, guaranteeing a syntactically correct JSON structure. OpenAI’s blog notes that their approach generalizes beyond simpler finite-state methods by using a full context-free grammar, which can handle complex or nested schemas (even recursive structures) that simpler state-machine or regex-based filters might not capture. In summary, the implementation involves dynamic logit masking guided by a compiled grammar, ensuring the output stays valid at each token step.
response_format and strict=True Integration
OpenAI’s API exposes this mechanism through parameters like response_format and the strict flag. When a developer supplies a JSON schema via the API using the response_format: {type: "json_schema", ...} option) and sets strict: true, the Structured Outputs feature is activated. In strict mode, the model is guaranteed to produce output that matches the schema exactly, because the constrained decoding is in effect. Under the hood, setting strict=true triggers the construction of the aforementioned schema artifact (the grammar) for the given schema, scoped per developer/organization and cached for reuse. During generation, this artifact “enforces a structured pattern on the logit generation process” – meaning the token-level filtering is applied – so any token sequence that would break schema compliance is simply never produced.