{
"error": {
"message": "Your request was flagged by automated-use detection. Insert a minimum 3-second delay between calls or your key may be suspended.",
"type": "policy_ratelimit",
"param": null,
"code": "policy_ratelimit"
}
}
I’d been running the same Claude Code pipeline for weeks—batch-reviewing PR diffs via the API—without ever touching the rate limit. Suddenly, even requests spaced eight seconds apart got slapped with that policy code. Something changed server-side.
Stepped through the diagnosis:
-
Captured a working session from the old day – identical prompt structure, same key, no error. That ruled out a code regression in my queue manager.
-
Compared request headers – noticed a new
X-Rate-Policy-Version: 2.1
appearing in the failing responses. Previous calls had 1.9
. This suggested a policy rollout, not a quota issue.
- Tested a single, lightweight call – a simple
complete
with no system prompt. It went through fine. The rejection only triggered on my heavy code-review prompts (large context, chain-of-thought instructions).
- Checked the official status page – no incident listed. So this was a silent policy tightening, probably tied to what the press is now calling “OpenAI talking to the White House about slowing down AI.”
The fix for now: I added a uniform 5-second sleep and slashed the temperature to 0.2 to reduce token variance (their heuristics seem to penalise high-entropy outputs originating from automated loops). That cut throughput by 40% but the pipeline runs.
This isn’t a bug in the conventional sense—it’s a deliberate limit imposed because they’re negotiating with regulators. The real-world deployment impact is that any LLM agent running unattended can trip this wall unexpectedly. Has anyone else seen similar header changes (X-Rate-Policy-Version
) or worked around the delay requirement without losing too much speed? I’m experimenting with batching multiple reviews into one
Next Why Adam Optimizer Fails in RL and Transformers →