JevBench · vLLM-SR d3 joins the regular draw

Refusals, errors and context-bound failures stay in the full 1,500 denominator. Every row kept its own package, model, runtime and context settings; nothing was re-run for presentation.

NOT DIRECTLY COMPARABLE WITH THE LIVE v1.6.1 BOARD OR WITH THE EARLIER FRESH DRAWS. This release is a different draw with its own small-field median: G_med = 9.839526770355711, frozen from the four v1.6.10 members (attest-31B-v1.0 does not move it), against 2.573387642438244 on the live field. G_med_flag_gt10 is false. The gap penalty is max(0, 1 - max(0, (gap - G_med) - 8)/100), so this field's threshold is G_med + 8 = 17.84. On the merged live board this draw is placed with offset 0 while its anchor runs are pending, exactly like the earlier fresh draws. Measured, not estimated: Applying the same penalty formula to the stored base and gap at the live field's median 2.573387642438244, attest-31B-v1.0 Intelligence 65.238 would be 65.238 (gap -0.628); the original four rows are as stated in the v1.6.10 notes: standard_one_3b_sh Intelligence 32.786 would be 31.294 and metask_jev_rain_12b_trained 67.826 would be 67.587; krino-2b and metask_jev_rain_31b_trained are unchanged.

Cost: no item is excluded from the cost basis on this draw. Every row is priced from its own measured usage block at a clearly-labelled ESTIMATE rate fixed before scoring (r99, r101, r103 and r106 pre-registrations); none is a bill any of these systems issued. Every row is under the published v1.6 cost ceiling of USD 0.0646 per 1,000 decisions. The cost normalizer C0 is USD 0.001 per 1,000 decisions with 30 cost points per decade.

No subject-topic radar in this release: this draw's items have not been topic-labelled yet, and the shared topic labels of earlier draws do not cover its items. Families, use cases and languages are authoring metadata and are shown.

v1.6.13 ADDS ONE ROW, attest-31B-v1.0, to the six of v1.6.12 on the same draw, under the same rule as the earlier same-draw additions: the field median stays the frozen v1.6.10 value, so all six earlier rows keep identical point scores, axes and capability; ranks and bootstrap confidence intervals are recomputed for the seven-row roster, and the existing raw_on_A and API-basis offset diagnostics are unchanged because the new row is full-set API, not a new self-hosted equating-pool member. No API offset enters its score.

krino-2b: All 1,500 items answered HTTP 200 with native probabilities. The 15 longest items of the draw (the same 15 that standard_one_3b_sh refuses) ran with the state truncated to 65,536 tokens, as the author's submitted serve command documents (KEV_TRUNCATE_STATES=1); every other item is at most 1,802 input tokens. Reference kernels were used (KEV_FUSED=0) because the documented pip install has no flash-linear-attention. Kev reports usage.output_tokens as the token count of the serialized answer JSON although nothing is generated (165,276 over 1,500 decisions); it is priced as reported at the frozen DeepInfra Qwen/Qwen3.5-2B reference, USD 0.02/0.10 per 1M. Measured on an evaluator-owned Lium H100 pod in an offline container (network none).

metask_jev_rain_12b_trained: All 1,500 items answered HTTP 200. The author's service runs the authors' own int4 (W4A16) quantization of Google's Gemma 4 12B QAT checkpoint with their own rank-16 LoRA applied unmerged by vLLM; per its model card it takes a second pass on part of the items, so it reports generated output tokens (84,238 over 1,500 decisions) and its latency has a long tail (raw p95 8.1 s against a raw p50 of 0.13 s). Measured on an evaluator-owned Lium H100 80GB pod (IP geolocated to Nizhny Novgorod, Russia) in an offline container (network none). google/gemma-4-12b-it is not listed on OpenRouter, so the cost uses the nearest listed sibling, google/gemma-3-12b-it at USD 0.05/0.15 per 1M, times its own usage. It is a different system from the earlier metask_jev_rain_12b row.

metask_jev_rain_31b_trained: All 1,500 items answered HTTP 200. The author's service runs Google's unchanged W4A16 Gemma 4 31B QAT checkpoint with the authors' own rank-16 LoRA applied unmerged by vLLM, at max_model_len 6,656 (per the measuring operator's handoff): longer inputs are shortened by the service's own documented extraction rule rather than refused, so the longest items were answered on a shortened state. The authors tested it on H200; it was measured on an evaluator-owned Lium H100 80GB pod (IP geolocated to Nizhny Novgorod, Russia) in an offline container (network none) with unchanged settings. The service reports 1 output token per decision; cost is the OpenRouter google/gemma-4-31b-it list price (USD 0.09/0.34 per 1M) times its own usage.

