Cartesia Sonic Retirement: October 20 Model Audit

A voice assistant can look unchanged in its editor while depending on a model snapshot that is about to stop working. The useful first question is the exact model ID used by the saved configuration, not whether the provider logo still appears in a menu.

Cartesia's current lifecycle documentation says sonic-2 and all its snapshots, and sonic-turbo and all its snapshots, will stop working after October 20, 2026. It also marks sonic-3-2025-10-27 for sunset on that date. This guide checks the deadline on October 18. It is not announcing a new model launch today, and the provider page does not specify a cutoff timezone. Official older-model schedule.

The practical result is a short inventory and a reviewed replacement plan. Changing a string, receiving generated audio and approving a replacement for real callers are three different steps.

Burki currently exposes two Cartesia model choices: sonic-3 and sonic-3-2025-10-27. This review does not establish a native Sonic 3.6 selector. The direct-provider example below must not be copied into a custom voice identifier field to add an unsupported model.

Download the free model migration worksheet. It includes a blank dependency inventory, an original reception script and acceptance rows. No synthesis request, configuration change or test call was performed for this guide. The resource is free; production usage is separate.

Find the ID at the point where the assistant runs

Start with the configuration that actually serves the relevant route. A development environment, an unused draft and an assistant attached to a public number may have different settings even when they share a friendly name.

Record these items for each dependency:

Keep credentials out of the inventory. An internal reference to an authorized configuration is more useful than a copied secret. If you cannot establish which configuration serves a route, mark the dependency unresolved rather than assuming that a convenient editor view is authoritative.

For a direct integration, inspect the explicit model_id in the request construction. Also check environment-specific configuration and any fallback branch. A default value in a library is not proof that the same value is active in production.

For a standard-pipeline assistant in Burki, open Voice → Speech settings → Advanced voice stack → Voice model for Cartesia. The current labels are Sonic 3, labeled Latest (recommended) or Stable snapshot, mapped in the catalog to sonic-3 and sonic-3-2025-10-27 respectively. Record the selected label, matching ID and saved assistant reference. The list establishes a configuration choice; it does not establish a successful provider invocation.

Separate a retirement from an ordinary model update

A dated snapshot is useful when you need a fixed target for evaluation. It still has a lifecycle. “Pinned” should describe update behavior, not a promise of indefinite availability.

Cartesia's current Sonic 3.6 documentation distinguishes a stable alias, sonic-3.6, from dated snapshots and the beta sonic-preview. The current listed stable snapshot is sonic-3.6-2026-08-27. The changelog dates Sonic 3.6 general availability to August 27. A preview that can change without notice is a different evaluation target from a fixed production snapshot. Current model and snapshot contract, release chronology.

The retirement page still lists sonic-3-2026-01-12 and sonic-3.5-2026-05-04 as stable. That does not mean a given application, account or runtime exposes every provider model. Check the supported configuration route before choosing a replacement. Do not assume sonic-3, a 2025 snapshot and Sonic 3.6 are interchangeable names. Older-model status.

A useful decision record therefore has two separate fields: the replacement you intend to request, and the evidence that your actual application can request it. If the second field is empty, the migration is still a plan.

The diagram illustrates an original review process. It does not represent an automated Burki migration or completed deployment.

Build a replacement configuration without changing every variable

For a direct Cartesia integration, choose an account-authorized model, a valid voice and an audio format the receiver supports. The current realtime quickstart creates a WebSocket context with model_id, voice and output format, sends text, then signals that no more input is coming. Its example player expects a specific raw PCM format. Realtime setup contract.

A model-selection fragment for a deliberately pinned evaluation would be:

model_id: sonic-3.6-2026-08-27
voice: <existing authorized voice ID>
output_format: <format supported by your receiver>

This is an unexecuted settings fragment, not a complete SDK request or a Burki import format. Keep the current voice, script, language and output path fixed where the replacement supports them. If one must change, label that as another variable rather than attributing every difference to the model.

