Using ltx-2.5-fast/text-to-video on HiAPI for Short-Form Video

Why ltx-2.5-fast/text-to-video fits short-form work

Short-form video is a volume game with a short attention budget. You need many clips, fast turnaround, and a way to throw away the bad ones without feeling the loss. That shapes which generation model is worth wiring into your pipeline.

ltx-2.5-fast/text-to-video is a text-to-video model on the HiAPI API with two properties that matter here: it produces native audio alongside the picture, and it outputs at 1080P. In practice that means one call returns a clip that is already publishable in shape — you are not stitching a silent video track to a separately generated music bed, and you are not upscaling a low-resolution draft before it is presentable.

The fast in the model name points at the same tradeoff: throughput over maximum fidelity. For short-form work — vertical clips, hooks, social cutdowns — that is usually the right side of the trade. You iterate more, and iteration volume matters more than any single frame.

A simple way to picture the pipeline:

text prompt ──► ltx-2.5-fast/text-to-video ──► video track (1080P)
                                          └──► audio track (native)

One input, two outputs, one asset to manage. Everything downstream in this guide assumes that shape.

Planning clips before you write prompts

The most common mistake in prompt-to-clip work is writing one prompt for a whole video. A model asked to "make a 30-second ad" will average across beats and produce something that feels like none of them. Decompose first.

Break the video into shot units

Write your script, then cut it at every visual change. Each cut is one generation unit. A typical short-form piece lands at four to eight units. Give each unit:

• an index and a one-line description of what happens
• its intended duration
• the audio intent (dialogue line, ambient bed, music-only, silence)
• a note on whether it must connect visually to the previous shot

Keep each request small

Small units are cheap to regenerate and cheap to reorder. If shot 3 is wrong, you rerun shot 3, not the whole piece. Keep connective tissue out of the model's job: if two shots need to flow together, generate them separately and join them in your editor rather than asking for a long continuous take.

Decide the target shape up front

Aspect ratio, duration range, and where the clip will live determine everything else. Decide these before the first request, because changing them later means regenerating everything. If you are producing for more than one channel, plan separate shot lists per channel rather than cropping one master — the framing differs enough that a crop will look like a crop.

Treat the shot list as source-controlled data. A prompt that produced a good clip is an asset, and you want it in version control next to the code that consumed it.

Prompt patterns that produce usable clips

Write prompts like structured shot descriptions, not like prose. A stable template gives you reproducibility: when a retry succeeds, you know which field changed.

The five fields

[subject]   who or what is on screen, with concrete visual detail
[action]    what happens during the shot — one continuous motion
[camera]    framing, angle, and movement (e.g. slow push-in, static wide)
[lighting]  time of day, source, mood
[audio]     what should be heard: dialogue, ambience, music character

A filled example:

subject: a woman in a canvas work jacket, mid-30s, workshop background
action: she lifts a ceramic mug from a shelf and turns it in her hands
camera: static medium shot, slight shallow depth of field
lighting: warm afternoon window light from camera left
audio: quiet room tone, faint hum of a kettle, no music

Rules that hold up

• One action per shot. Two motions in one prompt produce a compromise between them. If the shot needs a second beat, it is two shots.
• Describe what is visible, not what it means. "She looks relieved" gives the model nothing. "Her shoulders drop and she exhales" gives it something to render.
• State the camera explicitly. Leaving camera behavior unstated is the fastest route to an unusable clip, because the model will pick a default you did not want.
• Be specific about audio intent. Native audio means the prompt influences sound. Say whether you want dialogue, ambience, music, or silence — do not leave it implicit.
• Avoid negation stacks. "No text, no watermarks, no extra people" tends to summon the things named. Describe the frame you want instead.

Keep a prompt log

Every prompt you send, store the full text plus the parameters. When a clip works, the prompt is the reusable artifact; when it fails, the log tells you whether the prompt or the parameters drifted.

Making a request through the HiAPI API

Generation goes through the HiAPI API under the model identifier ltx-2.5-fast/text-to-video. The call is a single request: you send the prompt and the generation parameters, and you get back a job whose result is the clip asset.

Minimal request shape

The exact field names and supported ranges come from the model's reference page in the API docs — check there before you hardcode anything. The structure below shows the shape of a working call:

curl -X POST "https://api.hiapi.ai/v1/video/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ltx-2.5-fast/text-to-video",
    "prompt": "static medium shot, a woman in a canvas work jacket lifts a ceramic mug from a shelf and turns it in her hands, warm afternoon window light from camera left, quiet room tone with a faint kettle hum",
    "duration": <clip length in seconds>,
    "resolution": "1080p"
  }'

