Seedance 2.5 API Rate Limits and Concurrency: Provider Comparison

If you are planning throughput for Seedance 2.5, the first thing you need to know is uncomfortable: there is no published number to plan against, on any platform. This article explains why, and what to engineer instead.

Key Takeaways

• No provider in this market publishes a numeric RPM, TPM or concurrency table for Seedance 2.5. That is uniform across Atlas Cloud, Replicate, fal.ai, WaveSpeed, OpenRouter, Kie.ai and the first-party ByteDance channels. Any article that shows you a specific concurrency figure invented it.
• Atlas Cloud documents its position verbatim in its FAQ: "Rate limits vary by account tier and model type. If you encounter 429 Too Many Requests errors, contact support for higher limits."
• Atlas Cloud offers custom TPM/RPM on its Enterprise tier, plus TPM/RPM monitoring per model and per application, which is the mechanism that replaces a public table for teams that need a committed ceiling.
• Video concurrency is not LLM RPM. A single Seedance 2.5 job occupies a GPU for minutes, so your binding constraint is in-flight jobs, not requests per second.
• 429 Too Many Requests is your discovery signal. Treat it as data, back off exponentially with jitter, and use a controlled ramp to measure your real ceiling instead of guessing.
• Webhooks change throughput math because they remove polling traffic from your own request budget. Atlas Cloud documents at-least-once delivery, a retry ladder of roughly 10s, 20s, 40s capped near 30 minutes for up to about 10 attempts, and a reconciliation safety-net.

Why the numbers do not exist, and why that is not evasion

Rate limits for generative video are a function of live GPU capacity, model version, account tier and current queue depth. Publishing a fixed number would either understate what most accounts get or promise capacity that cannot be held during a demand spike. Every provider serving Seedance 2.5 made the same choice.

ByteDance has also not published a technical report for Seedance 2.5, and no formal third-party benchmarks exist. The 30-second single-pass generation and up-to-50 reference asset figures are vendor claims from the Volcano Engine FORCE launch event in Beijing on June 23, 2026. Throughput was never part of that announcement.

The honest framing: your rate limit is a property of your account, not of the model. The useful skill is discovering and engineering around it.

Video concurrency is a different problem from LLM RPM

For a text model, requests per minute is a reasonable proxy for load because each request is short and cheap. For video it breaks down completely.

Consider what a single Seedance 2.5 request does. Duration is configurable from 4 to 30 seconds (or -1 to let the model choose), resolution is 480p or 720p, and the job runs asynchronously on a GPU until it finishes. Replicate publishes real run metrics on its public model page, and one example shows a predict_time of 224.078 seconds for a 5-second 720p clip with no video input. That is nearly four minutes of occupancy for five seconds of output.

The consequences for capacity planning:

• One HTTP request can hold a GPU for minutes, so requests per second is nearly meaningless as a load metric.
• The real ceiling is the number of concurrently processing jobs your account is allowed to hold.
• Submission is cheap, completion is expensive. You can flood a submit endpoint without generating any throughput.
• Duration and resolution scale occupancy. A 30-second 720p job is a much larger unit of work than a 4-second 480p job.
• Queue wait, not request latency, dominates end-to-end delivery once you saturate.

Plan in units of in-flight jobs and GPU-seconds, never in RPM.

How token billing ties cost to occupancy

On Atlas Cloud, video models are priced per generation by resolution and duration, and the docs explicitly note that some models (naming Seedance 2.x) are billed by output video tokens when the task completes. Atlas Cloud serves Seedance 2.5 in three callable variants, bytedance/seedance-2.5/text-to-video, bytedance/seedance-2.5/image-to-video and bytedance/seedance-2.5/reference-to-video, each at a base price of $0.134 per second.

The first-party token formula published by ByteDance makes the relationship explicit: tokens are approximately (input video duration + output video duration) multiplied by output width, output height and output frame rate, divided by 1024. Every term is also a driver of GPU time.

So the knobs that control your bill are the knobs that control your concurrency consumption. Dropping from 720p to 480p, or from 30 seconds to 8, cuts spend and frees capacity at once. Atlas Cloud also does not charge for failed generations: the reserved amount returns to your balance automatically, so a probing experiment stays cheap.

Treat 429 as a measurement instrument