Cartesia's migration guidance says existing voice IDs and request shapes generally carry from Sonic 3 to 3.5; its current model page describes 3.6 as backward compatible with 3.5. Those are provider compatibility statements, not evidence that every saved clone, decoder or interruption path in your application has passed review. The migration guidance specifically calls for care around beginning-of-word timestamps. Migration considerations, current model compatibility.

If the application cannot admit the intended replacement, resolve that support gap before the deadline. Do not quietly route callers to an untested preview or treat a custom voice ID as a model override. A separately approved temporary route should be recorded as its own operating decision.

Work through a fictional reception migration

Cedar Arts is a fictional community venue. Its receptionist assistant explains where visitors should enter and reads back an enquiry reference. The team discovers a saved configuration using the retiring October 2025 snapshot.

Its first goal is not to make the voice sound more impressive. It is to preserve a complete, understandable exchange while removing a dependency on the retiring ID. The team writes this original review script:

Welcome to Cedar Arts. The workshop entrance is beside the courtyard.
Your enquiry reference is C, D, four, zero.
A staff member still needs to confirm room access.

The caller then interrupts: “Did you say the courtyard entrance or the street entrance?” The expected application behavior is to stop the obsolete reply, answer from approved venue information and retain the enquiry as unconfirmed. Those are acceptance criteria, not results produced in this guide.

Keep an authorized baseline if one already exists. A recording made before migration can help identify a changed word or missing ending. It does not prove why the change occurred, and it should not be uploaded to another service without authorization. If no baseline exists, say so and review against the written criteria rather than inventing a before-and-after improvement.

For the replacement, check three outcomes independently. Did usable audio arrive? Could a listener repeat the entrance and reference correctly on the intended device? Did the application handle the interruption without releasing stale audio afterward? A pass on only the first question is insufficient for this particular receptionist workflow.

The worksheet leaves all results blank. Its fictional identifiers and script are a starting point for a permitted evaluation, not a suggestion to call a real customer or spend provider credits automatically.

Review failures without making the old model the only fallback

A retirement changes what “roll back” can mean. Reverting to an old configuration is not a durable recovery plan once its provider dependency is unavailable.

Before an approved change, name the person responsible for deciding what happens if the new route fails. The alternative might be another already supported and reviewed configuration or a staff handling process. The right choice depends on the business's actual operating arrangements; this guide does not assume that Burki automatically provides either one.

Keep a short failure record:

• Requested model and saved configuration reference.
• Whether the provider accepted the request or returned an error.
• Whether complete audio reached the application and the receiver.
• Whether the spoken content and interruption behavior passed review.
• Which approved operating route was selected next.

An SDK exception, empty audio and incorrectly spoken reference are different failures. Do not combine them into one “quality” score or hide them by reporting only successful samples.

After a permitted update, inspect the saved configuration again and verify the route that uses it. Preserve the acceptance evidence and the unresolved issues. A changed editor value alone should not close the migration record.

Budget the review and the resulting voice usage

As checked October 18, Cartesia describes standard TTS as approximately one credit per character, with some preprocessing variation. Its public Pro plan lists USD 5 per month for 100,000 credits and includes a commercial use license. Plan terms and account allowances still need checking. TTS accounting, current plans.

For illustration, 2,000 assumed billable characters are roughly 2,000 TTS credits under that accounting. That is a quantity estimate, not a USD invoice or a test performed here. Repeated and discarded output can also consume usage. Recognition, reasoning, platform and carrier costs are separate from the TTS model allocation.

Do not convert a provider's approximate generated-audio minutes into a guaranteed number of customer calls. The amount spoken, time listening and repeated replies can differ substantially between enquiries.

For an AI receptionist, the useful finish is a supported, reviewed voice route with a named owner and an honest evidence record. The multilingual voice-selection guide covers the separate question of matching voice and language. Keep that choice stable during the retirement review so you can explain what changed and why the replacement was accepted.