Overview

We provide two distinct text-to-speech models, letting you choose between stability and cutting-edge features:

  • Aurora (default): Our stable, production-ready model, recommended for most users. Offers reliable performance with well-tested features and longer deprecation windows for any breaking changes.
  • Blizzard (experimental): Our latest advances, giving you early access to new capabilities and improvements. Features may change more frequently and with shorter notice, making it ideal for testing and development.

You’ll specify which model you want via the model parameter in API calls, defaulting to Aurora if unspecified.

Current Model Comparison

Aurora (Default)

  • Reliable, production-grade
  • Low-latency
  • Balanced performance across all use cases
  • Multilingual (supported languages)
  • Supports professional voice cloning

Blizzard (Experimental)

Key Improvements

  • Highly conversational output with natural pacing and intonation
  • Better handling of filler words and casual speech
  • Instant voice cloning that better preserves accents and speaker styles

Limitations

  • Higher latency compared to Aurora
  • Different pronunciation override tag format (see documentation)
  • Features not implemented yet:
    • WebSocket streaming
    • Multilingual
    • Audio output length and speed controls
    • Professional voice cloning

Model History

NameidLatest VersionType
Auroraaurorav1 (Nov 2024)Default
Blizzardblizzardv1 (Dec 2024)Experimental

Setting Models in the API

To specify which model you want to use, set the model parameter in your API requests:

# Use the experimental model
synthesis = await speech.synthesize(text='Hello.', voice='lily', model='blizzard')

# Use the default model (or omit the parameter entirely)
synthesis = await speech.synthesize(text='Hello.', voice='lily', model='aurora')

If you don’t specify a model, your requests will automatically use Aurora, our default model.

Model Updates & Changes

Regular Updates

Both models receive regular updates and improvements. Most updates are non-breaking and require no changes to your applications.

Breaking Changes

When we need to make breaking changes:

  1. We announce the changes in advance
  2. Provide a deprecation window to update your applications
  3. Document migration steps
  4. Send deprecation notices through the API headers

Model Version Tracking

You can find which specific model version handled your request in the API response headers under X-Model-Version. We recommend logging this value for debugging.

Support & Updates

We’ll notify you about model updates, breaking changes, and deprecation windows through these channels.

Was this page helpful?