Summary
This issue now tracks only the burst-sensitive AgentRouter failure mode.
Providers routed through agentrouter.org can return HTTP 400 with error.code: "content-blocked" after several requests arrive in a short period. Reports indicate the gateway relaxes again after an idle interval.
The language/content-dependent report has been split into #1804 because it has a different cause, evidence requirement, and risk profile. This issue does not authorize rewriting or prefixing user prompts.
Area
Provider adapter / outbound pacing
Reproduction
Provider shape:
{
"providers": {
"AGR-CLA": {
"adapter": "anthropic",
"baseUrl": "https://agentrouter.org",
"authMode": "key"
}
}
}Send several otherwise-valid requests rapidly enough to reproduce the gateway's burst behavior, for example a tool-using client generating multiple turns in quick succession.
Observed error shape:
{
"error": {
"code": "content-blocked",
"type": "agent_router_api_error"
}
}Current problem
A burst-sensitive 400 content-blocked is terminal to the active turn. OpenCodex currently has no established AgentRouter-specific contract telling it whether this response is safely retryable, how long to delay, or whether normal provider request pacing should absorb the burst before dispatch.
Evidence required
Before adding provider-specific retry semantics, provide a controlled current-dev capture that establishes:
- the number/timing of requests before the failure appears;
- whether the same unchanged request succeeds after an idle interval;
- whether serializing or pacing the same requests prevents the failure;
- whether the failure consumes/bills the upstream model request or is rejected before model execution;
- authoritative AgentRouter documentation for retryability or pacing, if available.
A third-party implementation can be useful reproduction evidence, but it is not by itself the AgentRouter contract.
Candidate implementation direction after evidence
Prefer the existing generic provider request-pacing/retry architecture over hidden prompt changes or an unrelated adapter fork.
Any accepted mitigation should:
- be narrowly scoped to the proven failure class;
- avoid replay when the upstream execution outcome is ambiguous;
- preserve cancellation and request accounting;
- use bounded retry/backoff or pre-dispatch pacing rather than an unbounded loop;
- keep non-AgentRouter providers unchanged.
Exact delays, attempt counts, and retry status classification should come from evidence rather than copying constants from another project.
Out of scope
Relationship
Checks
Summary
This issue now tracks only the burst-sensitive AgentRouter failure mode.
Providers routed through
agentrouter.orgcan returnHTTP 400witherror.code: "content-blocked"after several requests arrive in a short period. Reports indicate the gateway relaxes again after an idle interval.The language/content-dependent report has been split into #1804 because it has a different cause, evidence requirement, and risk profile. This issue does not authorize rewriting or prefixing user prompts.
Area
Provider adapter / outbound pacing
Reproduction
Provider shape:
{ "providers": { "AGR-CLA": { "adapter": "anthropic", "baseUrl": "https://agentrouter.org", "authMode": "key" } } }Send several otherwise-valid requests rapidly enough to reproduce the gateway's burst behavior, for example a tool-using client generating multiple turns in quick succession.
Observed error shape:
{ "error": { "code": "content-blocked", "type": "agent_router_api_error" } }Current problem
A burst-sensitive
400 content-blockedis terminal to the active turn. OpenCodex currently has no established AgentRouter-specific contract telling it whether this response is safely retryable, how long to delay, or whether normal provider request pacing should absorb the burst before dispatch.Evidence required
Before adding provider-specific retry semantics, provide a controlled current-
devcapture that establishes:A third-party implementation can be useful reproduction evidence, but it is not by itself the AgentRouter contract.
Candidate implementation direction after evidence
Prefer the existing generic provider request-pacing/retry architecture over hidden prompt changes or an unrelated adapter fork.
Any accepted mitigation should:
Exact delays, attempt counts, and retry status classification should come from evidence rather than copying constants from another project.
Out of scope
Relationship
Checks