standard_one_3b_sh: 15 of 1,500 items returned HTTP 422: they are the 15 longest items of the draw and exceed the model's documented 32,768-token context, so the author's server refuses them rather than truncating; scored wrong per method. Measured on an evaluator-owned Lium H100 pod in an offline container (network none). Priced at the M2 base-model floor, OpenRouter mistralai/ministral-3b-2512 at USD 0.10/0.10 per 1M, because the author's own list price (USD 0.038 per 1M input) is below that floor; the schema head generates no text, so output tokens are 0.

torchcast-decision-4b-v1.1: evaluator-owned Lium GPU pod (H100), offline read-only container (--network none); author's torchcast_decision server unchanged at tag v1.1.0 with the bundled decision_config.json (bf16, one forward pass reading option letters, calibration temperature 0.9, yes/no commit floor 0.801) on the documented stack torch 2.9.1+cu128 / transformers 5.8.1 / flash-linear-attention 0.5.2 / causal-conv1d 1.7.0 (fast kernels active, CUDA graphs on) Paid fast-lane order 529be5d5 (public). Qwen3.5-4B fine-tune served by the author's own torchcast_decision package. Runtime: official pytorch/pytorch:2.9.1-cuda12.8-cudnn9-devel image (digest-pinned) plus an offline hash-locked overlay of the documented packages (Python 3.11 instead of the documented 3.12). decision_config.json sets a disclosed yes/no commit floor of 0.801: a yes/no probability with max(P, 1-P) below 0.801 is moved to 0.801 on its own side (answer unchanged; same mechanism as h2o-lightning-4b). Prompts over 16,384 tokens keep the head and the tail of the state (documented). Output tokens are 0 (no generation). CC BY-NC 4.0 (weights); base Qwen/Qwen3.5-4B Apache-2.0; serving package Apache-2.0. ESTIMATE, v1.5-M2 base-model reference rule: self-hosted open weights, no bookable tariff. Base model Qwen/Qwen3.5-4B (model card base_model). OpenRouter does not list Qwen3.5-4B (host snapshot source/public-docs/OPENROUTER-MODELS.json, fetched 2026-10-12T08:15:26Z, read 2026-10-12). Binding precedent INTERPRETATION-1 I-2/I-3: DeepInfra Qwen/Qwen3.5-4B, USD 0.03/M input, USD 0.15/M output, frozen 25 Sep 2026 price cut-off snapshot (listing later deprecated; frozen reference kept). Logit readout, no generation: server reports 0 output tokens. Isolation is container-level (--network none); no separate host-level netcut probe was taken. The input tar was on the rented pod host disk during the run, and the pod was destroyed after measurement (CUSTODY-RECEIPT.json).

uniphore-4b-decider: 15 of 1,500 inputs exceed the author's documented 16,384-token wrapper limit; the author's code refuses them (HTTP 422, no truncation) and they are scored as wrong per method, so 1,485 items were answered. The native readout is one forward pass, so output tokens are 0 and the cost is the input tokens at the frozen DeepInfra Qwen/Qwen3.5-4B reference, USD 0.03/0.15 per 1M (that listing is flagged deprecated in the frozen snapshot but remains the reference). Measured on an evaluator-owned Lium H100 pod in an offline container (network none), in the vllm/vllm-openai v0.31.0 image with transformers 5.17 and reference PyTorch kernels in place of the documented flash-linear-attention / causal-conv1d kernels, so its latency was measured on the fallback path. The author discloses that the public JevBench set was inspected repeatedly during development.

