Pika Fancy plan: unlimited parallel generations vs Sume queueing

Pika's pricing page lists a Fancy plan at $95 a month ($76 on annual billing) with 8,550 or more credits, unlimited parallel generations, a priority queue and early access. Sume has no unlimited tier: workspace processing concurrency is set by plan, from 1 on Free to 20 on Scale and Enterprise, and extra jobs wait in a queue instead of failing.

Pika's numbers come from its pricing page, read on 2026-10-02, and may change; Sume's come from Generation admission. The page also lists a Starter plan at $10 a month with 900 credits, and Creator at $35 with 3,150 credits and 8 parallel video generations.

What does the Fancy plan include?

Per the page: no watermark, a commercial license, a priority queue and early access, with unlimited parallel generations. The page marks Fancy's credits as '8,550+' and the monthly price as $95, or $76 on the annual plan. Enterprise is custom, with unlimited parallelism and all features.

Pika's models on the page include Seedance 2.5, MiniMax H3, Wan 3.0, Google Omni Flash, Pika 2.5 and Pikaframes for video. Credits are not dollars, and per-clip credit cost varies by model, so the page's plan figures alone do not give a cost per clip.

How does Sume admit parallel work?

Concurrency is a dispatch limit, not a submit limit. On Free, one job processes at a time and the queue holds 5 more, for 6 accepted jobs. Pro runs 4 with a queue of 20, Startup 8 with 40, Scale 20 with 100, and Enterprise 20 with 100. Prepaid top-ups do not raise concurrency; it is plan-only, and admin overrides can raise it.

A valid job over the limit is accepted as queued and moves to processing when a slot opens. When the queue itself is full, a new paid submission fails with 429 queue_full, which is different from ordinary rate limiting (429 rate_limited).

What should a batch job do differently?

With an unlimited-parallel plan you can fan out and let the vendor absorb it. On Sume, treat queued as normal, store every job_id, poll status with backoff, and read the effective cap from generation_limits.concurrency_limit instead of the static table. For a batch bigger than the accepted capacity, feed jobs in waves and handle queue_full by waiting for a slot.

Over MCP, jobs_wait takes 1 to 20 ids with wait_for of all or any, which suits a wave.

curl https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"

Which is better for you?

If you run bursts of dozens of clips and want them all in flight, the Fancy tier's unlimited parallelism is the stated advantage, though the page does not say how many generations actually run at once. If you want a predictable ceiling, a queue that accepts work rather than refusing it, and a USD balance, Sume's model is simpler to reason about. Compare your own burst size against the accepted-capacity column before choosing.