Hi team, I am encountering a schema validation error when making tool-calling requests via the HTTP interface using the AI Gateway. The issue specifically happens when routing the request to AWS Bedrock.
Important Context (Recent Regression):
This exact implementation was working perfectly fine yesterday (April 16, 2026). The error just started occurring today (April 17, 2026) without any changes to my request payload. This strongly suggests that a recent update or deployment to the AI Gateway introduced this breaking change.
Error Message
{
"error": "tools.0.custom.eager_input_streaming: Extra inputs are not permitted",
"statusCode": 400
}
Steps to Reproduce
I am calling the HTTP interface directly.
When I set the providerOptions to route only to Bedrock, the request fails with the error above:
providerOptions: {
gateway: {
only: ['bedrock'] // ❌ Fails with 400 Extra inputs are not permitted (Since April 17)
}
}
However, if I change the routing to only Anthropic, the exact same request payload works perfectly fine:
It appears a recent update to the AI Gateway / AI SDK automatically injects a custom: { eager_input_streaming: ... } metadata field into the tools definition.
Since the same request works with only: ['anthropic'] but fails with only: ['bedrock'], I’d treat this as a Gateway → Bedrock request translation/schema issue first, not an auth issue.
providerOptions.gateway.only is the right kind of option for restricting routing, but Bedrock seems to be rejecting an extra field inside the tool definition:
tools.0.custom.eager_input_streaming: Extra inputs are not permitted
A useful isolation test would be to run three tiny requests against the same model/provider route:
no tools at all
one minimal tool with only name, description, and input_schema / parameters
your real tool payload
If #1 works and #2/#3 fail only on Bedrock, that narrows it to tool schema serialization rather than model access or Gateway auth.
I’d also check whether your HTTP request is manually including any custom object under tools. If it is, remove that for Bedrock. If it is not in your payload and Gateway is adding it internally, then the best bug report would include:
status code
redacted request body
redacted response body
model ID
providerOptions.gateway.only value
timestamp
x-vercel-id / request ID if present
The Gateway provider options docs are here for comparison:
As a temporary workaround, I’d route tool-calling requests away from Bedrock or remove provider-specific/custom tool metadata when forcing Bedrock, then keep the smallest failing repro for Vercel to inspect.