LearnGrokThe worst API failures are the ones that return 200. Because xAI's API is
OpenAI-shaped, several parameters are accepted for compatibility and then have no
effect: no error, no warning, no field in the response saying so. If you ported
code from another provider, this is the page to read.
Accepted and ignored
At the time of writing, the documentation describes these as unsupported, ignored, or maintained only for compatibility on the newer models:
- Log probabilities. The request fields are accepted and silently dropped, including the newer include-style form. If you are building anything that depends on token probabilities, confidence scoring, constrained decoding checks. Verify it works before you build on it.
- Logit bias. Marked unsupported.
- Metadata and truncation fields on the responses surface: present for compatibility, not acted on.
- Background execution on the responses surface: marked unsupported.
- Context-management fields: parsed, but not yet acted on.
- Some remote-tool approval fields carried over from the OpenAI shape are not currently supported.
The pattern is consistent: xAI accepts the OpenAI request shape so existing SDKs work, and quietly no-ops the parts it does not implement. Convenient for porting, dangerous for correctness.
Silently downgraded: not rejected
Reasoning effort. Ask for a level a model does not support and it is treated as the nearest supported one rather than refused. Your request succeeds, costs what that level costs, and does not do what you asked.
Priority processing. If priority capacity is unavailable, you are served at the default tier with no error. The response tells you which tier actually served you; read that field rather than assuming you got what you paid for.
Search tool conflicts. Specify both a preview-style search tool and explicit search parameters, and the parameters win. Nothing reports the conflict.
The cache diagnostic
Prompt caching has no error path: a miss is normal and your application must work without it. So the only signal that caching is not working is a cached-token count that is consistently zero.
If you see that, the usual causes are a missing conversation or cache key on the request, or a history you are mutating between calls so no prefix ever repeats. Neither produces an error; both quietly double your cost.
Tool calls that failed without failing
Server-side tools can fail (a page that does not exist, a deleted post, a transient pipeline error) and the model recovers and carries on. Your request succeeds. The evidence is in the difference between the number of tool calls attempted and the number recorded as successful. If a result looks thin, compare those two before assuming the model was lazy.
How to defend against all of this
- Log the response fields, not just the text. Service tier, cached tokens, finish reason, tool-usage counts. Every silent failure above is visible in a response field, and invisible if you only read the content.
- Assert on behaviour, not on acceptance. A 200 means the request parsed. It does not mean the parameter did anything.
- Re-test after a model change. Support for these varies by model, so the parameter that worked on one is not guaranteed on its successor.
- Check the reference, not just the guide; see below.
When the documentation disagrees with itself
Worth knowing rather than discovering at runtime: xAI's guides and their REST reference do not always agree. At the time of writing they differed on which models accept a reasoning-effort setting and what its default is, on the maximum number of tools per request, and on maximum file size.
Where two pages conflict, do not assume either is right. Test the specific behaviour against the specific model you are calling, and treat your own observation as the tiebreak.
What changes
Which parameters are honoured is model-dependent and moves with each release. Confirm anything load-bearing against the API reference for the model you are actually calling.
