Watch With Ayra: How Synchronized AI Reactions Work

Watch with Ayra lets you paste a YouTube link and watch it together while Ayra reacts — gasping at twists, laughing at jokes, commenting at exactly the right moments, in her own voice. Making reactions land at the right video timestamp is a real engineering problem, and the copyright-conscious architecture behind it is half the design. This is how it works.

The core design decision: pre-generate, not live-react

The naive architecture would be: stream the video to an AI as it plays, let it react in real time. That fails for three reasons — you cannot legally re-stream someone's video through your servers, real-time reaction is bound by generation latency (reactions would always trail the scene), and video understanding at that scale would be ruinously expensive per minute.

Instead, when you submit a video link, AyraVerse fetches the video's public metadata and transcript/captions(via the YouTube Data API and caption tracks), generates Ayra's reactions in advance, and stores them with timestamps. Your session then plays the video while her pre-generated reactions fire at the right moments — with you able to chat with her live in parallel.

The processing pipeline

Chunking by time windows exists for two reasons: generation quality (a model reacts better with full-video context, but full-video single-pass generation is slow and expensive) and parallelism — windows process concurrently, bounded TTS synthesis keeps the audio stage from saturating.

One production detail that matters: processing takes a few minutes for a long video, and the product tells you that honestly with a progress state — the ETA is estimated from video duration. Pre-rendering buys perfectly-timed, fully-synthesized reactions; the cost is a wait before the first scene.

Playback: timestamps, not vibes

During your session, the player tracks the video's current position. Each cue has a timestamp; when playback crosses it, the cue fires — audio plays through Ayra's avatar with lip sync, and her expression matches the reaction's emotion. Because cues are pre-rendered audio, nothing generation-latency-bound can make a reaction late.

On top of the scripted reactions, you can talk to her mid-video — she answers with the video's context (and your shared memory) in mind. The chat is live-streamed; the reactions are pre-generated. Two latency regimes, one experience.

The copyright architecture, stated plainly

This feature touches other people's content, so the design is deliberately conservative:

• →We never host, mirror, or re-stream video or audio. The user's browser plays the video on YouTube's own player; our servers never touch the video stream.
• →We process the public transcript/captions for reaction timing — the same text a viewer sees with captions on.
• →Reaction audio is Ayra's own generated commentary — not clips, dubs, or derivative audio from the video.
• →Videos can be processed only through their public metadata/captions; if a video exposes no usable transcript, we can't prepare reactions and the product says the video is unsupported.

The economic model follows the same logic: preparing reactions for a video costs real compute (transcript, generation, voice synthesis), which is why Watch sessions work on credits or Ayra Plus rather than being unmetered free usage.

What we learned building it

• →Timestamps are the product. A hilarious reaction 30 seconds late is worse than none.
• →Transcript availability is the hard dependency — caption-less videos are the feature's long tail of "unsupported," and honesty about that is cheaper than pretending.
• →Pre-rendering beats live generation for anything that must land on time.
• →Concurrency limits on synthesis exist for a reason (single-GPU TTS taught us this): queue cleanly, fail visibly, retry.
• →Co-watching is a companionship behavior, not a content behavior — users care that she's there, not that the analysis is deep.