attest-31b-v1.0: Paid public fast-lane order 07d13315. Vendor-hosted attest.engineering /v1/systemone API; latency measured from Sandy (Germany), using the official per-item latency subset without API adjustment. Full S1200+P300 draw, not API A300 supplement; no API equating. 15 of 1,500 requests returned HTTP 500 after 8 retry invocations and are scored as wrong in the full denominator. Public model documentation declares frozen google/gemma-4-31B-it @842da3794eaa0b77d5f08bae87a17459d91ff475, unmodified bf16, no adapter or quantization; single forward pass reading option-label logits, no generated tokens, one fitted temperature (value not documented). Hosting implementation and deployed weights were not independently inspected. Hosted API access is not an open-weights release by the vendor; base weights are under the Gemma 4 licence. ESTIMATE, v1.5-M2 base-model reference rule: vendor-hosted API, customer list price USD 0.048/M input and USD 0.00/M output effective 2026-10-11 has been in force fewer than 30 days. Base model google/gemma-4-31b-it reference on OpenRouter USD 0.09/M input / USD 0.34/M output, snapshot fetched 2026-10-12T17:55:05Z (SHA-256 81eae2f3f94bf299c8d4499260f842c357b7a869ce82dfa1741ad6a89cf57014), same base-model estimate precedent as metask_jev_rain_31b_trained. Applied to measured response usage; failed HTTP 500 usage/billing may be unreported. No output generation; reported output tokens 0. Estimated, not a vendor bill.

Microsoft A2 re-run: 300 sealed supplementary A2 + 300 public items, not the full S1200 set. Unranked measurement; the official Microsoft row is retained on the merged boards. Equating pool four of six: Krino, Standard One, Uniphore, MeTask 12B. MeTask 31B and Torchcast were not completed after four unsuccessful allocation attempts (price/creation/controller failures); no inferred scores for missing pool systems. Seven HTTP 422 responses are wrong in the 600-item denominator. Pool re-runs used H200 in Helsinki, versus H100 parents; wide equating confidence intervals are reported. Latency from Sandy (Germany). Cost is the Azure Foundry tariff USD 0.042/M input, USD 0/M output; invoice/warmup/refusal charges unknown. No category cells or ranks are assigned to the A2 measurement.

v1.6.15 ADDS THREE SELF-HOSTED CPU ROWS to the seven official rows of v1.6.14 on the same draw, under the same rule as the earlier same-draw additions: the field median stays the frozen v1.6.10 value, so all seven earlier rows keep identical point scores, axes, capability and cost objects. Ranks and bootstrap confidence intervals are recomputed over the new roster - the scorer draws ONE paired resample for the whole field, so adding rows moves a carried row's confidence interval while no point estimate changes; six of the eight carried rows' intervals moved (attest-31b-v1.0 and the carried A2 measurement did not). One DIAGNOSTIC also moved, and it is named here rather than left to be found: the API-basis median diagnostic is computed over the ranked field, so it moved from 9.628699345543296 to 9.158662835848954 when three rows joined, and that moves the stored A-basis diagnostic (the row field v16.raw_on_A) of exactly one carried row, standard_one_3b_sh: intelligence 29.3339 -> 29.1921, capability 53.1539 -> 53.0830. That diagnostic is not part of any score, rank or axis on this release, and no carried row's composite, axis, capability or cost object changes. The unranked A2 measurement of v1.6.14 is carried through byte for byte and is not rescored. reflex-instinct-0.6b is LISTED BUT NOT RANKED: CoS deputy decision #18761 accepts its Intelligence, Calibration and Cost only and declares its Speed figure non-official, and the composite weights Speed. All three new rows were measured at USD 0 on the evaluator's own shared CPU host, so their Speed figures are loaded-host lower bounds; each row logs its own one-minute load trace and carries it in its note.

Where to look for the row that is shown but not ranked, and what it does NOT mean. reflex-instinct-0.6b is deliberately absent from the ranking charts, the Composite and Capability boards, the compare view and the category radars, because those are ranked views and this row has no rank. It is named in this release's own notes and header, and it appears in the collapsed "All data" table further up the page, after the Noul table. DISCLOSED: in that table the row still shows its composite as the scorer computed it, and a Jev-class verdict the site derives from its cost per decision and its MEDIAN LATENCY against the frozen Jev-class caps. The composite weights the Speed axis, and that latency is the very measurement CoS deputy decision #18761 declares non-official for this row, so neither figure is an official placement. They are not an official placement and must not be quoted as one. Its accepted figures are Intelligence 3.960, Calibration 73.153, Capability 38.556 and Cost USD 0.00630127 per 1,000 decisions. A dedicated row group for listed-not-ranked rows, with Speed greyed out and the composite hidden, is the right presentation and is a site change this release does not make.

