endless-learning

Generate your own RL training tasks — and verify they are worth training on.

endless-learning builds a concept graph by exploring the web, mines verifiable tasks from it, and gates every task through execution: a task ships only if something can actually check the answer. Two kinds of task are live — deep-search questions grounded in a frozen document corpus, and executable coding instances mined from real repositories.

It is an open reproduction of the knowledge-graph task synthesis described in the Kimi K3 technical report (arXiv 2607.24653).

Scope: this is the data engine — graph, mining, verification, and versioned datasets that ship with their reward functions and environments. There is no training loop; trainers own the rollout loop.

What you can do with it

Install

pip install 'endless-learning[all]'

Python 3.11+. Extras, if you would rather pick: [anthropic] [openai] [litellm] [ddg] [mcp] [hub] [semantic] [verifiers].

Docker is required for the coding domain only. Everything else runs locally.

Quickstart

Nothing here downloads a prebuilt graph — the package is the engine, and every artifact is produced by your run, in your workspace.

mkdir my-graph && cd my-graph
endless init                                            # endless.toml + .endless/
endless kg expand --seeds knowledge --budget-nodes 0    # plant a seed pack, no keys needed
endless kg stats

Seeding is local. Growing the graph calls a model and a search backend, so set the credentials your endless.toml roles name, then raise the budget:

export ANTHROPIC_API_KEY=...          # or whichever provider endless.toml selects
endless kg expand --budget-nodes 50   # agents explore outward from the seeds

Deep-search questions

Sample the graph, write questions against retrieved documents, and keep only what survives the gate. The corpus is content-addressed, so a question that passes today re-verifies tomorrow against the same bytes.

endless synth run --n 20 --workers 6    # sample → write → gate → tasks.jsonl
endless dataset verify                  # offline: no network, no model calls
endless dataset export-verifiers        # verifiers-v1 taskset package

Coding tasks

Onboard a repository into a pinned image with a flake-screened test ledger, then mine instances from its history. Every instance is validated by execution against two states of the repo before it is allowed to exist.

endless coding select --n 10                   # graph concepts → candidate repos
endless coding onboard --repo <url>            # pinned image + test ledger
endless coding mine --since 2024-01-01         # mine instances → dual-state validation
endless coding verify-instances                # replay every instance from its images

Three families are built, differing in what the model is asked to do:

endless coding mine-testgen        # invert released bug fixes
endless coding mine-evolution      # mine merged pull requests

Export to whichever harness you train against:

endless coding export-chorus                       # chorus TaskRecord registry
endless coding export-harbor                       # Harbor task directories
endless coding publish-images --registry <prefix>  # retag; push only with --push
endless coding export-tree                         # one file per instance, for a git-backed corpus

What ships, and what does not

Datasets are outputs of your run, and are not distributed here. A search-QA record cites document hashes; a coding instance names a pinned image. Without the corpus and the images neither re-verifies, so shipping the JSONL alone would be shipping a claim with its evidence removed. endless dataset verify re-verifies against your corpus, built by your runs.

What to expect

Measured results, including the ones that did not go our way — worth reading before you plan around this:

• Difficulty is expensive to measure and noisy. Per-task pass rate is ±0.24 at 5 rollouts, exactly binomial. Aggregate over 30+ tasks; never read a single task's label.
• The graph does not make tasks hard. Four independent levers each improved a question's shape and left the mean pass rate at 0.88. What the graph is actually for is coverage and checkable grounding.
• Onboarding is mechanical, and bounded. Roughly 83% success on curated mainstream Python, near 0% on the long tail the graph selects.
• A task's statement is the binding constraint, not its difficulty. In one 80-episode run every instance scored 0.000, not because the work was hard but because the statements under-specified what the tests check. Re-deriving each statement from what the pull request actually merged moved one instance from a flat 0.167 to a mean of 0.938.
• Offline re-verification holds. 25/25 on the search set, 8/9 on coding — the miss being a real catch, an oracle whose verdict depended on set ordering.

Docs

Design notes, decisions and measured results live in docs/ as a numbered series — start at docs/000-overview.md.