Avatar micro twitches: what Sume's 2 fps frame check can see

Tavus says Phoenix-4.5 cut micro twitches. To check your own clip, Sume's frame sampler tops out at 2 fps; use explicit times for 24 neighbouring frames.

5 min readSume
All posts

Tavus's changelog says Phoenix-4.5 upgrades on October 7 delivered improved facial emotions and reduced micro twitches for video-based faces (read 2026-10-11). To check a Sume avatar clip for the same kind of glitch, the frame sampler is the wrong tool at its default setting: fps is capped at 2, so it would miss a twitch that lasts a few frames. The right call is at[] with explicit times, which can pull up to 24 neighbouring frames of one moment.

The Tavus line is from the Tavus changelog, read 2026-10-11. It is a statement about Tavus's own Phoenix-4.5 faces, not about Sume's avatars, and it says nothing about how to measure twitches. The Sume mechanics are from Video frames and Video inspect.

Why 2 fps cannot see a twitch

A micro twitch is a brief jump in the face, often lasting a handful of frames. At 25 frames per second, a 3-frame twitch lasts 0.12 seconds. Sampling at 2 fps takes one still every half second, so the chance of landing on a short glitch is small. The sampler's fps option is documented as 0 < fps ≤ 2, expanded to mid-bin samples, with a limit of 24 frames. It is built to give you a storyboard, not to prove an absence.

What the frame tool lets you do instead

Both video frames and video inspect cap a call at 24 frames, and the clip must be a media.sume.com artifact of 300 seconds or less.

Frame extraction options (Sume Video frames and Video inspect docs; Tavus entry read 2026-10-11)
GoalUseLimit
Storyboard of the whole clipfps up to 224 frames per call
Neighbouring frames around a momentat[] with times a frame apart1-24 values, each inside the clip duration
Exact frames at source sizevideo frames, no max_edgeJPEG default, PNG for lossless
Probe facts and 8 default stillsvideo inspectDefault stills clamp to 768 px
Audio and has_audio checkvideo inspect probeframes: false is enough

A twitch check in three steps

First, find the clip's real frame rate with a video inspect probe, rather than assuming 25 or 30. Second, pick the moments you care about: the first second after a cut, a hard consonant, a smile, a head turn. Third, for each moment, request at[] with times separated by one frame interval, for example 0.04 seconds apart at 25 fps, 24 values covering a bit under one second, and set format to png if you want lossless stills.

Name the files by their time so you can find a glitch again, and keep the request's Idempotency-Key so a retry does not queue a second extract. Put the stills next to each other. A twitch shows as a jump in the mouth corners, brows or jaw between two adjacent frames that the surrounding frames do not have. If a frame fails to extract, that entry has a null url and the job still completes, so check each entry.

What this check proves and does not

It proves the frames you pulled. It does not prove the clip is free of twitches elsewhere, because 24 frames cover under a second. Billing is by compute rather than a fixed price, so pull only the moments that matter, and note the cost of each call from the job result instead of guessing. Clips longer than 90 seconds can also return a low_confidence_long_video warning, which does not fail the job but is a reminder to trim to the section you want first with the separate video trim job.

For a rendered avatar clip, the practical routine is the cheaper one: approve the first frame with an avatar preview before the full render, render once, watch the clip at normal speed, and use frame extraction only on moments that look off. If a clip has a glitch, regenerate it; a regenerate is a new job and is billed again, so decide how many attempts a clip is worth.

Sources

Related posts

More in Media tools

All Media tools posts

Written by Sume