> ## Content Index
> Fetch the complete content index at: https://iteracompute.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# API key concurrency: model one account-wide admission budget
- URL: https://iteracompute.com/blog/api-key-concurrency-account-admission-budget/
- Published: 2026-10-29T05:42:11.000Z
- Updated: 2026-10-29T05:42:11.000Z
- Description: A runnable offline example shows how two API keys can exceed one shared account concurrency budget when each key admits requests independently.
- Author: IteraCompute
- Tags: LLM API, Concurrency, DeepSeek V4.1 Flash 1017

Adding another API key can make credential ownership clearer without adding another concurrency budget. For developers maintaining paid coding tools, this distinction belongs in the integration design: two workers can each respect a local limit while their combined traffic exceeds a shared account limit.

This tutorial uses a four-job offline simulation to make that aggregation error visible. All durations and the two-slot capacity are invented. The code runs with Python's standard library and performs no network requests. It demonstrates an admission model, not a production limiter or provider performance.

Establish the scope before choosing a number

The direct DeepSeek service's concurrency documentation, read on 29 October 2026, aggregates limits across API keys at the account level and counts a request until its response completes. Its ordinary accounts aggregate user IDs too; expanded accounts also have per-user constraints. Those are documented service rules, not measurements from this tutorial.

IteraCompute is a separate gateway. Its public Flash 1017 route is `deepseek/deepseek-v4.1-flash-1017`; the direct service's quota cannot be copied into that route's configuration. The gateway's effective account/model capacity, isolation mapping and cancellation behavior were not established here. Keep an unverified limit as unknown until the relevant owner confirms it.

Before building a queue, write down the supplier, account, exact model, limit scope, observation date and source. A key alias identifies a credential group in this example; it is not an independent quota allocation and contains no real secret. Request-rate and token-rate budgets require their own rules. A concurrency count alone does not establish how many requests or tokens a service can process each minute.

Four synthetic jobs, one account

Assume one model, one account and two available slots. Jobs are ordered by arrival time; equal arrivals retain their input order. There is no priority, preemption or fairness policy beyond that FIFO convention.

| Job | Key alias | Arrival (s) | Invented duration (s) |
| --- | --------- | ----------- | --------------------- |
| A   | one       | 0           | 4                     |
| B   | two       | 0           | 2                     |
| C   | one       | 0           | 1                     |
| D   | two       | 1           | 1                     |

With an account-wide gate, A and B start at zero. C waits for B's slot and starts at second 2\. D arrives at second 1, waits behind C, and starts at second 3\. The resulting intervals are A \[0,4), B \[0,2), C \[2,3), D \[3,4). Queue waits are 0, 0, 2 and 2 seconds. Peak concurrency is two.

Now incorrectly give each key two independent slots. A and C can start under key one, while B starts under key two. Three jobs overlap from second 0 to second 1\. This violates the invented account budget even though neither local key gate exceeds two.

D starts at second 1 under the second key. C ends at that same second, so the combined peak remains three. Count the intervals as half-open: an end at time t occurs before a new start at t. Counting both at the boundary would incorrectly report four. The figure visualizes these invented schedules on the same time scale; it is not a captured request trace.

Run the example without a key

Save the following as `simulate.py` and run `python3 simulate.py` with Python 3\. It validates unique local job IDs, aliases, integer arrivals and positive integer durations. It sorts arrivals stably, preserving the table's A/B/C order at second zero. `None` means unknown capacity and produces no schedule or inferred peak.