Cost on the three new rows: each is priced from its own measured usage block at a clearly labelled ESTIMATE rate fixed before scoring, on the full 1,500-row basis, and each is far under the published v1.6 ceiling of USD 0.0646 per 1,000 decisions - phocinae-largha-150m-v1 USD 0.00143980, reflex-instinct-0.6b USD 0.00630127, julia-1 USD 0.00217445. None is a bill any of these systems issued. julia-1's declared base jhu-clsp/mmBERT-small has no market listing; adding it to the frozen pricing module's reviewed unlisted-base set was authorised by #18761, re-frozen, hashed, proved behaviour-identical over every registry entry on the evaluator's machine and independently reviewed before this row was scored.

julia-1: 1,500 attempted, 1,483 answered. The 17 misses are the author's own strict_encoding policy refusing rather than truncating (15 items above their lossless context budget, 2 with an option above their 48-token option contract); the totals AND the per-type split were pre-registered before the run and came back exact. All answered items native; the Speed figures are the published method's percentiles over this draw's open standard and judge items. 652,334 input tokens and 0 output tokens by construction (one encoder forward pass read at marker positions, nothing generated). The author ships no server, so the HTTP surface is the evaluator's - but their own julia.typed.predict_typed already speaks JevBench's typed-question shape, so no mapping decision of the evaluator's enters this row. Their hierarchical Router, which their own card says is not a global probability distribution, is neither used nor reachable here: every choice item of this draw has 3 to 9 options, inside their native 2-20 contract, so each decision is one call with one global softmax, and the probabilities are their raw values rather than their presentation helper's. Measured on the evaluator's own shared CPU host at their own settings read back from the run itself (float32, 4 threads, torch backend); one-minute load 10.87-13.78 logged, so Speed is a loaded-shared-CPU lower bound with the standard self-hosted x2 + 0.15 s adjustment on top. Cost is a clearly labelled size-class ESTIMATE: the declared base jhu-clsp/mmBERT-small has no market listing, and the base-size-encoder line of USD 0.005 per 1M input / 0 output that modernbert-jev-v2, tacet-sonata and watt-flash-0.1 carry in the PUBLISHED v1.6 field is used unchanged - no row of this draw carries it - and it is not a bill.

