Operations
Production integration
API v1 includes synchronous file endpoints, Orukeet utterance streaming, and the oruk-realtime WebSocket. Production clients should bound retries, preserve request IDs, monitor latency and error rates, and monitor prepaid balances or subscription usage and overage caps for the selected model.
Limits and latency
Orukeet accepts English audio up to 60 seconds and 4 MiB per request. There is no audio-duration minimum; its request usage value rounds up to one microdollar. Use model=oruk-orukeet with your existing organization key. For lower upload overhead, use lossless FLAC, reuse connections, and send the model field before the file. The Orukeet guide includes the direct endpoint, streaming protocol, and optional task flags. Published measurements describe the tested workloads and current single-region deployment.
Resonance 1, Fourier, and Realtime limits
- File size
- 30 MB
- File duration
- 60 minutes
- Realtime session
- 10 minutes
- Billing minimum
- 1 second
- Suggested short-file timeout
- 120 seconds
Proficiency
Proficiency accepts English audio up to 30 MB and 600 seconds. Use at least five seconds of audible speech; short reading prompts suit the continuous model, while 30–60 seconds of spontaneous speech suit the legacy CEFR estimate. Scores use aligned windows of at most 30 seconds; long-form aggregates have not been independently validated against human ratings.
The endpoint returns 0–1 word and recording pronunciation scores alongside the original CEFR fields. Preserve null scores and use proficiency.continuous_check for pronunciation validity. The original top-level check still governs CEFR validity and billing: insufficient_audio is free, but valid CEFR with partial pronunciation alignment consumes usage. See the model and compatibility guide for fields, status handling and benchmarks.
End-to-end latency depends on audio duration, selected task, model, and current capacity. Self-serve access does not include a contractual p95 latency or concurrency allocation. Measure representative audio and contact oruk before a high-concurrency launch.
Retry policy
| HTTP status | Action | Notes |
|---|---|---|
| 400, 401, 402, 404, 413, 422 | Do not retry automatically | Fix the request, credential, subscription allowance, or file. |
| 409 | Do not create a new chargeable request blindly | The request ID has already been used. Reconcile against usage history. |
| 429 | Retry | Exponential backoff with jitter. Reduce concurrency if it persists. |
| 500, 502, 503, 504 | Retry | Use the same logical request ID and a bounded retry budget. |
Observability
- Log your X-Request-ID and returned result ID.
- Track status code, duration, model, task, and client-perceived latency.
- Alert on sustained 429 or 5xx rates, not isolated retries.
- Compare application records with the request-level usage ledger.
- Monitor Orukeet subscription allowance or the included minutes, subscription state, and overage cap for other models.
- Never log bearer keys, audio content, or complete API responses by default.
Launch checklist
- 01Keep keys in a server-side secret manager.
- 02Use one key per environment and rotate it on exposure.
- 03Validate representative audio, microphones, accents, and edge cases.
- 04Set timeout and retry budgets explicitly.
- 05Load test below an agreed production concurrency envelope.
- 06Confirm the active subscription, each model allowance, and the shared overage cap.
- 07Review the security, privacy, and responsible-use commitments.
- 08Define a human escalation path for consequential emotion use.