PixVerse V6 native audio and camera work: what to check in an API

PixVerse V6 is described on the company's blog, read 2026-10-03, as a release with camera work and native audio. The same page announces R2, a real-time world model, and a Series C extension that brings total funding to $439M. For an API buyer, the two V6 claims are testable: look for an audio flag in the model catalog and write prompts that name camera moves.

What the blog says

Autocomplete that day also showed searches such as "pixverse v6 vs c1" and "pixverse v6 api", which tells you where buyer attention is.

Test native audio in the catalog

On Sume, a model that can return sound reports generate_audio in GET /v1/videos/models, and the generate_audio request field defaults to the model's audio capability. Some catalog entries always produce audio: Gemini Omni Flash 1.1 has synced audio always on, so generate_audio: false is rejected there. Audio references behave differently by model: they are honored by the Seedance 2.x models, Wan 3.0, MiniMax H3 and H3 Max, and not by Gemini Omni Flash 1.1.

If you are evaluating V6 elsewhere, ask the same question of its API: is audio on by default, can you turn it off, and can you pass your own audio as a reference.

Test camera work with a fixed prompt set

Camera claims are easy to check and easy to overread. Use a set of five prompts, one each for push-in, pan, orbit, handheld and static, and run them on each candidate at the same duration and resolution. Compare whether the named move appears, not how pretty the frame is. Sume's video guide advises detailed prompts that include motion, camera angles, lighting and scene composition, and that applies to every model.

A short evaluation plan

Run each candidate on the same ten prompts and score four things: whether the camera move named in the prompt appears, whether the audio fits the scene, whether the clip duration matches the request, and the billed cost. Use usage.cost on Sume, or the vendor's invoice line elsewhere.

Write the scores into a table with the model id and the date, since model versions change and an old comparison goes stale quickly.

Where R2 fits

A real-time world model is an interactive session, not a render job. Sume's video surface is asynchronous: submit, poll, download. There is no live session endpoint in the docs reviewed here, so an interactive use case needs a different tool, and a job-based pipeline should keep treating each clip as a request with an id.

Whatever you pick, record the job id, model, duration and resolution next to each output so a later comparison is fair.