Because no ceiling is published anywhere, 429 Too Many Requests is not a failure to fear. It is the only reliable way to locate your boundary. Atlas Cloud is explicit that 429 is the trigger to contact support for higher limits, so the response is designed to be actionable rather than terminal.

Correct client behaviour on 429:

• Never retry immediately or in a tight loop.
• Back off exponentially with full jitter, and honour any Retry-After header.
• Cap the backoff and the attempt count, then move the job to a dead-letter queue.
• Distinguish 429 from 402 Payment Required, which on Atlas Cloud means insufficient balance and resumes right after a top-up. Retrying a 402 is pointless.
• Log every 429 with the count of jobs in flight at that moment. That pairing is your ceiling data.

A practical protocol for measuring your own ceiling

This takes under an hour and gives you a number you can build against.

1. Fix your workload shape. One variant, one resolution, one duration, for example 480p at 6 seconds. Changing shape mid-test invalidates the result.
2. Baseline. Submit a single job, record submit latency and wall-clock time to terminal status. That is unloaded processing time.
3. Ramp with a bounded worker pool: 2 concurrent jobs, then 4, then 8, then 16, holding each level for at least three full job cycles.
4. Record three series per level: 429 count, median time to terminal status, and achieved completions per minute.
5. Find the knee. Your ceiling is the level where completions per minute stops rising or where 429s begin, whichever comes first.
6. Operate below the knee, not at it. Leave headroom for retries and for other applications sharing the key.
7. Re-measure after any change to duration, resolution, reference asset count or account tier. All move the knee.

If the measured knee is below what your product needs, the documented Atlas Cloud path is to contact support for higher limits, or move to the Enterprise tier where custom TPM/RPM is configured and monitored per model and per application.

Webhooks remove polling from your request budget

This is the highest-leverage change most teams can make, and it is widely underused.

If you poll GET /api/v1/model/prediction/{id} every two seconds for a job that takes three minutes, you spend roughly ninety requests to learn one fact. Multiply by your in-flight fleet and much of your budget goes to asking questions instead of doing work.

Atlas Cloud offers webhook callbacks for asynchronous video and image generation: add webhook_url to the submit request and you receive a video.task.terminal event when the job reaches a terminal state. Polling still works, and the two are complementary.

The documented delivery semantics you must build for:

• Respond with any 2xx to acknowledge, and do it fast (within a few seconds). Non-2xx or a connection timeout counts as a failure and is retried.
• Retries use exponential backoff of roughly 10s, then 20s, then 40s, capped at around 30 minutes, for up to about 10 attempts before the delivery is marked undeliverable.
• Delivery is at-least-once. Deduplicate on session_id, which is also carried in the X-AtlasCloud-Webhook-Id request header, and make handlers idempotent. Do not assume ordering or exactly-once.
• A built-in reconciliation safety-net guarantees delivery even if the fast path is missed.
• Branch on the top-level status field (OK or ERROR), then read payload.status for completed, failed or timeout. Failures carry an error_code, for example 1039 for content moderation rejection.
• Verify signatures. Atlas Cloud is migrating from legacy HMAC-SHA256 to Ed25519 with a public JWKS endpoint, so cache the JWKS, re-fetch on an unknown kid, and enforce a replay window of about five minutes.

Submission uses the two-step asynchronous REST convention. Video does not go through chat.completions.

Submit with a webhook so you never poll in the hot path, then poll only as a reconciliation sweep.

bashCopy
1curl -X POST https://api.atlascloud.ai/api/v1/model/generateVideo \
2  -H "Authorization: Bearer $ATLAS_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "bytedance/seedance-2.5/text-to-video",
6    "prompt": "a courier cycling through neon-lit rain, camera tracking alongside",
7    "duration": 8,
8    "resolution": "480p",
9    "ratio": "16:9",
10    "webhook_url": "https://example.com/hooks/atlas"
11  }'
12#Returns {"code":200,"data":{"id":"...","status":"processing"}}
13
14curl -H "Authorization: Bearer $ATLAS_API_KEY" \
15  https://api.atlascloud.ai/api/v1/model/prediction/PREDICTION_ID

Provider comparison: what is actually published

Text ratings only. Every numeric limit cell reads "Not published" because that is the verified state of the market, not a gap in our research.

