Crypto open-order count limits restrict how many orders can remain active within a venue-defined scope, often with separate limits for conditional or algo orders. Count confirmed orders and unresolved submissions across every consumer sharing that scope before reserving capacity for another plan. A free API request allowance or sufficient balance does not establish that an order slot is available.
A ladder can fit its cash budget and still fail halfway through placement. The scarce resource may be order capacity: one shared symbol limit, another conditional-order limit and an account-wide ceiling. The useful question is how many additional orders the whole account can support at the same time.
Identify which counter rejected the order
Three constraints can sound alike while measuring different things:
| Constraint | What it measures | What a passing check leaves unresolved |
|---|---|---|
| Open-order filter | Orders currently open within its defined scope | Other symbol, account or special-order filters |
| Interval-based order counter | Venue-defined order activity within a time window | Whether current open-order capacity exists |
| Request-rate allowance | Traffic or weighted requests within a window | Whether an otherwise permitted request can create an order |
Binance Spot's MAX_NUM_ORDERS includes normal and algo orders on a symbol; MAX_NUM_ALGO_ORDERS separately constrains designated stop-loss and take-profit order types. Its exchange-wide filters add account-level checks where applicable. Order-list limits are another dimension: a list count does not substitute for an individual-order count. Read Binance Spot's order-count filters, then obtain applicable current rules rather than treating documentation examples as live limits.
Binance's interval-based ORDERS counter has different lifecycle rules. Its FAQ says a first partial or full fill reduces that counter, potentially by more than one in specified cases, while cancellation or expiry does not. Updates can lag. It is tracked by account or subaccount and shared across API keys, IP addresses and APIs. See Binance's unfilled-order count rules. Therefore, canceling a working order can free a current-open slot without restoring the interval allowance.
The API rate-limit budget covers traffic and recovery bursts. The order-minimums worksheet covers size and value validity. Neither replaces the capacity check here.
Scope the inventory before counting it
Write the venue, environment, account, product, symbol and counted order class beside each limit. A total from one symbol cannot establish spare account-wide capacity. A new API key should not be assumed to create a new allowance.
Bybit illustrates the product distinction: its V5 placement documentation lists separate per-symbol active and conditional limits for perpetuals and futures, while describing Spot and Options limits differently. It also documents splitting an oversized reduce-only request into multiple orders. A single submitted instruction therefore need not always mean one resulting order. See Bybit's product-specific open-order limits.
Use authenticated order evidence with complete query coverage. Bybit's order-query endpoint provides order-class filters and cursor pagination; one response page is not automatically the complete inventory. See Bybit's open-order query parameters. Include manual trading and other software sharing the same account, not only orders created by the process doing the check.
A public order-book snapshot cannot reveal your untriggered conditional orders or establish your private quota. The order-book checksum guide addresses market-data integrity; account capacity needs its own evidence.
Two plans compete for the same last slots
The following invented account has three simultaneous constraints. These values are teaching inputs, not Binance or Bybit limits. Assume each proposed order consumes one total slot, and every proposed algo order also consumes one algo slot. No order lists, order splitting, fills, cancellations or external submissions occur during this example.
| Capacity dimension | Hypothetical ceiling | Confirmed open | Unresolved earlier submission | Available before new reservations |
|---|---|---|---|---|
| Symbol total | 12 | 9 | 1 | 2 |
| Symbol algo subset | 4 | 3 | 0 | 1 |
| Account total | 25 | 22 | 1 | 2 |
The earlier submission is one ordinary order on this symbol whose response was lost. It is not included in the confirmed-open column. Until its outcome is resolved, the planner assumes it could occupy one symbol slot and one account slot.
Plan A proposes an ordinary entry and an algo exit: two total slots and one algo slot. Plan B proposes one ordinary entry: one total slot and no algo slot.
Each plan fits when it independently reads the initial table. Together they do not. If the unresolved order exists and all three new orders are accepted, symbol usage would be 9 + 1 + 2 + 1 = 13 against 12. Account usage would be 22 + 1 + 2 + 1 = 26 against 25. The algo dimension reaches 4 and passes, which cannot rescue the failed total dimensions.
A shared reservation changes the decision:
| Decision | New reservation: symbol / algo / account | Remaining capacity: symbol / algo / account |
|---|---|---|
| Initial reconciled inventory | 0 / 0 / 0 | 2 / 1 / 2 |
| Reserve Plan A as one local decision | 2 / 1 / 2 | 0 / 0 / 0 |
| Evaluate Plan B against updated reservations | No reservation; defer | 0 / 0 / 0 |
This reserves capacity in the planner. It does not make the entry and exit an atomic exchange transaction or guarantee either will be accepted. Other rules, account changes and service failures still apply. If the plan depends on protection being present, separately define what happens when only part of it is accepted.
Keep one ledger entry as an order changes state
For each current-open capacity dimension, a conservative planning worksheet is:
available = ceiling − confirmed open − unresolved possible orders − other local reservations − policy buffer
Compare the proposed plan's full count vector against every applicable dimension. This is an operating model, not an exchange API formula, and it does not calculate interval-based counters. A negative result means the current ledger already exceeds its planning budget. Do not clamp it to zero and hide the discrepancy.
Avoid double counting the same request. Before submission it belongs to a local reservation. After confirmed acceptance it moves to confirmed open. After an ambiguous response it moves to unresolved capacity. It should not occupy all three buckets. A confirmed rejection releases the unused reservation; a terminal order releases its current-open capacity after reconciliation.
Do not reclaim a reservation merely because a local timer expired. The exchange may have accepted the request. If retries created several unresolved identities, one reserved slot no longer bounds the uncertainty. Follow the order-timeout reconciliation process before expanding commitments.
All cooperating consumers need to reserve against the same scope in one coordinated decision. A local ledger cannot control an independent manual trader or another uncoordinated application. Leave an explicit buffer where appropriate and treat exchange rejection as authoritative, even when local arithmetic passes.
Cancellation and expiry need evidence
A cancellation in flight remains a commitment in this model until its outcome is known. Similarly, a planned expiry time is not enough to infer the provider has removed the order. The good-till-date order guide examines timestamp granularity and execution around expiry.
Do not remove protective orders just to make room for optional entries. Identify each order's purpose and actual exposure before changing the inventory. A canceled entry can have earlier fills, and a replacement may introduce a second commitment; the cancel-replace race worksheet covers that reconciliation.
When reporting a capacity rejection, preserve the redacted provider code, applicable rule, inventory timestamp, unresolved identities and planned count vector. Record whether the request was explicitly rejected or still has an unknown outcome. Increasing retry speed cannot create capacity and can consume a separate request allowance.
The practical deliverable is a small ledger with ownership: which orders occupy each scope, which submissions remain unresolved, which future work already holds a reservation and who may release it. This article's worksheet is an original educational planning model prepared with AI assistance from official documentation reviewed on 23 October 2026. It does not represent a live account test or a claim about KLINEO's internal reservation implementation.