Klein-Code-Bench

Can a model build a working program from scratch? Klein-Code-Bench gives a coding model a specification and an empty directory, and checks whether the finished Python project passes every acceptance test.

• 260 tasks in four tiers of 65
• Pass or fail per project: a task counts only if all of its tests pass
• Runs locally: standard-library Python, no Docker, no cloud model, no extra dependencies

Tier	Intended model size	What the model builds	Tasks
easy	2–8B	A JSONL command-line tool with a domain algorithm and error recovery	65
intermediate	8–16B	A stateful document service: CRUD, listing, domain evaluation	65
hard	16–32B	A service with atomic batches, revision checks and nested transactions	65
max	60–200B	A durable service that survives being force-killed, with idempotency, history and pagination	65

The model sizes are design targets. Version 0.1.0 has not been calibrated against real models yet, and there is no leaderboard. Any model can be run on any tier.

How a task works

1. The model gets PROMPT.md: the full specification plus two examples.
2. It writes main.py and any other files into an empty project/ directory. There's no starter code and no existing repository to fix.
3. The evaluator runs the project as a subprocess, sends JSONL requests and checks every response and state change. In the max tier, the process is force-killed right after its last acknowledged response, restarted on the same state directory, and must continue correctly.

The 65 tasks per tier come from the same 65 domain families: text processing, CSV/JSON tools, calendars, numerical utilities, graphs, scheduling, ledgers, geometry, parsing, simulation and more. Each tier adds service behavior on top of the one below. Full list: task catalog.

Because the tiers share families, results across tiers are correlated. Report each tier separately, and don't train on one tier and then present another as an uncontaminated evaluation.

Quick start

Requires Python 3.11+ on Linux or macOS.

git clone https://huggingface.co/datasets/klein-ml/klein-code-bench
cd klein-code-bench
python -m pip install -e .
klein-bench list --subset easy

# Create a workspace: PROMPT.md, plus an empty project/ directory for the model
klein-bench prepare kcb-easy-001-word-frequency --output workspaces/first

# Give workspaces/first/PROMPT.md to your model and let it write into workspaces/first/project/, then:
klein-bench evaluate kcb-easy-001-word-frequency \
  --solution workspaces/first/project --output results/first.json
klein-bench score results/first.json

• python -m klein_code_bench works the same as klein-bench.
• Exit code 1 means a failed submission, 2 an invalid invocation.
• --public-only runs just the two examples as a smoke test. Those results can't be scored.

Bring your own agent or local API endpoint, or use the banana-harness integration. Record the model's inference settings with your results.

Loading the dataset

from datasets import load_dataset

easy = load_dataset("klein-ml/klein-code-bench", "easy", split="test")      # 65 tasks
all_tasks = load_dataset("klein-ml/klein-code-bench", split="test")          # 260 tasks

Each tier is its own config with a single test split; the default config contains all four. There is no training split, and no loading script or trust_remote_code is needed. Pin revision to a commit when you report results.

Field	Content
task_id	Stable unique ID
subset, family, category, title	Tier and task description
target_model_parameters	Intended model-size band (not calibrated)
language, entrypoint, protocol_version	Python, main.py, protocol version
prompt	The full specification the model sees
public_tests	Example requests and responses (JSON string)
acceptance_tests	Evaluator scenarios: sessions, requests, expected responses (JSON string)
num_scenarios, num_assertions, timeout_seconds	Test counts and the per-session time limit

The test fields are stored as JSON strings so that all tasks share one schema; decode them with json.loads.

Never put acceptance_tests, the reference implementations or the evaluator source into the model's prompt, context or workspace. They're public for reproducibility, so the benchmark depends on you keeping them away from the model.

Scoring

The metric is resolve@1: one project per task, and it counts only if every test passes.

• Per tier: resolved tasks / 65. Overall: resolved tasks / 260.
• Missing submissions count as failures. The report also shows the rate among submitted tasks and flags incomplete runs.
• Partial assertion success is reported for diagnosis, but it never counts as resolved.

Each scenario starts from a fresh copy of the submission and an empty state directory; sessions within a max-tier scenario share that directory. JSON comparison keeps array order and tells booleans apart from numbers. Floats use an absolute and relative tolerance of 1e-9; integers are compared exactly. Default limits are 10 seconds per session and 1 MiB of stdout. Details: evaluation protocol.

Tier	Assertions
easy	3,075
intermediate	5,415
hard	9,705
max	15,490
total	33,685

The tests cover:

• 65 hand-written golden outputs
• 24 generated inputs per family (seed 1729, shared across tiers)
• boundary cases and malformed requests
• failure atomicity, nested rollback and revision conflicts
• retry and restart sequences

All expected outputs are computed before grading, never inside the candidate's process.

Verifying the benchmark itself

python -m unittest discover -s tests -v                    # unit and property tests for the benchmark and runner
klein-bench build                                          # regenerate data and manifest from source
klein-bench validate --output results/validation.json      # every reference must pass, every empty project must fail

The reference implementations exist to maintain the evaluator. Export one for auditing with klein-bench reference TASK_ID --output DIR. The published validation-summary.json documents the dataset manifest and validation totals; it is not a model score.

Security

The runner is not a sandbox. It does the following:

• removes inherited credentials from the environment
• runs each submission from a temporary copy
• rejects symlinks
• limits time and output
• kills the whole process group when it's done

Generated code can still reach your filesystem and network. Run it under a separate unprivileged user, on a machine you can afford to lose. Timing depends on the host, so record your hardware with your results.

Provenance and limitations

• Origin: every task was written for this benchmark. None were copied from SWE-bench, LiveCodeBench or other benchmarks. That covers how the tasks were authored; it doesn't guarantee that standard algorithms in the easy tier never appear in a model's training data.
• Scope: Python only. The tests measure behavioral correctness, not code quality, architecture or UI. They don't cover concurrent writers, disk corruption or power loss during a write.
• Coverage: the reference implementations and independent golden checks make the dataset internally consistent, but the tests can't prove that no specification or expected output contains an error.
• License: MIT for prompts, test data and reference implementations.

Contributing

A new task needs:

• a contract (the specification)
• meaningful boundary tests
• an independent check of the expected outputs
• a reference implementation that passes

Changes to a contract or expected behavior require a new dataset version. Task IDs stay the same only for backward-compatible fixes.