I recently drove MiniMax-H3 through an OpenAI-compatible media gateway to generate a 15s, 9:16, with-audio vertical clip from a first frame plus a long storyboard prompt. I burned a few jobs on avoidable mistakes. Notes below are reproducible and sanitized.
Field names follow the gateway docs; treat this as a debugging checklist, not a product pitch.
Pitfall 1: Don't mix frame and reference roles
Sending both:
-
first_frame(image-to-video from a start frame) -
reference_image(identity / reference mode)
got an upstream error like:
frame and reference roles cannot be mixed
Takeaway: pick one mode. If the product docs describe both capabilities, the call layer still must not "just include everything."
Pitfall 2: Skip undocumented images=@… fields
Some copy-pasted examples use images=@file. On this path that returned unsupported / unexpected file field errors.
Use the documented multipart fields instead:
-
first_frame, or reference_image
Public aspect field name is ratio, not aspect_ratio.
Pitfall 3: prompt optimization failed vs first-frame resolution
What I saw:
- First frame around 1008×1792: even a short clean English prompt could fail with
prompt optimization failed - Same account, text-to-video only: succeeded — so it wasn't obviously a dead key or zero balance
- Re-encoding the first frame to 720×1280 JPEG, same other params: two runs in a row completed
Suggested order when debugging:
- Confirm you didn't mix frame / reference
- Confirm multipart field names match the docs
- Downscale / re-encode the first frame to ~720×1280 and retry
- Only then chase upstream status and poll payloads
A working combo (sanitized)
| Item | Value |
|---|---|
| model | MiniMax-H3 |
| seconds | 15 |
| ratio | 9:16 |
| resolution | 768P |
| input |
first_frame only (re-encoded vertical JPEG) |
| avoid |
reference_image, undocumented images
|
Typical async flow: POST /v1/videos → poll GET /v1/videos/{id} → download with GET /v1/videos/{id}/content. Status JSON may not include a durable direct URL; the content endpoint is more reliable. Prefer a unique Idempotency-Key on multipart creates.
Bonus: DeepSeek Flash queueing vs own capacity
Separately, when a lot of clients share the same official DeepSeek / Kimi queues, TTFT spikes show up as "everything is slow" even if your gateway is healthy. Comparing a route that does not share the crowded official pool (own / reserved capacity) against a shared proxy is a useful A/B when peak-hour latency looks broken everywhere.
Use public model ids (not marketing names) in the request body. For this gateway the public flash alias maps to the catalog id you see in docs / /llms.txt.
Soft wrap-up
- First frame ≠ reference image — never both.
-
Field names follow the docs — don't transplant another SDK's
images. -
I2V +
prompt optimization failed— resize the first frame before blaming the prompt. - Peak latency — check whether you're on a shared official queue.
References (docs + copy-paste examples):
- API docs: https://cheapbuddy.cc/api-docs
- Bash / Python / Node examples: https://github.com/GiantClam/cheapbuddy-examples
- Model list for agents: https://cheapbuddy.cc/llms.txt
If you hit a similar 400, paste the error text + field names (no keys) in the comments and we can compare notes.
Top comments (0)