Replace the duration placeholder with a value the model accepts. Send only what you need: prompt, duration, resolution, and any aspect or audio controls the reference lists.

What to send, at minimum

• the model identifier, exactly as published
• a finished prompt assembled from your template
• duration, chosen from the model's supported range
• output resolution, when the model lets you choose

Read the response as a job, not a file

Treat every response as a job record: an identifier, a status, and — once complete — a reference to the asset. Persist the job identifier with your prompt and parameters so every clip in your library can be traced back to the request that made it.

Keep the API key server-side and inject it from your environment. Do not construct prompts on the client.

Handling native audio and 1080P output downstream

The call returns a 1080P clip that already has an audio track. What you do next determines whether that matters.

Review before you assemble

Watch every clip once, unmuted, at full size. Two specific things to check:

• Audio-picture sync. Native audio is generated alongside the picture, not derived from it. Confirm the sound matches the action — a mug being lifted should not sound like a door closing.
• Audio level and character. Generated audio can arrive louder or quieter than you expect. Check peaks before you drop it into a timeline at unity gain.

Reject fast. A clip that needs fixing at review is usually cheaper to regenerate than to repair, especially when the fix is in the prompt.

Assemble, don't re-generate

Cut your shots together in the editing tool your team already uses. Because each shot came back as a full 1080P asset, assembly is ordinary editing: trim heads and tails, set transition points, duck the audio under any voiceover you add.

Keep the native audio where it earns its place. Ambient beds and room tone generated with the picture usually sit better than a stock track dropped on top, because they were generated for that frame. Replace audio only where you need a specific voice or licensed music.

Export for the target channel

Export to the codec, aspect, and duration your destination platform expects, and validate a sample export against that platform's requirements before you produce a batch. The 1080P source gives you room to reframe for a different aspect, but re-check framing on the reframe — the composition you approved may not survive a crop.

Keeping iteration cost and quality under control

Generation is billed by the work you ask for — clip length and resolution both move the cost of a call. That means your iteration discipline is your cost control. Three deliberate moves:

Regenerate before you rewrite

If a clip is close but not right, rerun the same prompt once. Generation is not fully deterministic, and a second sample sometimes clears a minor artifact. If two reruns of the same prompt both fail the same way, the prompt is the problem — change it.

Change one thing at a time

When you edit a prompt, edit one field. If you change subject, camera, and lighting at once and the result improves, you have learned nothing reusable. One-variable iteration converges; shotgun edits produce clips you cannot reproduce.

Separate prompt problems from parameter problems

Ask which axis the failure is on. Composition, action, and mood are prompt problems. Length, resolution, and format are parameter problems. Fixing a framing issue by shortening the clip wastes a call; fixing a length issue by rewriting the prompt does the same.

Escalate in order

1. Rerun the same prompt.
2. Adjust one prompt field.
3. Change a parameter (duration, resolution).
4. Redesign the shot.

Most fixable clips resolve at step 1 or 2. Jumping to step 4 is how a cheap iteration becomes an expensive one.

Finally, cap the attempts. Set a per-shot retry limit in your job layer and stop when you hit it — the shot needs a rethink, not another sample.

Common failure modes and how to debug them

Most prompt-to-clip problems fall into a small set of buckets. Here is where to look first for each.

The clip does not match the prompt

Check the prompt's specificity before anything else. Vague subjects and unstated camera behavior are the usual causes. Rewrite the shot using the five-field template and make the camera explicit.

The action is muddled or split

You probably asked for more than one thing to happen. Split the shot into two generation units, each with a single continuous motion.

The audio does not fit the picture

Look at the audio field of your prompt. If you left it implicit, the model picked a default. State the audio intent directly — ambience, dialogue, music character, or silence.

The clip is the wrong length or shape

This is a parameter problem, not a prompt problem. Verify the values you sent are within the range the model's reference lists, and confirm your client is serializing them as expected rather than dropping them.

Requests fail or time out

Check, in order: model identifier spelled exactly as published; API key present and valid; request body valid JSON; rate limits not exceeded. Generation is asynchronous work, so a slow response is not necessarily a failed one — poll the job rather than resubmitting, or you will pay for the same clip twice.

Results are inconsistent across runs

Expected to a degree. Log every prompt and parameter set so you can tell a genuine regression from normal variance, and keep your retry limit in place.

The fastest debug loop is always the same: pull the job record, read the exact prompt and parameters that were sent, and change one field at a time until the clip matches the shot you planned.