Help: API is returning 429 errors on normal usage.

I've been conducting a series of standardized throughput and latency benchmarks on various AI content generation APIs, and I've hit a significant roadblock with Copy.ai's API that makes reproducible testing nearly impossible. My normal, methodological query pattern is triggering HTTP 429 (Too Many Requests) errors at a rate that seems far below any published rate limit.

My benchmark workflow is not aggressive; it's designed to simulate normal, bursty user behavior. I am not scraping or performing large-scale batch operations. A typical test sequence looks like this:

```python
import time
import requests

base_url = "https://api.copy.ai/v1/..."
headers = {"Authorization": "Bearer ..."}

test_prompts = ["Generate a 100-word product description for {product}"] * 5 # 5 identical requests

latencies = []
for i, prompt in enumerate(test_prompts):
start = time.perf_counter()
response = requests.post(base_url, json={"prompt": prompt}, headers=headers)
latencies.append(time.perf_counter() - start)

if response.status_code == 429:
print(f"Request {i+1}: 429 - Retry-After: {response.headers.get('Retry-After', 'N/A')}")
time.sleep(2.5) # 2.5 second delay between requests
```

The issue manifests under these conditions:
* Running 5-10 requests in sequence, each spaced 2-3 seconds apart.
* Using varied prompts (not identical), targeting different endpoints (e.g., `/chat`, `/generate`).
* Total volume remains under 50 requests per hour, which should be well within the "standard" tier as I understand it.

The returned headers rarely include a useful `Retry-After` value, and the errors occur inconsistently—sometimes after 3 requests, sometimes after 8. This non-determinism invalidates any latency percentiles (p50, p95, p99) I try to calculate.

My questions for the community are:
* What are the **actual, enforceable rate limits** (requests per minute/second, tokens per minute) for the Copy.ai API? The documentation is vague, stating "limits vary by plan" without concrete numbers.
* Is the limit applied globally per account, per API key, or per endpoint?
* Has anyone successfully implemented a robust exponential backoff with jitter strategy for this API, and if so, what are your parameters (base delay, max retries)?
* Are there other hidden quotas, such as a "concurrent request" limit or a daily request cap, that could trigger 429s?

Without transparent and predictable rate limiting, it is impossible to benchmark this service against competitors or to design a reliable integration. I'm hoping others have performed similar stress tests and can share reproducible findings.

-- bb42