It worked on the first message and died on the fourth. Here are the six causes, ranked by how often they actually happen, and how to tell which one is yours in under two minutes.
The message that gets you here is almost always the same shape.
"It was working. I sent three messages. The fourth one came back with this."
LLM request failed: provider rejected the request schema or tool payload
That is actually good news. A 400 is deterministic. Something in the payload is wrong every single time it is sent, which means it is findable.
Here is what nobody tells you about this particular error: the message is a catch-all. OpenClaw collapses at least six distinct failure modes into one string, so the error text tells you almost nothing about which one you hit. The fix depends entirely on that.
So let us sort them by how often they actually show up.
Cause 1: tool schemas replayed at a fallback provider
This is the big one, and it has a signature you can spot instantly.
Your agent works on message one, then dies on a later message right after a retry. That timing is the tell.
Here is the mechanism. OpenClaw prepares your tool definitions once, shaped for your primary model. The primary fails for some unrelated reason, a content filter or a timeout, and the router fails over to a second model. On a different provider. And it replays the same tool definitions, still shaped for the first provider.
Provider B has different rules about what is allowed in a tool input schema. It answers 400. This is documented in OpenClaw issue #64961, where an Azure GPT model returned a content filter error, failover went to Grok, and Grok rejected the untouched tool definitions.
The fix, in order of how quickly you can do it. Pin your agent to a single provider and remove cross-provider fallbacks. Or configure fallbacks only to models on the same provider with the same schema rules. Or update, because normalization on failover is exactly the kind of thing that gets patched.
If it works on message one and fails after a retry, stop reading the rest of this article. It is failover.
Cause 2: a JSON Schema keyword the provider will not accept
Every provider supports a different subset of JSON Schema in tool definitions, and the overlap is smaller than you would hope.
Gemini rejects patternProperties. Claude rejects anyOf in tool input schemas. Others get strict about nullable, deeply nested objects, or missing required arrays. OpenClaw carries provider-specific cleaning for some of these, but coverage is not universal and custom skills are where it breaks.
If you wrote or installed a skill and the error started immediately, this is your cause. Not failover. Custom skill schemas are the most common source of exotic keywords.
Strip the schema down to primitives. Flat objects, string and number and boolean types, explicit required, no unions. Then add complexity back one field at a time until it breaks, which takes about five minutes and tells you exactly which keyword the provider hates.
Cause 3: the model does not support tool calling at all
Sometimes the answer is boring. You pointed your agent at a model that cannot do function calling, and every request carrying tool definitions fails.
There is a clean diagnostic for this. Set compat.supportsTools: false and send a message.
If the failures stop completely, the tool surface was the problem. If they shrink but do not disappear, tool schemas were part of the pressure and there is a second issue underneath, usually message shape. That single toggle splits your remaining search space in half.
This is especially common with local models through Ollama, where the tag you pulled may simply not have tool support compiled in. We wrote a fuller breakdown of the model does not support tools error covering which models actually work.
Cause 4: the message array shape, not the tools
This one fools people because they spend hours auditing skills when the tools were never the problem.
Some backends reject a messages array that is system-only with no trailing user turn. ZAI and GLM have both been reported doing exactly this, in OpenClaw issue #68735. Others reject structured content parts and want a plain string. Others reject OpenAI-style replay metadata sitting on the message keys.
For that last one specifically, there is a config flag: models.providers.<provider>.models[].compat.strictMessageKeys: true, which restricts messages to the keys the backend will accept.
You can tell this apart from a tool problem with the Cause 3 toggle. Tools off, still failing, means look here.
Cause 5: reasoning parameters the provider will not take
Reasoning models added a whole new category of 400s in 2026.
The best documented case is a version of OpenClaw internally mapping reasoning_effort to a value the upstream router does not accept, which surfaces as this exact error even though your own config looked valid. Azure AI Foundry reasoning models produced the same failure after an April update, in issue #65603, where disabling reasoning fixed everything except tool-calling requests.
A related variant: some providers require fields from a prior tool-call turn to be echoed back on the follow-up request, and a router that drops them gets a 400 on the second turn of every tool round trip.
Fastest checks are setting thinkingDefault to "none" to take reasoning parameters out of the equation, or switching from a router to the model vendor's native API endpoint. We covered the DeepSeek flavour of this in detail in DeepSeek 503 and schema errors, including the exact config change.
Cause 6: something in front of the provider, not the provider
Rare, but it wastes the most time when it happens, because every diagnostic points at your payload and your payload is fine.
If there is a CDN, WAF, bot-management rule, or reverse proxy in front of an OpenAI-compatible endpoint, it can reject requests before they ever reach the model. The signatures are distinctive. Every model under that provider fails identically. You get HTML or generic security text instead of a structured provider API error. A tiny direct curl probe succeeds while normal SDK-shaped requests fail.
That last contrast is the giveaway. A real schema rejection fails the small probe too. A security layer usually lets the small one through.
How to work out which one you have in two minutes
Stop guessing and read the raw error. Run openclaw logs --follow and send the failing message again.
The gateway's wrapper string is generic, but the upstream 400 body underneath it usually is not. Providers name the offending field. That one line of raw text does more than an hour of config archaeology.
Three checks, in this order:
- Does it fail on the first message or only after a retry? Retry means Cause 1.
- Does turning tools off fix it? Yes means Causes 2 or 3, no means Cause 4.
- Does a minimal
curlto the same endpoint succeed while the agent fails? Yes means Cause 6.
A 400 from a provider is the provider working correctly. It is telling you the request was malformed. The bug lives in whatever built that request.
If you are chasing the same class of error on a different framework, the Hermes agent error 400 guide covers the equivalent failures there, and our agent error decoder will take a pasted error string and return the specific cause.
If you would rather not own this category of problem at all, start free on BetterClaw. One agent with every feature, no credit card. Pro is $49 a month for five agents, unlimited connectors, and 90-day memory, with 20 percent off annually. Full pricing here. If you are still deciding between running a framework yourself and using a managed builder, our overview of no-code AI agent builders lays out the tradeoff honestly.
The thing that makes this error so annoying
Every provider agreed to speak roughly the same API dialect, and then quietly disagreed about the details.
One rejects anyOf. One insists on a trailing user turn. One wants reasoning fields echoed back. Individually each rule is reasonable. Collectively they mean any tool that routes across providers is doing continuous translation work, and translation is where things break.
That is the actual lesson buried in this error message. It is not a bug in your config or a bug in the provider. It is the cost of a compatibility layer, showing up on the fourth message of an otherwise perfect afternoon.
Frequently Asked Questions
What does "the AI provider rejected this request" mean?
It means the model provider returned an HTTP 400 because the request body or tool JSON schema was malformed for its API. It is not a rate limit, an outage, or an authentication failure, all of which produce different status codes. The provider is behaving correctly and the malformed payload was built upstream of it.
How is this different from "model does not support tools"?
"Model does not support tools" is a specific, narrow case where the selected model has no function-calling capability at all. The provider rejection error is a catch-all that covers at least six failure modes, including schema keywords, message array shape, reasoning parameters, and failover replay, of which missing tool support is only one.
How do I find out which cause is mine?
Run openclaw logs --follow and resend the failing message so you can read the raw upstream 400 body rather than the wrapper string, since providers usually name the offending field. Then run three checks: does it fail only after a retry, does setting compat.supportsTools: false stop it, and does a minimal curl to the same endpoint succeed. Those three answers narrow it to one cause in about two minutes.
Is it worth switching providers to avoid this?
Sometimes, and it is often the fastest fix rather than the most elegant one. Moving from a multi-provider router to a model vendor's native endpoint removes an entire translation layer and with it most of this error class. The tradeoff is losing failover, so weigh it against how much downtime you can absorb.
Should I report this to Anthropic, OpenAI, or my provider?
No. A 400 invalid request error is the provider correctly refusing a malformed payload, so the issue belongs in the tracker of whatever assembled the request. If you can reproduce it with a minimal curl containing the same tool definitions, that reproduction is the single most useful thing to attach to a bug report.
