llmcoderlab

How the tests work

From make run to a number on the leaderboard, with no human judgment anywhere in between. Four diagrams, rendered to static SVG at publish time — this page, like the rest of the site, ships zero JavaScript.

01 the assembly line

mechanical grading

the engine · lab/ · zero dependencies

what goes in

models.toml
roster · temp 0 · budgets

challenge JSON
spec + pytest suite
+ proven reference

runner
model × challenge × mode × sample

one-shot
one blind reply

agent loop
≤24 turns · 5 tools

isolated workspace
+ JSONL flight recorder

pytest
60%

deliverables
20%

content checks
20%

SQLite
stamped: git SHA
config · set hash

static console
zero JS · self-hosted

one attempt = one isolated workspace; every result commits to SQLite as it lands, so runs resume after a crash
Run modes
2
one-shot vs agent loop
Turn budget
24
per agentic attempt
Score blend
60·20·20
tests · files · content
Temperature
0
deterministic replies
Dependencies
0
stdlib-only engine
Human scoring
0%
pytest decides

Green boxes are inputs and outputs, blue is the engine, amber is grading, purple is storage. The challenge set is content-hashed and every run is stamped with it — edit one spec or test and the universe forks: old scores are never compared against new challenges. The full engine source is published on the harness page.

02 inside one agentic turn

no

yes

read · write · list

run_tests

done

yes

no

yes

no

turn begins

model replies
tokens logged

valid JSON
action?

corrective nudge
bad_action logged

turns
left?

which
action?

apply to
workspace

REAL pytest run

failures fed
back verbatim

suite
green?

accepted —
attempt ends

rejected +
failure output

budget exhausted

the done gate is why a model cannot talk its way to a score — only green tests end an attempt early

Two red paths tell real stories. The corrective nudge loop is where small models die of JSON escaping — one model emitted the identical malformed action 24 turns straight (the escaping cliff). And budget exhausted catches the models that solve the task on turn 1 and never realize it (knowing when to stop).

03 the fate of every reply

yes — after ×3 retries

no

no

yes

model reply

empty or truncated
at token limit?

DEGENERATE

protocol
parseable?

attempt completes

EXTERNAL grade —
the loop never grades itself

0–100 blend on the board
axes always shown

excluded from averages ·
counted separately ·
never a fake zero

failures are data, not zeros — averaging them in would let delivery mechanics masquerade as coding ability

The grade is external: after the attempt ends — by gated done, by exhaustion, or by failure — the harness runs the pytest suite itself and computes the blend. Every attempt page shows the axes, the raw pytest output, and the full transcript, so a suspicious number is always one click from its receipts.

04 who tests the testers

unit tests +
reference proofs +
no-network guard

smoke —
mock model through
the whole pipeline

browser matrix
chromium · firefox · webkit
iPhone 13 · Pixel 7

sanity gate —
refuses implausible data

make publish

the harness itself sits under three test layers plus a publish gate — its first browser run caught a real mobile bug

Every challenge ships a reference solution that must pass its own suite in CI, so a model failure is always a model finding. A guard test forbids any page from referencing the network. The browser matrix drives the real site in five desktop and mobile profiles. And make publish refuses to ship a board whose numbers look implausible. Details in the methodology.