```
"""Offline teaching simulation; integer synthetic seconds, no network or API client."""
import heapq

def schedule(jobs, capacity):
    seen = set()
    for job in jobs:
        ident = job.get('id')
        if not isinstance(ident, str) or not ident or ident in seen:
            raise ValueError('Use unique non-empty job IDs')
        seen.add(ident)
        if not isinstance(job.get('key_alias'), str) or not job['key_alias']:
            raise ValueError('Use a non-secret key alias')
        for name in ('arrival_s', 'duration_s'):
            value = job.get(name)
            if type(value) is not int or value < (1 if name == 'duration_s' else 0):
                raise ValueError('Use non-negative integer arrivals and positive durations')
    if capacity is None:
        return {'state': 'unknown_capacity', 'rows': None, 'peak': None}
    if type(capacity) is not int or capacity <= 0:
        raise ValueError('Capacity must be a positive integer or None')
    free_at = [0] * min(capacity, len(jobs))
    rows = []
    # Python sorting is stable: equal arrivals retain their input order.
    for job in sorted(jobs, key=lambda row: row['arrival_s']):
        start = max(heapq.heappop(free_at), job['arrival_s'])
        end = start + job['duration_s']
        heapq.heappush(free_at, end)
        rows.append({**job, 'start_s': start, 'end_s': end,
                     'wait_s': start - job['arrival_s']})
    return {'state': 'synthetic', 'rows': rows, 'peak': peak(rows)}

def peak(rows):
    # Half-open intervals: an end (-1) sorts before a start (+1) at a tie.
    events = [(row['start_s'], 1) for row in rows]
    events += [(row['end_s'], -1) for row in rows]
    active = maximum = 0
    for _, change in sorted(events):
        active += change
        maximum = max(maximum, active)
    return maximum

JOBS = [
    {'id': 'A', 'key_alias': 'one', 'arrival_s': 0, 'duration_s': 4},
    {'id': 'B', 'key_alias': 'two', 'arrival_s': 0, 'duration_s': 2},
    {'id': 'C', 'key_alias': 'one', 'arrival_s': 0, 'duration_s': 1},
    {'id': 'D', 'key_alias': 'two', 'arrival_s': 1, 'duration_s': 1},
]

if __name__ == '__main__':
    shared = schedule(JOBS, 2)
    separate = []
    for alias in ('one', 'two'):
        separate += schedule([j for j in JOBS if j['key_alias'] == alias], 2)['rows']
    assert [j['start_s'] for j in shared['rows']] == [0, 0, 2, 3]
    assert [j['wait_s'] for j in shared['rows']] == [0, 0, 2, 2]
    assert shared['peak'] == 2
    assert peak(separate) == 3
    assert schedule(JOBS, None)['peak'] is None
    print({'shared': shared, 'separate_key_peak': peak(separate),
           'gateway_capacity': None})
```

The printed shared schedule has starts \[0, 0, 2, 3\], waits \[0, 0, 2, 2\] and peak 2\. The independently admitted key schedules have combined peak 3\. The gateway capacity stays `None`. These values describe only the synthetic workload above.

We executed the displayed code locally. Additional controls checked the equal-time boundary, an empty workload, out-of-order arrivals, a one-slot schedule and the four-slot peak. Rejection controls covered zero/negative/boolean/fractional capacities, negative arrivals, boolean/zero/fractional durations, an empty alias and duplicate IDs. An empty simulation has peak zero; this says nothing about a live service's demand or billing.

Use the simulation to review ownership

A production design needs an admission owner matching the actual quota scope. If multiple processes or machines share an account budget, an in-process semaphore per key cannot by itself coordinate their total. Choose a coordination mechanism suited to the real deployment and validate it separately; this example implements no distributed synchronization, persistence, failover or leases.

Keep at least three clocks distinct in an authorized trial: arrival at the application's queue, sending to the provider, and observed response completion. Queue wait is computed from arrival to local admission here. In a live system, transport and service timings require actual observations and consistent clocks. The invented durations cannot predict tail latency, throughput or how much capacity a particular coding workload needs.

Cancellation needs an explicit unresolved state. Stopping a client wait does not establish that server work has stopped or that an account slot is available again. Decide which provider-specific signal confirms completion or cancellation, and how to reconcile missing evidence. The simulation assumes its predetermined end times are known; it does not implement that reconciliation. It also omits retries, rate limits, token budgets, backpressure, bounded queues, timeouts and tenant fairness.

A useful capacity handoff therefore contains an observed limit and its scope, the admission owner, a local queue record, a completion/cancellation evidence rule and a list of unresolved cases. Keep prompts and credentials out of routine capacity logs. Model quality, token usage and charges need separate records; accepting a job within a concurrency budget does not establish its cost or successful task outcome.

Evidence and next step

This article is prepared for IteraCompute. It uses no customer trace, model request, SDK integration, gateway load test or invoice. It makes no claim about live IteraCompute capacity, performance, savings, isolation guarantees or SLA.

The [IteraCompute Flash 1017 model page](https://iteracompute.com/models/deepseek-v4-1-flash-1017/) was read as a route reference, not as evidence of a verified capacity allocation. The code and synthetic inputs are included in full above; no private repository access is required to run them.

Before setting an admission budget, [read the direct provider's current concurrency contract](https://api-docs.deepseek.com/quick%5Fstart/rate%5Flimit/) and confirm the separate contract for the endpoint your application actually uses.