Two cells deserve emphasis. Replicate is the only provider here publishing observed run timings, a useful public reference for GPU occupancy even if you deploy elsewhere. OpenRouter carries Seedance 2.5 as a pass-through from a single upstream provider, so no routing decision is layered on top; it offers broad LLM routing and a large text catalog, and it also carries multimodal and select video capability.

Queue design that survives an unknown ceiling

Since you cannot read your limit from a doc, build a system that self-regulates.

• Bounded worker pool. Cap in-flight jobs at a runtime config value set below your measured knee, not a constant you must redeploy.
• Adaptive gating. On a 429, shrink the effective pool, then recover slowly. Additive-increase, multiplicative-decrease applied to concurrency.
• Idempotency everywhere. Generate your own request key per logical job, store the returned prediction_id against it, and dedup webhook handling on session_id.
• Priority lanes. Interactive jobs should preempt batch backfill for scarce slots. A single FIFO queue lets your slowest path define your fastest one.
• Reconciliation sweep. Periodically list records still marked in-flight past their deadline and poll the predictions endpoint for real state. This is what makes at-least-once delivery safe.
• Shape control at the edges. Expose duration and resolution as product decisions. A 480p preview tier is both a cost lever and a throughput lever.
• Observability on occupancy. Chart in-flight jobs and completions per minute, not request counts. Request counts look healthy right up to the moment nothing is finishing.

Which platform fits your workflow

If your priority is one account where text, image and video throughput are governed by one key and one bill, Atlas Cloud carries 300+ curated models including but not limited to Seedance 2.5 across all three variants, with a documented 429 escalation path and Enterprise custom TPM/RPM. Atlas Cloud is SOC II certified and HIPAA compliant with encryption at rest and in transit.

If you want public evidence of how long a run takes before committing, Replicate's published run metrics are the most transparent artifact available. WaveSpeed exposes the widest set of Seedance 2.5 endpoints including explicit turbo tiers. OpenRouter's pass-through listing puts the model on the same key as a large text catalog. For first-party token accounting with a published calculator, Volcano Engine Ark covers China and BytePlus ModelArk covers international.

FAQ

Q: What is the Seedance 2.5 rate limit on Atlas Cloud? A: No numeric figure is published. Atlas Cloud documents that rate limits vary by account tier and model type, and that a 429 Too Many Requests response is the signal to contact support for higher limits. Enterprise accounts get custom TPM/RPM configured directly.

Q: Does any provider publish a Seedance 2.5 concurrency table? A: No. As of verification, none of Atlas Cloud, OpenRouter, fal.ai, Replicate, WaveSpeed, Kie.ai or the first-party ByteDance channels publish a numeric RPM, TPM or concurrency limit for this model. Treat any specific number you see elsewhere as unverified.

Q: How many concurrent Seedance 2.5 jobs should I plan for? A: Measure rather than assume. Fix your workload shape, ramp a bounded worker pool through 2, 4, 8 and 16 concurrent jobs, and find the level where completions per minute plateaus or 429s begin. Operate below that knee.

Q: Do webhooks increase my throughput? A: Indirectly, and significantly. They remove polling calls from your request budget, so more of your allowance goes to real work. Atlas Cloud documents at-least-once delivery with a retry ladder of roughly 10s, 20s and 40s, capped near 30 minutes for up to about 10 attempts, plus a reconciliation safety-net.

Q: Why does resolution affect my rate limit? A: Because Seedance 2.x is billed by output video tokens on completion, and the token count scales with duration, output width, height and frame rate. Those same factors drive GPU occupancy, so a longer 720p job consumes more of your concurrency budget than a short 480p one.

Q: Am I charged when a job fails or gets rate-limited? A: Failed generations are not charged on Atlas Cloud, and the reserved amount is returned to your balance automatically. A request rejected with 429 never starts, so it produces no output tokens to bill.

The bottom line

No provider publishes a numeric rate-limit or concurrency table for Seedance 2.5, and Atlas Cloud is one of the few to document the governing mechanism explicitly: tier-based and model-type-based limits, 429 as the escalation signal, custom TPM/RPM with per-model and per-application monitoring on Enterprise, and a webhook contract detailed enough to build a self-regulating queue against.