How much of SWE-bench Pro can 64 DeepSeek agents solve in a day?

A Doubleword inference deployment running 64 independent coding agents powered by DeepSeek-V4-Pro completed all 46,784 attempts across SWE-bench Pro's 731 public problems in 20 hours and 23 minutes on a single 8×B300 node, while the SGLang baseline averaged 10.7 problems per agent and throughput-oriented SGLang averaged 24.8 in 24 hours. The Doubleword deployment delivered roughly 30× the request and token rates of throughput-oriented SGLang, which itself more than doubled the SGLang baseline's throughput. A single agent solved 51.2% of the benchmark on average, and accepting a solution from any of the 64 agents raised that to 70.7%, a 19.5-point improvement.

How much of SWE-bench Pro can 64 DeepSeek agents solve in a day? Coding agents can now spend hours on a single task, making hundreds of model calls as they inspect code, edit files and test changes.<sup 1 user-content-fn-agent-demand </sup Each call carries the history of the work so far. As that history grows, so does the share of each new request that the inference system has already processed. That repeated history creates an opportunity to reuse computation, but with many agents working in parallel, their histories compete for memory. While one agent is away running a test, others claim that space for their own next steps, and whether its history survives until its next call determines how much compute goes towards new work and how much towards reconstructing the past. To see how this plays out at scale, we gave 64 independent coding agents, powered by DeepSeek-V4-Pro, all 731 problems in SWE-bench Pro’s public split: 46,784 attempts to complete within 24 hours . On a single 8×B300 node, we compared the Doubleword inference stack with two SGLang deploymentsSGLang is here as a reference, not a target. The aim is to show what the Doubleword inference stack can do on the same hardware., one keeping the default server settings and one using SGLang’s recommended throughput-oriented configuration. 2 user-content-fn-serving-configurations In 24 hours, the agents worked through an average of 10.7 of their 731 problems each with the SGLang baseline and 24.8 with throughput-oriented SGLang . With the Doubleword deployment, every agent finished its full list in 20 hours and 23 minutes . Figure 1. Cumulative completed attempts during the first 24 hours, shown on a logarithmic vertical axis. What’s really interesting is how much the extra attempts helped. In the completed Doubleword run, a single agent solved 51.2% of the benchmark on average, and accepting a solution from any of the 64 raised that to 70.7% , a 19.5-point improvement. At the engine level, the Doubleword deployment delivered approximately 30× the request and token rates of throughput-oriented SGLang , which itself achieved more than twice the SGLang baseline’s throughput. Figure 2. Engine throughput relative to the SGLang baseline, measured over each deployment’s saturated-serving window, the period in which every agent still had fresh problems to keep its configured concurrency. That is the first 24 hours for both SGLang deployments, which never ran short of problems, and the first 15.96 hours for Doubleword, after which its finite schedule began to drain. Brackets show Doubleword’s gains over throughput-oriented SGLang. From benchmark task to inference workload from-benchmark-task-to-inference-workload SWE-bench Pro presents an agent with a repository at a fixed commit and an issue describing a bug to fix or functionality to add. For each attempt, the agent works in an isolated copy of the repository and submits its changes as a Git patch. Each of the 64 agents can work on several problems concurrently, starting the next in its list whenever an attempt finishes.We allowed 5 concurrent attempts per agent with the SGLang baseline, 15 with throughput-oriented SGLang and 40 in the Doubleword run, giving up to 320, 960 and 2,560 active attempts across the 64 agents. These limits were chosen to keep each inference stack supplied with work. The full schedule remained 46,784 attempts for every deployment. We use the benchmark’s own fork of mini-swe-agent to drive the agent loop.<sup 3 user-content-fn-agent-settings </sup At each step, the harness sends DeepSeek-V4-Pro the problem statement and the conversation so far. The model responds with a bash command, which the harness executes in the attempt’s sandbox before appending the model’s response and command output to the conversation. Every subsequent request includes the full accumulated history, without truncation or summarisation. We call the full sequence of model calls and command results from a single attempt a trajectory. Figure 3. Mini-swe-agent coordinates model calls through the shared Responses API and command execution through SWE-ReX in the attempt’s Modal sandbox. In the completed Doubleword run, the median trajectory made 66 model calls. Prompts typically grew from roughly 1,400 tokens on the first call to 48,000 on the last, yet in over half of these attempts, less than 0.25% of the final prompt was new input. Responses were much shorter, with a median length of 75 tokens across all calls and a long tail extending into the thousands. Figure 4. The upper panels show medians and percentile bands across trajectories at the same relative call position. New input is estimated from token counts relative to the preceding prompt and model response. The lower panel shows the density of all recorded model calls, with median response length within input-length bins. Where the 30× over throughput-oriented SGLang comes from where-the-30-over-throughput-oriented-sglang-comes-from The throughput-oriented SGLang deployment served 110 requests per minute, roughly 2.3× the baseline’s rate.We take throughput-oriented SGLang as the comparator throughout the analysis below and do not examine its improvement over the baseline. On the same 8×B300 node, the Doubleword deployment served 3,289 requests per minute, a further 30× increase. On average, the Doubleword deployment advanced 5.27× as many output tokens per local decode step and completed those steps 6.08× as often. Responses were 7.3% longer, so the increase in completed requests was approximately 6 user-content-fn-throughput-model To see what drives these two factors, we write down the cost of serving a request. When an agent returns from a tool call, much of its input is history the server has already processed. The server can reuse the portion still in cache and prefill the rest. If a fraction of input tokens comes from cache, an average request of tokens leaves uncached tokens. Processing those tokens costs GPU-capacity seconds per request, where is the effective cost per input token. During generation, requests in the same batch share the cost of loading model weights, while attention reads each request’s history. The effective cost per output token, , therefore depends on batch width and context length . A request incurs its prefill cost once. We divide that cost across the tokens in its response and add the decode cost per token. A local decode step advances tokens on its GPU, giving an average elapsed time of 6 user-content-fn-throughput-model Across eight GPUs, the output rate is . Dividing by the average response length gives the completed-request rate: The final expression exposes two levers for increasing throughput, the share of input the server reuses and the number of requests it batches during decode . Prefill: reusing agent history prefill-reusing-agent-history Figure 7. Share of input tokens served from the prefix cache over the measurement windows used in the throughput comparison. The Doubleword deployment supplied 98.1% of input tokens from cache, compared with 2.16% for throughput-oriented SGLang. That gap comes down to differences in how the deployments route returning requests and retain history between calls. Each worker holds its own cache, so routing decides which copy of an agent’s history its next call reaches, and retention decides how much of that copy is still there when the call arrives. Potential reuse: the history a returning request can reach potential-reuse-the-history-a-returning-request-can-reach We first estimate how much input each deployment could reuse if no cached history were evicted. For each problem, all 64 agents start with the same opening prompt and then build separate histories of model responses and tool results. A call can therefore reuse the history its own trajectory left behind, or another trajectory’s copy of the shared opening prompt. We count the first and set the second aside.Sharing depends on whether another agent ran the same problem on the same worker recently enough for its copy to survive, which a trajectory's own record cannot show. Leaving it out can only lower the estimates. The Doubleword inference stack balances trajectories across the eight workers while preserving affinity, so successive calls usually return to the worker that served the preceding call. For each call recorded during the Doubleword run, we count the input tokens, , and the tokens covered by the same trajectory’s history from calls earlier, . With ideal affinity, , giving potential reuse of 7 user-content-fn-prefill-opportunity Throughput-oriented SGLang assigns requests round robin. While an agent is away using tools, other agents’ requests advance the dispatcher, so its next call can reach a different worker.<sup 8 user-content-fn-prefill-routing </sup Suppose an agent’s calls land on worker 2, then 6, then 2 again. On the third call, the agent finds only a copy of its history two calls old; worker 2 has not seen the work that went through worker 6. At best, a returning call reaches the copy from the last time its landing worker served the agent, and that can be any number of calls back. To model the interleaved traffic, we treat the worker each call lands on as an independent uniform choice among the eight, and let count the calls since the agent last used call ‘s landing worker. For the recorded calls in the SGLang run, we weight the tokens each copy of age covers by the probability of landing on its worker: Routing costs SGLang only part of its ceiling, 83.7% against the 98.2% that affinity preserves, and even the reduced ceiling sits far above the 2.16% of input the run actually supplied from cache. Return intervals: what the history must survive return-intervals-what-the-history-must-survive After a request finishes, the worker holding its history continues processing requests from other trajectories while the agent uses tools or waits. Those requests need KV cache space and can evict the retained history. Let count the requests that start on that worker before the trajectory’s next request begins execution, whichever worker handles it. With trajectories in flight and an average of of them executing a request, are away between executions at any moment. Assuming steady throughput and balanced admissions across the eight workers, the mean gap is then The two runs’ recorded populations give: | Deployment | Trajectories in flight, | Mean executing requests, | Mean gap, | |---|---|---|---| | Doubleword | 2,560 | 1,958 | 75 requests | | Throughput-oriented SGLang | 960 | 466 | 62 requests | Since the Doubleword inference stack routes a trajectory’s requests to the same worker, the history only needs to survive until the next request begins execution. If the history lasts requests on its worker, the probability it survives until reuse isThe populations give only the mean gap, so the distribution's shape is an assumption. We take to be geometric with , and the wait then falls short of a lifetime of requests with probability . With SGLang’s round-robin routing, a trajectory’s next request may run on another worker, so the wait before a copy is reused can span several requests. In the worker-2 example, the history on worker 2 waits through a gap while the agent uses tools, an execution while its call runs on worker 6, then a second gap before the agent returns. Let count the other requests that start on the holding worker before a copy from requests earlier is reused, and those that start while one of the trajectory’s own requests executes elsewhere, with mean under balanced admissions. The first two cases give Each further request on another worker adds another execution and another gap:We take each and to be geometric with its own estimated mean, with probability mass functions and , and treat the counts as mutually independent, so that With this reduces to the Doubleword formula. We also assume the counts are unrelated to which workers the calls land on and to how much input each copy covers. Not only does an older copy cover less of the input, but its longer wait also leaves it less likely to survive until reuse. Cache residence: how quickly other requests displace history cache-residence-how-quickly-other-requests-displace-history The return intervals measured how much competing traffic a history must survive; whether it does depends on its cache residence , the number of subsequent requests it lasts on the holding worker before being displaced. That is a contest between the available cache capacity and the new allocations each request makes. Throughput-oriented SGLang retains cached history in the GPU’s high-bandwidth memory HBM . The KV state of executing requests is protected from eviction, so new allocations use the remaining capacity, filling free slots or displacing idle histories. If an agent’s history is displaced while it uses tools or waits, the missing state must be reconstructed when it returns. The Doubleword inference stack extends retention into the server’s host memory, backing up reusable KV there so that HBM can be reclaimed while the history remains recoverable. When an agent returns, surviving state can be restored to the GPU instead of reconstructed from the prompt. We model host memory simply as additional retention capacity beyond the HBM that executing requests leave free. 9 user-content-fn-host-tier-model For either deployment, reusing a cached prefix requires both forms of its KV history intact, the compressed state and the uncompressed SWA tail covering its final 128 tokens. Losing that short tail can make a much longer compressed prefix unusable. The two forms occupy separate cache pools: 10 user-content-fn-prefill-capacity | Available capacity per worker, in token slots | Doubleword deployment | Throughput-oriented SGLang | |---|---|---| | Compressed-history pool | 19,759,616 | 3,474,944 | | SWA pool | 493,568 | 157,248 | Although only its final 128-token tail stays reusable, SWA state is produced for every token processed, so new history presses on both pools alike. We model each uncached input token and each generated output token as allocating one logical slot in each pool, giving a mean allocation count per request of Under this allocation model, the smaller SWA pool limits residence, so its available capacity sets Hit rate: combining reuse and survival hit-rate-combining-reuse-and-survival The three quantities now in hand decide how often a returning call still finds its history. For either deployment, the modelled hit rate isFor the Doubleword deployment, all reachable input shares the preceding copy's survival, so . For SGLang, the tokens reachable at each copy age survive with that age's probability, so Solving with the runs’ recorded means, roughly 31,000 input tokens and 220–240 output tokens per request, gives:For the Doubleword deployment, the hit-rate equation has more than one self-consistent solution. The measured regime picks which one to compare, but the solution's value comes from the inputs alone, none of which use the measured hit rate, so the match is a real test. What the model cannot do is predict that the deployment reaches this regime rather than another. | Quantity | Doubleword deployment | Throughput-oriented SGLang | |---|---|---| | Mean gap | 75 requests | 62 requests | | Modelled residence | 591 requests | 5.07 requests | | Modelled hit rate: own-trajectory reuse | 98.12% | 1.13% | | Measured total hit rate | 98.08% | 2.16% | For SGLang, a history survives roughly 5 requests on its worker, far fewer than its mean gap of 62, so the copy is nearly always displaced before its agent’s next call arrives, and older copies fare worse still. For the Doubleword deployment, a history survives roughly 600 requests, eight times its mean gap of 75, so it is nearly always still there when its agent returns. For the Doubleword deployment, the modelled 98.12% is consistent with the measured 98.08%. For SGLang, the modelled 1.13% covers only reuse from a trajectory’s own history. The run also drew on the shared opening prompt, kept refreshed in cache by other agents’ calls. If we count the prompt as cached for every call, bounding what sharing could add, the modelled rate rises to 5.70%.With the prompt's share of input , its cached copy's survival , and the rest of the reachable history , the hit rate becomes Setting gives the bound. For the Doubleword deployment, the solution rises from 98.12% to 98.19%. The measured 2.16% lands in between. With the modelled and measured rates in agreement, the two runs read as outcomes of the same feedback loop. In the Doubleword run, the cache supplied most of each request’s input, so histories survived until their agents returned and reuse stayed high. In the throughput-oriented SGLang run, the cache supplied little, so new allocations displaced the idle histories on each worker and reuse stayed low. Decode: keeping generation batches full decode-keeping-generation-batches-full The Doubleword deployment advanced an average of 241 requests in each local decode step, compared with 45.7 for throughput-oriented SGLang.<sup 11 user-content-fn-decode-backlog </sup Part of that gap is expected. Each time a request finishes generating, the batch loses a member, and a queued request can replenish it only after completing prefill. A returning Doubleword request leaves little to prefill, while an SGLang request reconstructs nearly its whole history before it can replenish the batch. Ordinarily SGLang’s scheduler runs prefill on any pass where a worker has queued work and room in its cache, and decodes only when it cannot.<sup 12 user-content-fn-decode-prefill-first </sup Yet half of the decode passes logged in the throughput-oriented SGLang run were taken with dozens of requests waiting and caches less than half full. 13 user-content-fn-decode-cadence The exception follows from DP attention. Each worker runs attention for its own batch, but every other layer still runs across all eight GPUs together, so the workers’ forward passes move in lockstep. A worker prefilling alone can stall its seven peers on its longer attention computation; eight prefilling together pay that wait once. When to prefill is therefore a central decision for either deployment. SGLang decides with its prefill delayer, which waits to admit queued requests until every worker has one to prefill, and can wait for up to 29 of every 30 forward passes.<sup 14 user-content-fn-decode-coordination </sup A worker whose queue runs empty can therefore hold its backlogged peers’ admissions back while their finished requests keep leaving the batches. Such a worker stood beside a backlogged peer for 47.0% of the SGLang run and 2.2% of the Doubleword run. 15 user-content-fn-decode-queues Figure 8. Lines show the requests running across each node’s eight workers, sampled every 10 seconds and summarised as five-minute medians. The medians can hide brief drops within a bin. Orange shading shows the share of samples in each bin with one worker’s queue empty while another held at least 20 waiting requests. Whether a queue stays supplied comes down to where each agent’s next call lands. Round robin lands them in turn, regardless of which worker completed the preceding call or how much work is already queued. A worker that runs ahead of its peers therefore drains its queue, while the follow-ups to the requests it finishes go to peers whose queues are growing. Because the Doubleword inference stack preserves affinity, each returning call lands on the worker that served the preceding one. Each worker’s arrivals then rise and fall with its own completions, and queues do not run empty beside backlogged peers. What cheaper inference makes possible what-cheaper-inference-makes-possible The Doubleword run spent $0.049 of node time on each completed attempt, so all 64 attempts at a problem came to $3.13 , less than the cost of one attempt on the SGLang baseline and less than two on throughput-oriented SGLang.<sup 16 user-content-fn-benchmark-cost </sup And so, the 19.5-point higher score on SWE-bench Pro from 64 attempts per problem, served by the Doubleword inference stack, comes for roughly the spend of a single attempt per problem on the SGLang baseline. | Deployment | Measured window | Completed attempts | Cost per attempt | |---|---|---|---| | SGLang baseline | 24 h | 687 | $3.92 | | Throughput-oriented SGLang | 24 h | 1,586 | $1.70 | | Doubleword | 20 h 23 min | 46,784 | $0.049 | Buying intelligence with repeated sampling raises a broader question of whether open-weight models can be competitive with proprietary frontier models at the same inference spend. We compare DeepSeek-V4-Pro with the frontier of its generation, Gemini 3.1 Pro Preview, GPT-5.6 Luna, Terra and Sol, and Claude Opus 4.8. For each, we estimate what one attempt per problem would cost at the provider’s published rates,<sup 17 user-content-fn-provider-cost </sup and count how many DeepSeek-V4-Pro attempts the same budget funds. The comparison is then DeepSeek-V4-Pro’s score across those attempts, its pass@k, against the proprietary model’s published single-attempt score, its pass@1. 18 user-content-fn-passk-method Figure 9. Inference spend is totalled across all 731 problems and shown on a logarithmic horizontal axis. Labels on the curve give attempts per problem. What’s incredible is that DeepSeek-V4-Pro does in fact compete with all five, keeping pace even with Opus 4.8, the strongest performer in the group. Opus’s estimated $1,368 for the benchmark buys 38 attempts per problem from DeepSeek-V4-Pro, scoring 69.5% against Opus’s 69.2% . 19 user-content-fn-budget-comparison This is what cheaper inference makes possible. Each attempt draws from the model’s distribution, repeated draws raise the likelihood that a correct solution surfaces, and better tokenomics buys the draws. Serving efficiency therefore unlocks parallel test-time scaling and offers open-weight models a practical route to frontier capability. Footnotes footnote-label 1. OpenAI, How agents are transforming work https://openai.com/index/how-agents-are-transforming-work/ , 25 June 2026. ↩ user-content-fnref-agent-demand 2. Both SGLang deployments used the stock lmsysorg/sglang:v0.5.14-cu130-runtime container. The throughput-oriented deployment followed the SGLang cookbook https://lmsysorg.mintlify.app/cookbook/autoregressive/DeepSeek/DeepSeek-V4 hw=b200&variant=pro&quant=fp4&strategy=high-throughput&nodes=single , with the global running-request limit raised from 256 to 1,000. With eight data-parallel attention workers, this allows 125 running requests per GPU instead of 32.SGLang setting SGLang baseline Throughput-oriented SGLang --tp 8 8 --dp 1 8 --enable-dp-attention false true --ep-size 1 8 --moe-runner-backend flashinfer mxfp4 auto --moe-a2a-backend none megamoe --mem-fraction-static 0.901 0.835 --max-running-requests 256 1000 --chunked-prefill-size 16384 65536 --schedule-conservativeness 1.0 0.3 --swa-full-tokens-ratio 0.1 0.075 --enable-prefill-delayer false true Both configurations use --tp 8 , but enabling data-parallel attention makes attention run independently on each GPU. ↩ user-content-fnref-serving-configurations ↩<sup 2</sup user-content-fnref-serving-configurations-2 3. All three deployments used the same prompts, agent loop and sampling settings. Temperature was set to 0.7 to introduce variation between trajectories, with top-p set to 1.0. Each model response was capped at 32,768 output tokens and each trajectory at 250 steps. ↩ user-content-fnref-agent-settings 4. The first two attention layers use HCA. The remaining layers alternate between CSA and HCA, giving 31 HCA layers and 30 CSA layers in total. The schedule, along with the model dimensions and precisions used here, is specified in the published model configuration https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/config.json . ↩ user-content-fnref-attention-layer-schedule 5. SGLang v0.5.14’s DeepSeek-V4 attention module https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/models/deepseek v4.py , compressor https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/layers/attention/dsv4/compressor.py and indexer https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/layers/attention/dsv4/indexer.py implement the fused query-latent/KV projection, both compressors and the complete indexer as replicated linear layers, while the query-head expansion and output projections use column- or row-parallel layers. The files used by the run are unchanged from the v0.5.14 tag. ↩ user-content-fnref-sglang-attention 6. The ratios and factors are measured over the serving windows of Figure 2. The effective costs and include a consistent allocation of all capacity time at the observed operating point, including coordination, scheduling and idle time, across preparation and generation; no overhead is assumed to vanish or counted twice. ↩ user-content-fnref-throughput-model ↩<sup 2</sup user-content-fnref-throughput-model-2 7. Each potential-reuse rate is computed from the calls recorded during its own deployment’s run. For each call, we measure how many of its input tokens are covered by the cached prefix an earlier call of the same trajectory leaves behind, capped at the current input length. SGLang’s allocator commits and matches cached prefixes in whole 256-token pages, and we count coverage in these units for both runs, so a partial page at the boundary does not count. The shared opening prompt counts as part of that history, and calls without an age- predecessor contribute zero. The Doubleword estimate uses each call’s immediate predecessor; the SGLang estimate sums every available copy age, weighted by . ↩ user-content-fnref-prefill-opportunity 8. SGLang v0.5.14’s data-parallel controller https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/managers/data parallel controller.py maintains a single counter and sends each request to the next active worker in turn; the deployment did not pin trajectories to workers, so an agent’s successive calls land wherever the counter has advanced. ↩ user-content-fnref-prefill-routing 9. History evicted from a GPU survives in host memory and is copied back when its trajectory returns, counting as cached input, so restored history is reused exactly like device-resident history. That requires every evicted history to finish its copy before the GPU drops it, and a returning request to find GPU space to reload it; we assume both. Restoring a typical 31,000-token history moves about 180 MB of KV state, 5.6 KB of compressed state per token plus a 4.6 MB sliding-window tail, and crosses a PCIe 5.0 ×16 link, roughly 63 GB/s each way, in about 3 ms. Prefilling it again runs the full model over those tokens, since the KV state at each layer depends on the output of every earlier layer’s attention and MoE blocks. The attention layers’ weight projections alone, the matmuls in Figures 5 and 6, come to about 39 GFLOP per token, roughly 0.3 GPU-seconds at the B300’s peak rate for each projection’s precision. We therefore charge nothing for restoration and treat host memory as retention capacity. ↩ user-content-fnref-host-tier-model 10. Both columns are modelled available capacity rather than raw pool sizes. For throughput-oriented SGLang, we estimate the slots free or holding evictable history from the configured pool sizes and the run’s median cache occupancy across workers. For the Doubleword deployment, each worker’s host pool also holds copies of whatever its GPU pool holds, so we subtract the GPU pool’s size, the most those copies can occupy, and count the rest as retention capacity. Both serve as inputs to the residence estimate, not exact measurements of any prefix’s eviction budget. ↩ user-content-fnref-prefill-capacity 11. The full-window generation accounting gives 240.62 output tokens per local decode forward for the Doubleword node over its saturated-serving window and 45.695 for the SGLang node over its 24-hour window; each running request advances one token per forward, so these are the mean requests advanced per step. The same windows’ engine measurements record mean queue lengths of 482.977 requests across the SGLang node, half of its 960 trajectories in flight, and 243.6 across the Doubleword node, a tenth of its 2,560. SGLang worker queues held at least 20 requests in 80.7% of sampled decode-report intervals. Figure 8 plots sampled running populations means of 1,958.463 and 465.923 requests , which count requests in the batch at each instant including time spent between decode steps, and so differ from the forward-weighted widths above. ↩ user-content-fnref-decode-backlog 12. SGLang v0.5.14, scheduler.py, lines 2655–2666 https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/managers/scheduler.py L2655-L2666 . Mixed-chunk scheduling was disabled in both deployments, so a forward pass is either a prefill batch or a decode batch. ↩ user-content-fnref-decode-prefill-first 13. SGLang’s workers log one decode pass in forty, with queue length, cache usage and running count at that moment. Of the 19,299 decode passes logged in the throughput-oriented SGLang run’s 24-hour window, 2,374 show an empty queue and 3,101 show queued requests with SWA or full-KV usage at 0.9 or above, the two states in which a decode pass is expected. The remaining 13,824 show queued requests with usage below 0.9 in both pools, and 9,783 of those show at least 20 queued with SWA usage below 0.5 and full-KV usage below 0.4. Usage gauges count protected state only, so low usage means admission budget was available, and no logged decode pass shows a worker at its 125-request limit. ↩ user-content-fnref-decode-cadence 14. SGLang v0.5.14, prefill delayer.py, lines 272–299 https://github.com/sgl-project/sglang/blob/v0.5.14/python/sglang/srt/managers/prefill delayer.py L272-L299 . ↩ user-content-fnref-decode-coordination 15. Each worker’s running and waiting counts were polled every 10 seconds, giving 7,834 complete samples over throughput-oriented SGLang’s serving window and 5,149 over Doubleword’s. A sample meets the condition when at least one worker’s queue is empty while another holds at least 20 waiting requests, a threshold that separates a genuine backlog from a nearly idle node; 3,683 SGLang samples and 113 Doubleword samples did. The polls are not aligned to individual forward passes, so they show the state the delayer reacts to rather than its decisions. The scheduler’s own counters over the same SGLang window record 106,184 passes with split readiness, of which 103,233 denied fresh admission and 83,931 of those ran no prefill at all, not even a chunk of an earlier admission, against 646 denials in 75,206 passes with every worker ready. ↩ user-content-fnref-decode-queues 16. Costs use the AWS Capacity Blocks for ML https://aws.amazon.com/ec2/capacityblocks/pricing/ rate of $112.32 per hour for a p6-b300.48xlarge in US East N. Virginia . Each SGLang run’s first 24 hours cost $2,695.68; the Doubleword run finished the schedule in 20 hours, 23 minutes and 17 seconds, costing $2,289.99 including its final period with fewer remaining trajectories. Dividing each cost by its completed attempts gives the per-attempt figures. The figures are run-level averages over different completed problem mixes, and the comparison does not establish that 64 attempts cost less than one on each individual matched problem. ↩ user-content-fnref-benchmark-cost 17. One attempt at each of the 731 problems, on the recorded workload, sends about 36.7 million new input tokens, 1.65 billion input tokens repeated from earlier calls in the same trajectory and 12.5 million output tokens. Each estimate charges the repeated tokens at the provider’s cached-input rate and the new tokens as cache writes, at 1.25× the input rate on the GPT-5.6 family and Claude and at the input rate on Gemini, whose implicit caching carries no storage charge, using the prices OpenAI, Anthropic and Google published in July 2026, when this work was done. Per million tokens, cached input, input and output: GPT-5.6 Luna $0.10, $1 and $6, giving $286; Gemini 3.1 Pro Preview $0.20, $2 and $12, giving $554; GPT-5.6 Terra $0.25, $2.50 and $15, giving $716; Claude Opus 4.8 $0.50, $5 and $25, giving $1,368; GPT-5.6 Sol $0.50, $5 and $30, giving $1,431. ↩ user-content-fnref-provider-cost 18. An attempt succeeds if its submitted patch passes every evaluation test, and 23,971 of the 46,784 attempts did. For a problem with passing attempts out of 64, pass@k is , with the numerator taken as zero when , averaged over the 731 problems; pass@64 reproduces the observed 517 of 731. The Doubleword run cost $2,289.99 for 64 attempts at every problem, so one attempt at every problem is allocated $35.78 and attempts times that. Dividing each API estimate by $35.78 and rounding down gives the attempts its budget affords, 7, 15, 20, 38 and 39 for the five models in order of budget. ↩ user-content-fnref-passk-method 19. The 0.3-point gap against Opus 4.8 indicates comparable performance under this normalisation rather than a statistically established advantage. ↩ user-content-fnref-budget-comparison @misc{doubleword-swe-bench-pro-64-deepseek-agents, title = {How much of SWE-bench Pro can 64 DeepSeek agents solve in a day?}, author = {Rushil Bhat}, year = {2026}, howpublished = {Doubleword Blog}, url = {https://blog.doubleword.ai/swe-bench-pro-64-deepseek-agents}, }