Grok Imagine Video 1.5 Lite batch API: what xAI documents
xAI's Lite page lists a $0.02 per second price, 10 requests per second, batch support and two regions. Sume jobs are async instead; here is how they differ.
Yes. xAI's model page for grok-imagine-video-1.5-lite says batch processing is available, sets a limit of 10 requests per second, lists output at $0.020 per second, and names the us-east-1 and us-west-2 regions. The page does not give resolutions, durations or audio behavior; those are on xAI's video generation page. Sume's Grok row does not use this API shape: you submit a job to Sume and poll it.
What does the Lite model page list?
The page for grok-imagine-video-1.5-lite is short. It describes text and image inputs producing video output and gives four operational facts.
- Output price: $0.020 per second.
- Rate limit: 10 requests per second.
- Batch processing: available.
- Regions: us-east-1 and us-west-2.
How long does a Grok video take to come back?
xAI's video generation page says a request typically takes up to several minutes depending on prompt, duration, resolution and editing. Its SDK defaults wait up to 10 minutes and poll every second in the Python SDK or every five seconds in the AI SDK. So a rate of 10 requests per second is a submit limit; the clips themselves take far longer than that to finish, and a batch is a long queue of waiting jobs.
How does that compare with a Sume job?
Sume's Videos endpoint answers a submit with a 202 and a job object that carries an id and a polling URL. You poll the job until it completes, then read the content from the job's content URL. A terminal failure returns a job_failed conflict on the content call. The table sets the two flows side by side.
| Question | xAI Lite | Sume grok-imagine-video-1.5 |
|---|---|---|
| Output price | $0.020 per second | 1.25 cents per second |
| Duration range | 1 to 15 s | 4 to 15 s |
| Text-only prompt | Yes | No, image required |
| Result | Poll a request until done | Poll a job id, then fetch content |
What should a bulk run plan for?
Whichever API you use, plan around waiting, not around submit speed. Submit in waves, store each job id the moment you get it, and treat a failed job as something to retry once, not loop on. Sume's plans cap how many jobs run at once, so read your plan's concurrency before you queue a hundred clips.
Sources
Related posts
More in Developers
- Image-to-video with sound by API: Sume ids that take a first frame
Kandinsky 6.0 has an image-to-audio-video mode. On Sume these ids take a first_frame image and return sound, and these do not. Request code included.
- Inngest Bursty Concurrency 3x: will Sume answer queue_full?
Inngest can lift step concurrency 3x for 60 minutes a month. Sume's limit does not move: size bursts to accepted capacity and retry queue_full with one key.
- Julia: verify a Sume webhook with SHA.jl and a hand-rolled compare
Verify a Sume webhook in Julia: SHA.hmac_sha256 over timestamp.raw_body, a hand-rolled constant-time compare, rotation entries, and a five-minute replay window.
- Lambda Powertools idempotency and Sume's Idempotency-Key: use both
Powertools idempotency guards your Lambda handler; Sume's Idempotency-Key guards the paid submit. How they differ, and how to derive one key from an order id.
Written by Sume