Sapling

Sapling is pair research: an interactive frontier autoresearch system that humans guide through conversation, built for machine learning, math, and computational sciences.

Comment

Sapling

Sapling is pair research: an interactive frontier autoresearch system that humans guide through conversation, built for machine learning, math, and computational science.

Inspiration

Frontier autoresearch systems can now sustain large research efforts. OpenAI recently ran 10,000 agents on the Navier–Stokes Millennium Prize problem. The AI Scientist-v2 wrote a workshop paper end to end. AIRA(_2) runs experiments asynchronously across a large research tree.

Agents are great at executing research tasks, but not so great at dictating research taste.

Long-horizon research depends on choices that are hard to specify in advance. Which question is worth asking? Whats the end goal? Which result needs to be replicated? When is a promising direction no longer worth pursuing?

Sapling keeps a human inside the research process while it runs. The system handles search, experiments, memory, and coordination. The human provides direction through the same conversation they use to understand the work.

Codex and Claude Code made pair programming a normal way to build software. Sapling applies that interaction model to research. We call it "pair research".

Moreover, sapling enables us to collect interaction data exactly for this weak point of current LLMs and agents to allow the development of even stronger research models. We even train our own today!

What it does

Every Sapling project starts with a conversation. The root researcher searches the literature, challenges assumptions, and turns a rough idea into a research direction. Once the direction is clear, it starts a persistent and steerable autoresearch campaign modeled after papers Aira_2 and Google's MARS.

Starting a campaign creates a live research tree. Sapling can pursue competing explanations, read the literature, run experiments, and split promising directions into new groups. The coordinator keeps useful work moving and reprioritizes the tree as results arrive.

You steer from the root. If you say: “I do not believe this explanation. Test this instead...” Sapling can redirect the relevant branches while everything else keeps running.

Research interaction data for frontier models

Pair research produces a second output: research interaction data.

Papers preserve results. Sapling also records the path: rejected directions, human corrections, failed experiments, changing priorities, and the evidence available when each decision was made. Essentially the research "taste" humans have developed.

AI coding tools already generate this kind of supervision. SpaceX acquired Cursor partly for the data created by its coding workflow: prompts, iteration cycles, and architecture decisions. Sapling produces the research version: questions, evidence, candidate directions, corrections, decisions, and outcomes.

We built and deployed the full loop at demo scale:

8 redacted decision states
        ↓
8 GPT-5.6 Terra demonstrations
        ↓
6 chosen/rejected preference pairs
        ↓
gpt-oss-20b: SFT → DPO
        ↓
Custom Research Model: Accessible in Sapling under the name "Sapling Research" in the model selector.

The Custom Research Model is a general research model specialized for Sapling. SFT distills how a strong teacher model uses the system's literature, evidence, experiments, and coordination tools. DPO trains on expert human preferred research decisions.

How we built it

Sapling has a Python/FastAPI runtime and a Next.js interface. The database holds the canonical research state.

Every node uses the same research contract. It receives the current objective, relevant claims and evidence, messages, tools, and remaining budget. It returns a structured action to search, read, experiment, publish evidence, delegate, branch, reallocate, or stop. Sapling validates the action and saves the result before the next turn.

Jobs are persisted, leased, and heartbeated. Work can recover after an interruption, and stale results cannot overwrite newer state. Experiments retain their code, Git state, commands, environment, logs, metrics, artifacts, and parent run.

The main campaign uses the OpenAI Responses API for every researcher and coordinator.

OpenAI's gpt-oss-20b is the base for the Custom Research Model. Teacher model responses were distilled from GPT 5.6 Sol interactions on Sapling itself, with research preference data from our own test runs.

We built Sapling with Codex. Our method of development would often be presenting a set of features, changes, or issues from testing then requesting a plan to be developed (On a strong model like 5.6 sol). We would then iterate with Codex on the plan until it is correct. Finally, we would switch to a more efficient model like Terra for implementation of the plan.

Sapling handles the messy data required by the Rox track. Sources can be incomplete or disagree. Experiments can fail. Sapling keeps conflicts attached to the relevant claim and responds with another research action: retrieve the primary source, run an independent check, or search for a counterexample.

Baseten is available through the same model selection, providing the best open source model options. A Baseten-hosted open model can run any researcher or coordinator without changing the research runtime.

Challenges we ran into

Getting the researchers to work together

Early versions created several branches, collected the results, and stopped. The nodes did not consistently share useful evidence, expand the frontier, or create follow-up work. We added a persistent campaign coordinator that ranks the frontier, routes results between nodes, queues work, and starts the next research round.

Ordinary agent failures

Agents make bad tool calls, return the wrong structured output, repeat failed actions, hit output limits, and stop before finishing. Sapling keeps these failures local. The coordinator can retry, choose another route, or continue with the limitation recorded.

Switching training providers

The planned Baseten training run and deployment of the Custom Research Model were unavailable for our workspace. We switched to Together for SFT, DPO, and serving.

Accomplishments that we’re proud of

  • The whole project :) . This is something I have been thinking about for a while from my own workflows and observations in the ML research space. I am happy with the execution and will continue iterating on it.

Try it out locally

GitHub: nomitchell/sapling

Built With

Share this project:

Updates

Submission history