LLM API error · 400
Invalid request (400)
A 400 means the request body was rejected before the model saw it. The parameters that most often cause it, and how to find the offending field.
The message you are seeing
invalid_request_error: max_tokens: Field required
Invalid value for 'temperature': must be between 0 and 2.
What it means
The provider rejected the request structure before any inference happened. Something is missing, the wrong type, out of range, or not valid for the model you targeted.
The message usually names the field, which makes this one of the more tractable errors — the difficulty is normally that the field is being set somewhere you did not expect.
Why it happens
Most likely cause first.
- 1
A required field missing after a port
Anthropic requires max_tokens; OpenAI treats it as optional. Moving a request between providers without adding it produces this immediately.
- 2
A system message in the wrong place
OpenAI takes the system prompt as the first message in the array. Anthropic takes it as a separate top-level field and rejects a system role inside messages.
- 3
A parameter out of range
Temperature above the permitted maximum, top_p outside zero to one, or max_tokens above what the model allows.
- 4
Malformed content blocks
Empty message content, alternating roles broken, or a tool schema that is not a valid object. Common when messages are assembled programmatically.
How to fix it
Read the field name in the error
It is almost always named. Search your code for where that field is set — frequently in a shared helper that was written for a different provider.
Log the request body before sending
Redact the key, then look at exactly what your client serialised. What you built and what was sent differ more often than people expect.
JSON Validator with Token ReportParse errors with position, plus depth and the cost of your indentation.Regenerate the message structure rather than patching it
If the problem is message shape, build it from a known-good generator instead of hand-editing until it validates.
Chat Messages Array BuilderReadable conversation in, valid API payload out, in three formats.If porting between providers, convert properly
The system prompt and required fields differ. A mechanical conversion avoids the whole class of error.
OpenAI to Anthropic Format ConverterPort a payload between providers. Handles the system prompt difference.
Stopping it happening again
- Validate the request against the provider schema in your own code, so failures surface at build or test time rather than in production.
- Do not share one request builder across providers without an explicit adapter — the formats differ in ways that fail silently until they fail loudly.
- Log request bodies with the key redacted on any 400, so the next occurrence takes seconds instead of an afternoon.
Tools that help
- Chat Messages Array BuilderReadable conversation in, valid API payload out, in three formats.
- OpenAI to Anthropic Format ConverterPort a payload between providers. Handles the system prompt difference.
- JSON Validator with Token ReportParse errors with position, plus depth and the cost of your indentation.
Frequently asked questions
- Why does my request work with OpenAI but not Anthropic?
- Two differences account for most cases: Anthropic requires max_tokens, and it takes the system prompt as a top-level field rather than as a message with a system role.
- The error names a field I never set. Why?
- A default from your client library, a framework wrapper, or a shared configuration. Log the serialised body — the field is being set somewhere between your code and the wire.