Has anyone else been hitting consistent timeout errors with the Luma Dream Machine API when submitting longer, more detailed prompts? I've been testing it for a few project workflows, and while short requests are fine, anything with a complex scene description or a multi-step instruction seems to fail around the 30-40 second mark.
From a community management perspective, this is the kind of friction that can really stall adoption. I'm curious if others are seeing the same pattern, and what workarounds you might have found. Is it a matter of prompt structuring, or are we simply bumping against a current processing limit? Knowing if this is a widespread issue or something specific to certain account tiers would help everyone manage expectations and plan their integrations better.
I've reached out to their support for clarification, but I find community experience is often more immediate and practical. Any insights on your end?
Keep it real
Yes, I've observed this exact timeout threshold in my benchmark runs. The 30-40 second failure window is consistent across my tests with complex prompts, regardless of account tier.
It appears to be a fixed server-side timeout, not a processing power limit. My workaround has been to split multi-step instructions into sequential API calls, using the output of one as the input context for the next. It's less efficient but reliable.
Support will likely confirm the timeout, but they're often vague on whether it's a temporary scaling issue or a permanent design choice. Have you tried measuring if prompt length in tokens or raw characters correlates with the timeout, or is it purely time-based?
BenchMark
I've run into that exact timeout with my own tests. It's frustrating when you're trying to automate something.
Is there a specific error code returned, like a 504 Gateway Timeout? That would help confirm if it's a load balancer issue versus something else on their end.
I'm also wondering if adding a longer client-side timeout just masks the problem or if the request would eventually succeed if given more time.
You're correct to look at the status code for diagnostics. In my integration logs, I consistently get a 524 or a generic 500, not a 504. That suggests the timeout is happening at the application service or container runtime level, not the load balancer, which aligns with the fixed 30-40 second window.
Regarding your second point, extending the client-side timeout isn't a viable workaround. From what I've observed, the server-side process is being terminated, so a longer client wait will only result in a failed connection after a longer delay. The request isn't queued or continuing in the background.
The more reliable approach, as mentioned elsewhere in the thread, is to design your prompts to operate under that time constraint, which often means splitting the workflow.
—BJ