Add proof of concept of transcription ordering fix

[1egoman]

Previously, transcriptions were ordered by the first actual transcription data stream packet arrival time.

What this meant was that in a situation like the below:

1. User transcription data stream opened
2. Agent transcription data stream opened
3. Agent transcription first data stream packet received
4. User transcription first data stream packet received

The transcriptions would be ordered in Agent -> User order, not User -> Agent.

To fix this, change transcription ordering so it is based off of when transcriptions data streams are initially opened, and push all this ordering logic further up into the components-core package so it is more easily testable (and then both useTranscriptions AND useSessionMessages get this same fix). Finally, add some tests to assert both this behavior and the related clock offset behavior which @davidliu reported and was fixed in #1229.

Fixes #1280 (I am pretty sure, but would like to get confirmation from the reporter first)

Todo

• Exercise this locally outside of a test context in an example app
• Verify with reporter this actually fixes the problem

[changeset-bot]

🦋 Changeset detected

Latest commit: 9ee3932

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@livekit/components-react	Patch
@livekit/components-core	Patch
@agents-ui	Patch
@livekit/component-example-next	Patch
@livekit/components-js-docs	Patch
@livekit/component-docs-storybook	Patch
@livekit/components-docs-gen	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
components-js-storybook-5kld	Ready	Preview, Comment	Jun 18, 2026 3:24pm

[github-actions]

size-limit report 📦

Path	Size
LiveKitRoom only	6.01 KB (0%)
LiveKitRoom with VideoConference	32.21 KB (0%)
All exports	43.77 KB (+0.26% 🔺)

[lukasIO]

generally makes sense to me!

For agent use cases, I believe in theory there's still a timing issue wrt speech timing vs agent transcript timing. The sender timing should be consistent for these cases anyways, so we gain little from the firstReceivedTime timestamp unless the textstream were to open before actual data is being sent. I don't think that's the case though: https://github.com/livekit/agents/blob/main/livekit-agents/livekit/agents/voice/room_io/_output.py#L454-L464
we only stream_text once the transcription is available

[1egoman]

@lukasIO - for context, In the original issue, it seemed like the reporter mentioned that empty transcription chunks can get sent before the actual "content containing" transcriptions get sent.

Reading that agents snippet you pasted though, it makes me wonder if maybe this isn't really right, and a better direction here maybe could be to keep with the old strategy of ordering transcriptions based on the first received transcription chunk, but ONLY start aggregating chunks once the first non empty chunk is received (I'm assuming non empty means .length > 0? But not 100% sure, I wasn't able to reproduce this - it might be an edge case specific to certain LLMs or something like that).

So that would look something like:

1. User transcription data stream opened
2. Agent transcription data stream opened
3. Agent transcription data stream packet received ("")
4. Agent transcription data stream packet received ("")
5. User transcription data stream packet received ("")
6. Agent transcription data stream packet received ("foo")
7. User transcription data stream packet received ("bar")

And then the transcriptions would get ordered Agent -> User because foo came before bar.

Thoughts on that?