DeepSeek API Rate Limiting and Error Handling Rules

## DeepSeek API Production Rules

### Rate Limiting
- DeepSeek API enforces rate limits per API key
- Implement client-side rate limiting before hitting the API
- Use a token bucket or sliding window algorithm
- Cache responses for identical prompts (TTL: 5-15 minutes)

### Error Handling
Handle these error codes specifically:
- 400: Bad request — validate prompt before sending
- 401: Invalid API key — check DEEPSEEK_API_KEY env var
- 429: Rate limited — implement exponential backoff:
  - Start: 1 second
  - Max: 60 seconds
  - Jitter: random 0-500ms
  - Max retries: 5
- 500/502/503: Server error — retry with backoff (max 3 attempts)
- Timeout: Set reasonable timeouts (30s for chat, 120s for R1 reasoning)

### Cost Optimization
- Use deepseek-chat for simple tasks (cheaper)
- Reserve deepseek-reasoner for complex reasoning
- Set max_tokens to prevent runaway responses
- Use temperature 0.0 for deterministic cache-friendly responses
- Batch similar requests where possible
- Monitor token usage per request and set alerts

### Security
- Never expose API keys in client-side code
- Use environment variables or secrets manager
- Rotate keys periodically
- Log request metadata (not content) for debugging
- Implement request signing for webhook callbacks

### Monitoring
- Track: latency p50/p95/p99, error rate, token usage, cost per request
- Alert on: error rate > 5%, latency p95 > 10s, daily cost > budget
- Dashboard: requests/minute, model distribution, cache hit rate