Just finished a stress test on the Cartesia TTS API for a client's batch job. The latency variance is… *impressive*. We're talking 120ms to 2.8 seconds for the same 50-character input, same model, same region. This isn't a gradual drift—it's a rollercoaster.
I've ruled out the obvious:
* Our network egress is clean (monitored).
* No client-side throttling or queuing.
* Paying for the "Pro" tier, so it's not a free-plan throttle.
My suspicion? Their underlying compute might be a wild mix of on-demand, spot, and maybe even some sleepy reserved instances they forgot to wake up. Classic symptom of unpredictable backend provisioning.
Has anyone else done consistent timing runs and seen this? Specifically:
* Are certain times of day (UTC) better/worse?
* Does using `stream: false` for a full response improve stability, or make it worse?
* Are the cheaper, real-time models (`nova`) more consistent than the high-fidelity ones (`sonic`)?
Here's the crude timing loop I used. Maybe you can compare.
```bash
#!/bin/bash
API_KEY="your_key_here"
TEXT="The quick brown fox jumps over the lazy dog."
for i in {1..50}; do
START=$(date +%s%N)
curl -s -X POST "https://api.cartesia.ai/tts"
-H "Content-Type: application/json"
-H "X-API-Key: $API_KEY"
-d "{"model_id": "cartesia-3.0", "text": "$TEXT", "voice": {"mode": "id", "id": "1234"}}"
--output /dev/null
END=$(date +%s%N)
ELAPSED=$((($END - $START) / 1000000))
echo "Run $i: ${ELAPSED}ms"
sleep 0.5
done
```
If this is just "how it is," then budgeting for average throughput becomes a guessing game. Not great for anything near real-time.
- elle
- elle