ElevenLabs Cue Explained: Forced Alignment, API Pricing and Limits

ElevenLabs shared new research details about Cue on October 28, explaining the alignment model already behind Scribe timestamps and its standalone Forced Alignment API. Cue places text against audio, making it relevant to subtitles, transcript-based editing and applications where clicking a word needs to find the right moment.

This is a research disclosure about an existing capability, rather than a newly available API. The practical question is whether better timing removes enough correction work to make an audio workflow easier to operate.

What does Cue actually do?

Speech recognition answers what was said. Forced alignment takes audio and a supplied transcript and works out when the text was spoken. A correct transcript and correctly timed text are separate problems.

Imagine an interview editor who has corrected a product name in the transcript. The editor still needs those words linked to the recording. An aligner provides that connection, so a text selection can become an audio selection rather than another manual search through the timeline.

ElevenLabs describes Cue as a character-level model and says it is smaller than its previous aligner. Its research post reports 179 milliseconds of mean timing error across full recordings, compared with 283 milliseconds to more than six seconds for the open-source alternatives it evaluated. On noisy English audio, it reports 57 milliseconds.

Those are ElevenLabs' measurements, not an independent benchmark reproduction. The company says its evaluation counts words that an aligner fails to place, which matters because a system should not look accurate simply by leaving difficult words out.

What the speed result does and does not mean

ElevenLabs reports aligning an hour of audio in roughly half a second on a production GPU. That is an interesting compute result, but it is not a promise that uploading and processing an hour-long recording will take half a second from a user's device.

File transfer, request handling and the rest of an editing pipeline still exist. For an application, the useful measurement is the time from submitting a recording to receiving usable timestamps, alongside the time a person spends fixing them.

I would also separate timing accuracy from transcript accuracy when evaluating the result. Precisely locating the wrong text would not make a subtitle correct. A useful test set needs the awkward recordings the product actually handles, rather than only clean narration.

Forced Alignment API pricing and request format

The API reference documents a POST request to /v1/forced-alignment with an audio file and text. Its response contains word and character timestamps, plus loss values for words and the transcript. Developers do not need to adopt a complete video editor to use those outputs.

The capability documentation says forced alignment uses the same rate as the Speech to Text API. The current API price page lists batch Scribe v2 at $0.22 per audio hour, excluding taxes. The Cue research disclosure does not announce a separate new pricing tier.

This makes the relevant cost question broader than inference alone. If an alignment pass reduces manual subtitle repair, that saved editing effort may matter more than a small difference in the audio processing bill. That still needs testing on the team's own material.

Check the limits before integrating

The documentation currently has inconsistencies worth resolving before a large import. The overview lists a 3 GB maximum file size, while the endpoint reference says files must be under 1 GB. The overview also specifies ten hours of audio and 675,000 text characters. Do not build around the larger file limit without confirming which applies.

There is a similar distinction around languages. The research discusses coverage beyond 90 languages, but the capability page lists 29 supported languages. Research coverage should not be treated as a contractual API support list.

Finally, the overview says diarization is unsupported and warns that supplying speaker-labeled text can produce unexpected results. Applications that need to identify who spoke must handle that separately.

Better timestamps become valuable when they reduce correction work. The next useful comparison is therefore a full editing task: how often the user lands on the intended word, how many timings need repair, and how much work remains before the recording is ready to publish.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI teams turn technical releases and product thinking into clear stories that developers and founders want to read and share.

Book a 30-minute call.