Which OpenAI chat-completion parameters does xAI's Grok 4 family reject?

## The trap: compatible shape, per-model semantics "OpenAI-compatible" describes the envelope — a `/chat/completions` path, a `messages` array, a bearer key. It does not promise that every field OpenAI defines is honoured by every model behind that envelope. xAI is explicit about this: certain parameters are documented as unsupported on particular Grok model lines, and the flagship reasoning line is the one with the longest exclusion list. ## What grok-4 does not accept As documented by xAI, the grok-4 family does not support: - **`presence_penalty`** and **`frequency_penalty`** — the repetition-discouraging logit adjustments. - **`stop`** — client-supplied stop sequences. - **`reasoning_effort`** — the effort dial, which is meaningless here because the model reasons as part of its normal operation rather than on request. The important detail is the failure mode: these are **rejected**, not ignored. A request carrying them comes back as a client error. Silent ignoring would hide the mismatch and quietly change behaviour; an explicit error tells you immediately that your abstraction over-assumed. But it also means that any layer which always sends a fully populated parameter object — many gateways, ORM-ish wrappers and framework integrations do exactly this, filling unset knobs with defaults — will fail 100% of requests against that model until it is taught to omit them. ## Why the gaps exist Stop sequences and repetition penalties are decode-time interventions on the token stream. On a model that produces an internal reasoning pass before its visible answer, both are awkward: a stop sequence can cut the model off inside its own thinking, and penalties applied across a long internal trace distort it in ways the vendor cannot make safe generically. Rather than implement a subtly wrong version, xAI declines the parameter. `reasoning_effort` is excluded for the opposite reason — the model has no low-effort mode to select. ## What to do about it in production **Keep a capability matrix.** A small map from model id to the set of parameters that model accepts, resolved at request-build time. Sending is opt-in per model, not opt-out. Store it in configuration, not code, so onboarding a new model line does not need a deploy. **Never send defaults.** The root cause of the failure is usually a request builder that serialises every field of a settings object, turning "the user did not set a stop sequence" into `stop: []` on the wire. Omit unset fields entirely. **Classify errors correctly.** An invalid-parameter 4xx is permanent: retrying with backoff burns budget and latency for a result that cannot change. Your client should retry rate-limit and transient server failures, and fail fast — with the offending field named in the log — on parameter validation errors. Teams that lump all non-2xx responses into one retry path turn a five-minute fix into a mystery outage. **Replace the capability, not the parameter.** If you genuinely need the effect of `stop`, do it client-side: stream and cut the output when your delimiter appears, or ask for structured output so the boundary is syntactic rather than lexical. If you were using penalties to fight repetition, the honest answer on a reasoning model is usually a prompt change, since the model's decode strategy is not yours to tune. **Test the matrix, not the vendor.** A tiny contract test per model that fires the parameters you intend to send catches drift when xAI adds or removes support, which happens with new model generations. This matters more than usual here because the exclusions are attached to model families, and model families turn over fast. ## The general lesson This question is really about how you model multi-provider capability. The naive design assumes a lowest-common-denominator parameter set works everywhere; the mature design treats each model as a capability profile and makes the request builder ask what this specific model supports. That design also survives the inverse case — vendor-specific fields such as xAI's search parameters that no other provider understands — because both directions are just entries in the same matrix.