Sume TTS 1.0 rejects model and model_id: use the router to pick

If you send model or model_id to Sume's POST /v1/tts-1.0/generate, you get a 400: TTS 1.0 has no engine picker and its public id is sume/tts-1.0. To choose an engine explicitly, call POST /v1/tts-router/generate with a required model from GET /v1/tts-router/models. The router uses the same transcript, voice and output rules and the same billing as TTS 1.0; the only difference is that the engine is your choice, and its documented engines are Cartesia Sonic ids.

Two routes, one difference

Both routes take the same transcript fields (up to 20,000 characters), the same voice selectors and the same output options. An unknown model id on the router fails with 400 model_not_found and the catalog URL, so the catalog is the source of truth, not a blog post. The OpenAPI enum currently names sonic-3.6, sonic-3.5, sonic-3, sonic-latest and sonic-preview; read the live list before hard-coding any of them.

How other vendors tier the choice

On ElevenLabs the model is part of the call and each tier has a job. The models overview says Eleven v4 is for professional content with 90+ languages and a 10,000-character limit, v4 Turbo is a real-time option at about 100 ms, Flash v2.5 is about 75 ms with 32 languages and a 40,000-character limit, and Multilingual v2 is the previous generation with 29 languages (read 2026-10-04). OpenAI separates tts-1, tts-1-hd and gpt-4o-mini-tts in its guide.

Sume's default hides the choice so most callers never pick wrong; the router exists for the callers who want to pin an engine for repeatability or to compare two.

When to pin an engine

Pin one when a series must sound the same across months, when you are auditioning engines for a language, or when you need a documented id in a log. Otherwise TTS 1.0 is the simpler call. Either way, read the result from the job as described in jobs and results, and keep the job.model value, which the router sets to the id you requested. The models overview lists the surfaces side by side.