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.
- 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.
- LangGraph replay re-fires API calls: key Sume submits per fork
LangGraph time travel re-runs every node after the checkpoint, API calls too. Derive the Sume Idempotency-Key from the body so replays dedupe and forks run.
- MCPJam auth debugger on Sume's MCP host: what each step returns
Point MCPJam's auth debugger at mcp.sume.com and read the results: S256-only PKCE, public clients, authorization_code only, a one-hour token, a resource check.
Written by Sume