Summary
This issue tracks only the language/content-dependent half split from #1689.
Reports indicate that agentrouter.org may return HTTP 400 with error.code: "content-blocked" more often for benign Portuguese/Spanish first-user prompts than for equivalent English prompts.
This is separate from burst-sensitive failures. Request pacing, retry/backoff, and burst behavior remain tracked in #1689.
Why this is research / needs-info
The currently proposed workaround is to prepend an English instruction frame to the user's first message before forwarding it upstream. That changes user content and therefore changes request semantics. We should not adopt prompt mutation merely because it appears to bypass a third-party WAF.
Before implementing any OpenCodex-side language workaround, we need evidence that distinguishes:
- deterministic content filtering from burst/rate state;
- language effects from specific blocked phrases;
- gateway behavior from model/provider behavior;
- a supported provider contract from behavior inferred from a third-party reference implementation.
Evidence required
Please provide a controlled, redacted matrix against the same AgentRouter provider/account and current OpenCodex dev:
- Equivalent benign prompts in English, Portuguese, and Spanish, sent without burst traffic.
- Repeated runs after a sufficient idle period so prior WAF/burst state does not contaminate the comparison.
- Exact HTTP status and sanitized error code/type for each run.
- A control showing whether retrying the unchanged request after an idle period changes the result.
- If available, authoritative AgentRouter documentation describing the language/content filter contract.
Do not include credentials, full request identifiers, or sensitive prompt content.
Acceptance boundary
A fix should preserve user content unless there is an explicit, documented, opt-in compatibility policy with clear semantics.
A global or host-name-triggered hidden preamble is not an accepted implementation direction at this stage.
Potential outcomes after evidence:
- upstream/documentation-only guidance if this is intentional provider filtering;
- a provider-specific opt-in compatibility mode if a stable supported contract exists;
- no OpenCodex change if the only workaround is silently altering prompts.
Relationship
Summary
This issue tracks only the language/content-dependent half split from #1689.
Reports indicate that
agentrouter.orgmay returnHTTP 400witherror.code: "content-blocked"more often for benign Portuguese/Spanish first-user prompts than for equivalent English prompts.This is separate from burst-sensitive failures. Request pacing, retry/backoff, and burst behavior remain tracked in #1689.
Why this is research / needs-info
The currently proposed workaround is to prepend an English instruction frame to the user's first message before forwarding it upstream. That changes user content and therefore changes request semantics. We should not adopt prompt mutation merely because it appears to bypass a third-party WAF.
Before implementing any OpenCodex-side language workaround, we need evidence that distinguishes:
Evidence required
Please provide a controlled, redacted matrix against the same AgentRouter provider/account and current OpenCodex
dev:Do not include credentials, full request identifiers, or sensitive prompt content.
Acceptance boundary
A fix should preserve user content unless there is an explicit, documented, opt-in compatibility policy with clear semantics.
A global or host-name-triggered hidden preamble is not an accepted implementation direction at this stage.
Potential outcomes after evidence:
Relationship