CodeSOTAβOriginal site ↗

Ontology / current system

From interest
to measured evidence.

People help choose what matters. Runtime agents find and prepare benchmarks. White runs the evaluations. Every published score points back to evidence.

15 tasks in the live registry68 completed measurements2 GPU worker slotsInspect live registry →

The evaluation loop

Select a step to explore it. On smaller screens, swipe the diagram or use the step buttons below.

The current CodeSOTA evaluation loopVisitor interest informs Runtime Scout and task priority. Scout creates a sourced backlog. Operator validates candidates and schedules jobs. The queue dispatches to White, which uploads evidence. Compatible results and scatter plots are published, bringing more visitor interest. Each node opens a detailed explanation below.DISCOVER WHAT TO MEASUREPREPARE & SCHEDULEEXECUTE & PUBLISH01 People exploreServer traffic + qualified task interestThe public usage leaderboard shows interest.Explore this step ↗02 Runtime ScoutSearch primary benchmark sourcesEvery 6 hours · up to 3 proposals per cycleExplore this step ↗03 Sourced backlogproposed → ready → queued → measuredUnsupported protocols → needs_adapterExplore this step ↗04 Demand → priorityRecent interest + coverage + freshnessEvery fifth dispatch serves the oldest job.Explore this step ↗05 Runtime OperatorPin revisions · validate scoring recipeEvery 30 minutes · at most 2 candidatesExplore this step ↗06 Evaluation queueUp to 4 new autonomous jobs / UTC dayDeduplicated model + benchmark scopeExplore this step ↗09 Public comparisonsCompatible results + size / score plotsPeople inspect evidence → new interestExplore this step ↗08 Validated evidenceScore + predictions + pinned revisionsEvaluator hash + environment + manifestExplore this step ↗07 White executes2 × RTX 3090 · one worker per GPUPinned evaluator · first 32 valid examplesExplore this step ↗

Selected step

01 People explore

Server-side analytics counts public HTML responses and estimates daily unique visitors using a rotating-key HMAC of IP + User-Agent. Counts are public aggregates; no raw IPs or User-Agent strings are stored in the analytics tables. Daily uniques are estimates, and their sum across days is visitor-days. Separately, beta task visits qualify after 2.5 seconds on a visible page, with deduplication, bot filtering and privacy controls. Original CodeSOTA’s top-100 page counters refresh hourly. These are planning signals, not unique-person analytics. Visits to documentation and run pages appear in the popularity table; task-page visits drive task demand.

Public usage leaderboard →

What a score means

A score belongs to a model and one exact benchmark scope. The task is the starting point; the run is the evidence behind the result.

Capability areaTaskBenchmarkRunResult
EntityMeaning / relationshipExample in this beta
Capability areaGroups tasks for discovery.Code & Software Engineering
TaskDefines inputs → outputs; has benchmarks.Function signature + description → code completion
DatasetVersioned evaluation examples and reference answers; used by a benchmark.Pinned HumanEval data, test split
BenchmarkTask + dataset revision / split / selection + metric + protocol + evaluator version.CodeSOTA HumanEval 32-example pilot · fraction passing all tests
ModelThe exact system evaluated, pinned by model revision.Qwen2.5-0.5B at a specific model commit
RunOne execution attempt linking a model to a benchmark; records configuration and evidence.White GPU job with timestamps, outputs and evaluator hash
ResultCompleted model + benchmark + score + configuration + source + date.Measured passing fraction on the pinned pilot scope
SourceSupports a definition or result: upstream benchmark origin and our execution artifacts.Primary dataset repository; samples, environment and SHA-256 manifest
Leaderboard / chartCompares results within the same compatible scope.Task result table and model size vs score scatter plot

V1 direction / distinct from the current pilot registry

Choose a model. Follow the evidence.

The target V1 closes the path from a practical question to comparable results and their sources, within a limited set of task families. It keeps useful guides from the original site.

Three page templates

Task: inputs → outputs, benchmarks and relevant guides.
Benchmark: what it measures, protocol-specific results and sources.
Guide / comparison: practical choices, limitations, examples and links to evidence.

Two independent result labels

Origin: measured by CodeSOTA / reported by a source.
Scope: full benchmark / subset / unknown.
A reported result does not require a CodeSOTA run. Compatible protocols can share a ranking; other results belong in separate context groups.

V1 elementMinimum relationship
TaskStable ID, name, description, input and output types. Categories are navigation groups.
BenchmarkStable ID, primary source and one or more related tasks. Discovering a benchmark does not define a new task.
ProtocolDataset revision / split / subset, metric, prompt and scoring rules; fixes comparison compatibility.
SystemA versioned model or pipeline, optionally with execution configuration.
ResultSystem + benchmark/protocol + score + date + source, origin and scope; optional run_id.
GuidePractical content linked to tasks and benchmarks. “OCR for Python” is a guide, not a separate task.

The current beta publishes our measured pilot runs and represents newly activated benchmarks as registry rows. The separate V1 content model, external-result ingestion and guide migration are not implemented yet.

Start the content migration with OCR / document AI, then embeddings, speech and coding. Preserve useful original URLs and guides while connecting them to the new result views. Existing original pages remain available until their sections are migrated.

Original OCR for Python guide ↗ · Handwriting guide ↗ · TTS guide ↗

Current boundaries

Measured pilots

Results use the first 32 valid examples. They are diagnostic subset scores, not official full-benchmark scores. Popularity changes work priority; it never changes scoring or makes a proposal into a result.

Explicit adapter work

Existing evaluators run the baseline task families. New multiple-choice recipes can be prepared automatically. Other discovered protocols require an implemented adapter and remain in the backlog.

SOTA picks

The beta does not publish a global SOTA pick. The best pilot result is only best among measured models within that exact comparison scope.

Versioning and lineage

Dataset/model commits, protocol settings and evaluator hashes identify versions and comparison scopes. An explicit graph connecting benchmark predecessors and successors is not implemented yet.

Live factory → · Queue → · Scoring and privacy →