"Extra inputs are not permitted, field: safety_identifier": OpenAI-only parameters rejected by Kimi and other strict hosts
OpenAI keeps adding optional request fields: safety_identifier replaced user for abuse tracking, store and metadata feed its dashboard, prompt_cache_key steers its cache. Clients built on the OpenAI SDK send them to every "OpenAI-compatible" endpoint. Most hosts ignore what they do not understand. Moonshot validates the request against a strict schema and rejects the whole call for one unknown field, so a tool that works against OpenAI fails against Kimi with nothing changed but the base URL.
Last verified September 18, 2026 against anomalyco/opencode #20133 (👍11), Kilo-Org/kilocode #11521 · 3 min read
| Provider | Moonshot AI (api.moonshot.ai); a few other hosts validate the same way |
| HTTP status | 400 Bad Request |
| Message | Extra inputs are not permitted, field: 'safety_identifier' (the field name varies) |
| Parameters reported | safety_identifier, store, metadata, prompt_cache_key, service_tier |
| Who hits it | opencode (its OpenAI-compatible helper adds safety_identifier), Kilo Code, anything on a recent OpenAI SDK with those options set |
| Can you wait it out? | No |
- Your own code: do not set the OpenAI-only options when the base URL is not OpenAI's, or send them through a host that ignores them.
- opencode: the report is closed as fixed; update to a current release.
- Any host: the table below says which fields are safe where.
What the error looks like
Error: Extra inputs are not permitted, field: 'safety_identifier'The message names the offending field. Fix that one and the next unknown field, if any, produces the same error, so check the whole request once rather than one field at a time.
Which parameters, and which hosts
| Parameter | Sent by | Moonshot | Inference APIs |
|---|---|---|---|
safety_identifier | opencode (all providers), OpenAI SDK helpers | 400 | Accepted and ignored |
store | Codex CLI, Responses API clients | Rejected by some hosts | Accepted and ignored |
metadata | LangChain, LlamaIndex tracing | Rejected by some hosts | Accepted and ignored |
prompt_cache_key | OpenAI SDK | Rejected by some hosts | Accepted and ignored |
service_tier | OpenAI SDK | Rejected by some hosts | Accepted and ignored |
user | Almost every client | Accepted | Accepted and ignored |
max_completion_tokens | OpenAI SDK, Codex, Copilot | Accepted | Accepted (same as max_tokens) |
stop | Aider, Continue, custom code | Accepted | Accepted; dropped for GPT-OSS with header X-Dropped-Params: stop |
"Accepted and ignored" means the request succeeds and the field has no effect. That is what OpenAI-compatible should mean for optional fields; strict validation is a choice some hosts make. Neither is wrong, but you need to know which you are talking to.
Fix
In the OpenAI Python SDK, the fields are only sent if you set them, so remove them from the call when the base URL is a third party. opencode closed #20133 as fixed; if you still see it, update. For frameworks that inject metadata for tracing, most have a per-provider switch.
If you would rather not audit every client, use a host that ignores unknown optional fields. Ours does; the exact request that fails on Moonshot with all five fields set succeeds here on Kimi K2.7 Code.
Frequently asked questions
Is safety_identifier the same as user?
OpenAI introduced it as the replacement for the abuse-tracking use of user. Third-party hosts do not use either for that purpose.
Why does the same request work on OpenRouter?
Gateways normalise requests per provider before forwarding. A direct call to Moonshot gets no such translation, so the client's request has to be clean.
Where Inference APIs fits
Our endpoint accepts every parameter in the table and ignores the ones the upstream model does not use, so a client that sends safety_identifier, store or metadata works unchanged against all nine chat models, Kimi K2.7 Code included. Tested September 18, 2026.
Something changed or wrong? Tell us and we will re-verify the entry.