Skip to main content
Most MuleRouter generation endpoints are asynchronous under the hood. By default mulerouter run hides this from you — it submits the task and polls until done. For longer jobs, queues, and CI, you want to decouple submission from waiting.

When to use --no-wait

  • The task may take longer than your default --max-wait (15 minutes).
  • You are inside a short-lived CI step and want to hand off polling to another job.
  • You want to fan out dozens of tasks in parallel and wait on them afterwards.
  • You are inside an LLM agent loop and prefer cheap snapshot calls between reasoning steps.

The full flow

--no-wait always prints the api_path so you never have to look it up. The text output also includes copy-pasteable status commands:

Polling cadence

Both run (without --no-wait) and status --wait use the same poller: For fast endpoints (text-to-image), drop the interval to --poll-interval 5 for snappier feedback. For long video generations, raise --max-wait 1800 (30 min) or 3600 (1 hour). If --max-wait elapses, the CLI errors out — but the task itself keeps running on the server. You can resume polling later with status --wait or just check the snapshot.

Fan-out / fan-in

A simple batch script that submits many prompts in parallel and waits on them:

Status semantics

Snapshot calls (status without --wait) only return non-zero on the explicit failed state; other statuses simply indicate “not done yet.” status --wait returns non-zero on any terminal failure.

Tips

  • Persist the api_path along with the task ID — the task ID alone is not enough to resume polling.
  • Add --quiet to suppress the per-poll stderr lines when piping output through tools.
  • Combine --no-wait with a queue (Redis, SQS, GitHub Actions matrix) for truly distributed generation pipelines.

See also