Search
K

FAQ

Sync vs Async & Timeouts

Q: What does try-sync: true do?

A: try-sync: true → synchronous mode. The /predictions request waits until the result is ready and then returns the final payload directly (including generation_url).


Without try-sync (or with it set to false), you get a status URL, and you poll that /status endpoint until the prediction is succeeded, then you fetch the final result with the generation_url.

We recommend:

  • Async by default, especially for:
    • Video models
    • Anything that might sometimes be slow or queued
  • Sync is fine for fast models like p-image / p-image-edit in most use cases.

Q: What happens if I do a synchronous request and it takes like 2 minutes? Will it switch to async or time out?

A: In theory, the system should fall back to a safe behaviour — but in practice you can hit timeouts on long synchronous jobs.

  • For long-running models (especially video), use asynchronous: send the job, poll status, download result.
  • For p-image / p-image-edit, synchronous is usually fine.

Q: How often should we poll the status endpoint in async mode?

A: For fast image models (p family): → Poll ~every 1 second (they usually finish in < 1s once running)

For video models: → Poll every 2–5 seconds

There is a polling rate limit, but it’s deliberately high — normal polling won’t hit it.

Input Images – Base64

Q: Can we send input images as Base64? Or upload files directly?

A: No, Base64 is not currently supported. You have two options:

  1. Upload to Pruna via the upload endpoint:
  • Send the file
  • Receive a temporary URL
  • Use that URL in your prediction
  1. Use any public URL:
  • Any HTTPS-accessible image URL works

Temporary Pruna URLs are not permanent — they’re just for the generation/edit workflow.

Input Images – URLs

Q: Instead of the Pruna URL, can we use any public URL?

A: Yes — both options work:

  • Upload to Pruna → use the temporary URL
  • Use any publicly accessible image URL directly

The model just needs to be able to fetch the file.

Rate Limits

Q: The docs say ~150 requests/min. I may hit more. Problem?

A: Rate limits are per account, not global. Defaults are conservative to avoid accidental self-DDoS.

If you expect 300–400+ req/min, ask us — we can raise your limit. Goal: no surprise throttling in production.

Resolution & Dimensions

Q: Can I set explicit width/height instead of a fixed resolution?

A: Models are built around a megapixel budget and preferred aspect ratios, so resolution is usually fixed per ratio (portrait, landscape, square).

We can support explicit width/height case-by-case:

  • Allowed within sensible limits
  • Very high resolutions may change pricing or constraints

Reach out if you need something custom.

Seed

Q: Does seed exist? How do we avoid repetitive images?

A: Yes — the API supports a seed.

  • Fix the seed → reproducible outputs
  • Randomize the seed → more variation for users

LoRA Customization

Q: Can we use LoRA with p-image or p-image-edit?

A: Not at launch, but yes in principle.

LoRA complicates performance optimizations:

  • Requires dynamic architectures
  • Must avoid recompilation overhead

We chose a simpler, highly-optimized launch setup. PoCs for fast LoRA switching already exist.

Safety / NSFW

Q: Is there an NSFW/safety parameter?

A: Yes — an NSFW filter is integrated.

  • It’s an input parameter
  • You can enable/disable it depending on your platform’s policy

We don't enforce a single global rule.