Benchmark run
Started May 10, 2026, 8:12 PM · Recorded May 10, 2026, 8:43 PM · Ended May 10, 2026, 8:43 PM
Test suite v2 — Resilience · 045d4510abd0…
Generated May 10, 2026, 8:43 PM · qwen/qwen3-235b-a22b-2507
qwen/qwen3.6-flash4599 — coding, cost, debugging, hallucination, reasoning, refactoring, security, speed, ui--limit or --fail-fast triggered early termination)results_truncated: true — some detailed outputs may be omitted, but aggregate metrics are complete.210/459 (45.75%)2173.62 out of 3137 (69.29%)$0.4320.665s3.595s1.951s203.97 tok/s (average)52/60 passed (86.67%), 92.22% score — fastest and most accurate.29/30 passed (96.67%), 90% score — excellent on cost-aware tasks.49/60 passed (81.67%), 90.04% score — strong on algorithmic tasks, especially at easy level (100% score).5/9 passed (55.56%), but 62.45% score — limited data, but moderate success.6/60 passed (10%), 58.96% score — weakest category; struggles across all difficulty levels.11/60 passed (18.33%), 70.43% score — poor pass rate despite moderate scoring; fails complex constraint reasoning.10/60 passed (16.67%), 52.34% score — low pass rate, especially on easy (2/20) and hard (2/20) tasks.19/60 passed (31.67%), 68.95% score — inconsistent; fails many subtle bugs, especially in concurrency and state management.29/60 (48.33%), 72.78% score.fetch-timeout, weakref-gc) but fails basic ones (e.g., array-flat, json-parse-date).tc39-pipeline, validation-pipe).$0.43) for 459 tests, with 318,64 prompt and 285,906 completion tokens — indicates efficient token usage.0.66s avg), but long tail in latency (median 1.95s, mean 3.59s) — some complex tasks take significantly longer.coding, cost, speed.refactoring (1/20), security (2/20), and debugging (5/20).reasoning had only 11 passes — often generates plausible but incorrect logic under constraints.debugging tests failed with "Spread syntax requires ...iterable[Symbol.iterator] to be a function" — suggests model-generated code with runtime errors.The qwen/qwen3.6-flash model delivers strong performance in coding, cost optimization, and speed, with fast response times and low cost. However, it struggles significantly with refactoring, security, and complex reasoning, and shows inconsistent behavior in debugging and hallucination avoidance. It is suitable for lightweight, performance-sensitive tasks but may require validation for correctness in complex or safety-critical domains.
Per-model aggregates from overall_ranking.json for this run id.
Values are read from report.json when the benchmark wrote them.
Test suite
v2 — Resilience
Discovery
Full suite discovery (no --limit)
blxbench argv
tui
App version
v1.3.2
Resumed run
No
Score % vs mean latency where samples exist. Built from per-test rows in report.json when available.
Avg score % (bars) and strict success rate % (line) per cost cluster.
Per-test latency (seconds), successful timings only.
Normalized TTFT (inverted) vs decode tok/s per category for this run.
Average score % per metric dimension across all v2 tasks in this run.
Tests per scope (blue bars), estimated spend per scope (green bars), and mean $ ÷ merged rows per category (cyan line).
Per-test rows from report.json → results — by category (collapsed by default), then by difficulty. COMPL from details when present. The Visual column is omitted when no test in this run has a details.visual score. Judge: verdict and overall (0–100) from judge_validation / validation_model for coding/UI (hover for summary and subscores). No HTML or screenshots in this table. Cost: per-task USD from cost_usd or usage.cost when recorded. Suite: same manifest version/hash for every row (this run).
459 tasks in 9 categories · Grouped by category, then by difficulty; row order within each table matchesreport.json results (benchmark execution order)