Going to production

Use this checklist before sending production traffic. Each section links to detailed guidance elsewhere in the documentation.

Keys and secrets

One key per app and environment (prod-backend, staging, cli-tools), and private keys over workspace-shared ones when usage should remain attributable to a person. There are no per-key rate limits.
Load keys from a secret manager or environment variable. Never store them in source control. Add the ck_ prefix to secret-scanning rules.
Document a rotation procedure. Key changes can take up to one minute to take effect. Rotate shared credentials when access changes and immediately after suspected exposure.
Do not include a key in public client-side code. Browser calls are supported, but public JavaScript cannot keep a credential secret. Proxy requests through your backend.

Retry 429, 502, and 503 with exponential backoff and jitter, honoring Retry-After as the floor. Code in Rate limits.
Never retry 400, 401, 404, or 413 unchanged. They fail identically every time. See Errors.
Treat 402 as terminal and alert on it. An exhausted balance stops every key in the workspace; a retry loop cannot fix it.
Set client timeouts based on your workload and latency objective. Treat a timeout as transient and retry with backoff.
Retry any 5xx by status, not by body. Some 5xx responses may not include a JSON body, so do not require error.code before retrying. See Errors.

Use a shared client-side concurrency limit across workers. See Rate limits.
Remember limits are workspace-scoped. All keys share one rate ceiling and one credit balance. Set separate concurrency budgets for batch and user-facing traffic.
Reuse connections. Use connection pooling and keep-alive. OpenAI SDK clients enable these by default. See Measuring latency.

Send X-Client-Trace-Id on every request. Celeris echoes it in API responses so you can correlate failures with application logs and support cases. See the API reference.
Log or sample wall-clock duration and the Server-Timing header. For complete responses, compare them to estimate client/network overhead. For streams, measure time to first token separately because Server-Timing ends at the earlier response-header boundary. See Measuring latency.
Track your client-side 429 rate. Throttled requests are not counted on the usage page, so track them in your application logs and metrics. See Rate limits.

Monitor spend. The usage page shows completed request counts and token volumes over 24 hours, 7 days, or 30 days. Project spend from those volumes with the pricing rates.
Maintain sufficient credit. When the balance is exhausted, all keys in the workspace return 402. Alert on this response.
Set max_tokens on every request. This bounds completion latency and cost. Any positive integer that fits the 131,072-token context window is accepted. See Prompt engineering.

Deploy callers close to their users. Celeris aims to serve requests as close as possible to customers. Typical short requests complete in roughly 50–150 ms within the serving region, and network distance adds to end-to-end latency.
Measure complete responses with Server-Timing. Compare it with wall-clock latency to estimate client/network overhead. For streams, also measure time to first token and do not treat the header as model time. See Measuring latency.