Skip to main content
Concurrency limits control how many requests your account can process at the same time. Requests beyond your limit are rejected with a 429 error code. Your concurrency limit is based on your lifetime paid spend, and applies at the platform level across all endpoints you call.
Concurrency limits are tuned over time to keep the platform fast and reliable for everyone. The specific values on this page reflect the current configuration and may change.

​
How it works

When you submit a request, the platform tracks it against your concurrency limit. If you exceed the limit, additional requests are rejected with a 429 error until in-flight requests complete.

​
Partner Node concurrency vs. Cloud job concurrency

This page covers the concurrency limit on Partner Node calls specifically. It’s a separate, independently enforced limit from Cloud job concurrency, which controls how many Comfy Cloud workflow runs you can have executing at once and is set by your Cloud plan or subscription tier rather than your lifetime spend. Because the two limits are enforced independently, your effective throughput is bounded by whichever one you reach first. A high Cloud plan does not, by itself, raise your Partner Node concurrency limit: that’s governed separately by the lifetime spend tiers below.

​
Concurrency tiers

Your concurrency limit is based on your lifetime paid spend: the total of all credit purchases and subscription payments across Comfy Cloud and Partner Nodes, combined. This total accumulates over the life of your account and does not reset or look back over a rolling window. Don’t confuse this with the committed-spend ceiling below: “committed spend” is money tied up in calls currently running, a separate bound that your tier also sets. The two numbers are otherwise unrelated. How to read this table:
  • First match wins. The rows are evaluated from most to least specific: a custom limit set by our team beats the spend tiers, which beat the never-paid floor. If you’ve paid $1,200 lifetime, you get 40, and the lower tiers are never considered.
  • Lifetime, not rolling. A payment from months ago still counts toward your tier. Spend doesn’t expire or reset over time.
  • Cloud and Partner Node spend both count. It doesn’t matter whether you paid for Cloud subscriptions or Partner Node credits; both contribute to the same lifetime total.
  • Any payment lifts you off the floor. Accounts that have never made a successful payment are capped at 1 concurrent call. A single successful payment moves you to the default tier (5), and the 100/100 / 500 / $1,000 thresholds raise it from there.
  • Custom limits override the table. If our team has set a specific limit on your account, for example for an enterprise arrangement or a policy restriction, it takes precedence over every spend-based row, including down to 0 (Partner Node access disabled).
Self-serve limits scale up to 40 concurrent requests at the $1,000 tier.

​
Model-based limits

Higher-cost models have a lower allowed concurrency. When you call a model that costs $5 or more per request, your concurrency limit for that model is one quarter of your account’s tier limit (rounded down, with a minimum of 1). Requests to lower-cost models continue to use your full account limit, and the two limits are tracked independently.

​
Committed-spend ceiling

The committed-spend ceiling is being rolled out, and the amounts it allows are tuned over time the same way concurrency limits are, so no specific ceiling is published here. Handle the 429 and the headers below whether or not you see this refusal on your account today.
Besides the count of simultaneous calls, your tier also caps the total USD value committed to your in-flight calls. A call holds its cost for as long as it runs, so the platform may also refuse a Partner Node call on this bound while you still have concurrency slots free: a few expensive calls can commit more value than a lot of cheap ones. “Committed spend” is money tied up in calls that are currently running. It is not your lifetime paid spend, which is the separate total that sets your tier. Your tier sets both ceilings, but the two numbers are otherwise unrelated. Both bounds share the same 429. The response detail says which one you hit: a committed-spend refusal tells you that the value committed to your calls still in flight has reached your ceiling. Only that refusal carries the X-Committed-Spend-* headers, so branch on the headers rather than on the message text: X-Committed-Spend-Remaining can be positive on a refusal, which isn’t a contradiction: the refused call cost more than the headroom that was left, and a cheaper call would still have been admitted. The retry story is the same as for the concurrency limit: the ceiling clears as your own in-flight calls finish. For the full 429 contract, including the error bucket and the other headers on the response, see the Comfy Router API reference.

​
How concurrency slots work

A Partner Node call occupies one concurrency slot for the full duration of that call: from the moment the request is accepted until the provider returns a result, which for video or 3D generation can take several minutes. The slot is released as soon as the call finishes. Only in-flight calls count against your limit. A completed call frees its slot immediately, so a workflow that makes many Partner Node calls over the course of its run will still complete successfully; it just can’t have more calls running at the same instant than your limit allows.

​
What happens when you reach your limit

When all your concurrency slots are occupied and you make another Partner Node call, that call is rejected immediately with an HTTP 429 status and a response body whose message tells you to wait for existing requests to complete.
  • The same 429 can also mean committed spend. A call is refused with the same status when your in-flight calls already commit as much value as your tier allows, even while concurrency slots are free. See Committed-spend ceiling.
  • A blocked account returns 403 instead. If Partner Node access has been disabled on your account (a custom limit of 0), calls are rejected with an HTTP 403 rather than a 429.
  • Concurrency is separate from your credit balance. Concurrency slots only govern how many calls can run simultaneously. If your credit balance reaches zero, calls fail because you’re out of credits, independent of how many concurrency slots you have free. Keep a positive balance to keep running.
  • Whether a throttled call is retried automatically depends on how you’re calling the API. Check the behavior of the specific node or client you’re using.

​
Concurrency response headers

Partner Node responses include headers that reflect your concurrency usage at the moment the request was processed. They’re set on both successful and throttled responses, for API key and other callers alike: These headers aren’t returned for accounts with an unlimited custom limit, and they’re best-effort: useful for visibility and debugging, but not intended as a precise scheduling signal.

​
Increasing your limit

For concurrency above 40, contact our support team.

Support

Get help raising your concurrency limit

​
FAQ

Per simultaneous (in-flight) call. There’s no cap here on total volume or how fast you make requests over time, only on how many can be running at once.
No. Your tier is based on lifetime spend, so past payments always continue to count toward it.
The two limits are separate. A high Cloud job concurrency doesn’t raise your Partner Node concurrency limit; that’s governed by lifetime spend instead. See Partner Node concurrency vs. Cloud job concurrency.