[Bug]: AgentRouter 400 content-blocked under burst traffic; characterize pacing/retry mitigation #1689

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:

1. the number/timing of requests before the failure appears;
2. whether the same unchanged request succeeds after an idle interval;
3. whether serializing or pacing the same requests prevents the failure;
4. whether the failure consumes/bills the upstream model request or is rejected before model execution;
5. 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

• Non-English/content-dependent WAF behavior: [Research]: AgentRouter content-blocked responses correlate with non-English first prompts #1804.
• Prefixing an English preamble or otherwise modifying user message content.
• Treating every HTTP 400 as retryable.

Relationship

• [Research]: AgentRouter content-blocked responses correlate with non-English first prompts #1804 is the split research issue for language/content-dependent blocking.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.
• Controlled current-dev burst/pacing evidence is still required before implementation.