phocinae-largha-150m-v1: 1,500 attempted, 1,125 answered. The 375 score items are recorded as HTTP 422 misses by the EVALUATOR'S shim, under a rule pre-committed in writing before the run (PREREG-R92 section 4.6), because the author's API answers only a fixed nine-level 2..10 scale that does not fit this item type; the shim refuses them in about 0.7 ms without calling the author's server at all, so no claim is made that the author's code refused anything. They stay in the full 1,500 denominator as misses - the figure 1,125 was pre-registered and came back exact. All answered items native. The Speed figures on this row are the published method's percentiles over this draw's open standard and judge items, not a median over every attempt - and DISCLOSED: 37 of those 124 items are the shim's instant score refusals, which cost no model time, so the figures are faster than the model itself is. Over the 87 items the model actually answered the Speed axis would read 75.75 instead of 77.12, which changes no rank. Measured on the evaluator's own shared CPU host (AMD Zen 2, float32), NOT a dedicated machine: other jobs ran beside it and the one-minute load average was logged for the whole window (3.75 to 9.89, mean 5.81, 12 samples - the quietest of this release's three new rows). Speed is therefore a loaded-shared-CPU figure and a lower bound for this model on a dedicated core or a GPU; the standard self-hosted x2 + 0.15 s adjustment is applied on top and the raw percentiles are kept. DISCLOSED: the author's server places every short-option request in its own 512-token budget tier, so the state is truncated far below the 8,192 its MAX_POS advertises - the author's design, not the evaluator's, and visible in their own usage histogram. A SECOND mapping decision of the evaluator's, footnoted on the row: the item's instruction text (and for noul its true/false criteria) is appended to the state, because state is the only text field the author's API has. Cost is a clearly labelled size-class ESTIMATE on the base-size-encoder line the PUBLISHED v1.6 field carries - modernbert-jev-v2 (measured in v1.6.8 on the earlier a2 draw) and the v1.6.1 rows tacet-sonata and watt-flash-0.1 - and no row of this draw carries it. It is not a bill.

reflex-instinct-0.6b: 1,500 attempted, 1,500 answered, zero failures of any class - the pre-registered figure, exact. All answered items native; the Speed figures are the published method's percentiles over this draw's open standard and judge items. NOT RANKED, and here is exactly why: CoS deputy decision #18761 accepts this row's Intelligence, Calibration and Cost only and declares its Speed figure (58.972) NON-OFFICIAL, because the one-minute load on the shared host ranged 9.42-33.12 (mean 15.28, 155 samples) during the window and the evaluator's own preparation activity overlapped it. The published composite weights Speed, so this row is shown with its axes and its Capability 38.556 - which is Intelligence and Calibration only and contains no Speed - but it carries no rank and no composite placement. Its Capability 38.556 is the highest of this release's three new rows, above phocinae-largha-150m-v1's 30.240 - said here because the Capability board does not show it: that board contains no Speed at all, so a reader could reasonably ask why this row is absent from it. The answer is that THIS RELEASE applies #18761 to the whole row rather than axis by axis - the deputy's decision excludes the Speed figure, and whether a row with a non-official Speed may still be ranked on Capability alone is the open question #18825, which has no answer yet. The conservative reading ships. DISCLOSED: the author's own encode() truncates state lines above its own max_len of 16,384 instead of refusing them, so this row answers the 15 items of 106,804-122,936 characters that four other rows of this draw recorded as context refusals (attest-31b-v1.0, julia-1, standard_one_3b_sh and uniphore-4b-decider); that is the author's design choice, not the evaluator's, and those items are the slowest in the row. Cost is a clearly labelled size-class ESTIMATE on the sub-1B line the PUBLISHED v1.6 field carries (liquid-d1-omni-600m, jiwo-0.8b, vegaml-0.8b) - no row of this draw carries it - and it is not a bill.

v1.6.16 ADDS ONE SELF-HOSTED GPU ROW, vllm-sr-d3 (vLLM-SR d3), to the ten full-draw rows of v1.6.15 on the same draw, under the same rule as the earlier same-draw additions: the field median stays the frozen v1.6.10 value, so every carried row keeps identical point scores, axes, capability, cost and speed objects. What moved on carried rows, counted exactly. RANKS: vllm-sr-d3 has the highest Capability of this draw, so all nine ranked carried rows move down one place in this release's Capability order (attest-31b-v1.0 3 -> 4, julia-1 9 -> 10, krino-2b 7 -> 8, metask_jev_rain_12b_trained 2 -> 3, metask_jev_rain_31b_trained 1 -> 2, phocinae-largha-150m-v1 8 -> 9, standard_one_3b_sh 6 -> 7, torchcast-decision-4b-v1.1 4 -> 5, uniphore-4b-decider 5 -> 6); its composite (A 5.570) sits between krino-2b and phocinae-largha-150m-v1, so phocinae-largha-150m-v1 (8 -> 9) and julia-1 (9 -> 10) also move down one place on composites A, B and C and in their headline rank; no other composite rank moves. CONFIDENCE INTERVALS: none of the ten carried rows' bootstrap confidence intervals moved. The scorer seeds each row's bootstrap with the shared seed 16 plus the row's position in the key-sorted roster, and vllm-sr-d3 sorts last, so no carried row's position changed (in v1.6.15 the three new keys sorted into the middle of the roster, which is why six carried intervals moved then). Correction to the v1.6.15 note above: it says the scorer draws ONE paired resample for the whole field; it does not - the scorer seeds each row's resample by its position (seed 16 + index in the key-sorted roster), each row with its own resample, which is why rows that changed position moved in v1.6.15 and none moved here. The same mechanism is why d3's interval here differs from its private single-row preview while its point values are identical: Capability 95% interval [78.928, 84.441] here, [79.337, 84.362] in the preview. DIAGNOSTICS: the API-basis median diagnostic is computed over the ranked field, so it moved from 9.158662835848954 to 9.40342052601045, which moves the stored A-basis diagnostic (the row field v16.raw_on_A) of exactly one carried row, standard_one_3b_sh: intelligence 29.1921 -> 29.2660, capability 53.0830 -> 53.1199; and the release-level equating-offset diagnostic moved from I 0.1329 / C 1.0866 to I 0.2288 / C 1.2340. Neither is part of any score, rank or axis on this release: the only API row scored in this invocation, attest-31b-v1.0, is a full-set row and is not equated, and the carried A2 measurement keeps its own A2 equating and is not rescored. reflex-instinct-0.6b stays LISTED BUT NOT RANKED under #18761 and the unranked A2 measurement of v1.6.14 is carried; neither is changed.

Cost on vllm-sr-d3, and the scope of the cost note above: that note's "every row is under the published v1.6 cost ceiling of USD 0.0646 per 1,000 decisions" is true of the ten rows of v1.6.15 and is NOT true of vllm-sr-d3. d3 is priced as an ESTIMATE at the frozen Qwen/Qwen3.8-27B list reference of the published v1.6 field (USD 0.42 per 1M input and USD 3.00 per 1M output, the same pair the published Perplexity Decider v1.1 27B and Torchcast-Decision-27B rows carry) times its own measured tokens on the full 1,500-row basis: 1,951,205 input tokens and 0 output tokens, USD 0.5463374 per 1,000 decisions, about 8.46x that ceiling. It is not a bill and not a quote from the author or any host. Consequences: its Cost axis is 17.876, below 50, so the squared cost gate of the composite applies and its composite A is only 5.570 (rank 8 of 10 here) despite the highest Capability of this draw; and on the merged live board it is far above the official Jev-class cost cap, so it is NOT on the default (cost-capped) Capability ranking.

Board effect, and why this release needed an explicit GO. On the merged live board, with the default caps, the top five of composites A, B and C and of the cost-capped Capability ranking are unchanged on the mixed board, on the open-weights board and on the API board (vllm-sr-d3 is outside the cost cap and its composite is far down). The views that change are Capability views with the cost cap switched off: with the latency cap at 2x and open-weights and API models mixed, vllm-sr-d3 becomes #1 on Capability, 82.966 against Perplexity Decider v1.1 27B at 82.792; on the open-weights board it is #1 with the cost cap off whether the latency cap is 2x or off; on the mixed board with both caps off it is #6 and that top five is unchanged. The #1 is not a resolved order: d3's 95% interval here is [78.93, 84.44] and Perplexity Decider's is [79.18, 84.71], they were measured on different draws (this draw sits on the merged board with offset 0 while its anchor runs are pending), and d3's Speed was timed on different hardware (see its note). A change to a public top five needs Florian's GO; he gave it on 13 Oct 2026 at 15:12Z (card 17392).

vllm-sr-d3: Model vllm-sr/d3 at revision 5ce995dfb7ff07da00fec4211eb7f0560f52eaf8 (vLLM Semantic Router team), a fine-tune of the base Qwen/Qwen3.8-27B; its model card states 26.09B parameters including a 0.46B vision encoder. Weights Apache-2.0. The training data is not disclosed by the author, so the weight licence alone says nothing about the provenance of the training data. 1,500 attempted, 1,500 answered (all HTTP 200), 0 errors, 0 missing; the author's server sets no input-length cap, so it also answered the draw's 15 longest items that several rows of this draw refuse. Determinism check: 50 items re-asked, 50/50 bit-identical probabilities, 0 argmax flips. HARDWARE DIFFERS FROM THIS DRAW'S OTHER GPU ROWS AND FROM PERPLEXITY DECIDER AND TORCHCAST-27B: measured offline on one rented NVIDIA RTX PRO 6000 Blackwell Server Edition 96 GB GPU (Verda), while this draw's other GPU rows, Perplexity Decider and Torchcast-Decision-27B were timed on a single H100 80 GB, because no single H100 was available; the Speed axis (87.369; p50 0.1087 s raw, 0.3675 s adjusted, over the scorer's 124 open standard and judge items) therefore rests on different hardware, and the larger 96 GB memory may also matter for the longest inputs. The plain CUDA/PyTorch path of the author's unmodified d3_server.py was measured; the author's AMD ROCm fast path does not apply on CUDA. The own-server adjustment x2 + 0.15 s is an assumption, not a measurement. Cost is an ESTIMATE, not a bill: the frozen Qwen3.8-27B list reference (the same basis as Perplexity Decider and Torchcast-Decision-27B) times d3's own measured tokens, USD 0.5463374 per 1,000 decisions, far above the official Jev-class cost cap, so d3 is NOT on the default (capped) Capability ranking and its composite is small because of the squared cost gate. Source review of the pinned code before the run: PASS (no network on the text path, no benchmark-specific branches, no secret reads).