Composer autoinstall: how older versions help train new ones

Cursor introduced Composer autoinstall — a system that uses earlier versions of the Composer model to automatically prepare environments for reinforcement learning training. During the development of Composer 2, the team used version 1.5 to manage this process. The idea is based on experience with Cursor cloud agents, but applied to RL training of the models themselves.

Why broken environments kill learning

RL training requires working environments. If a project won't compile, dependencies won't install, or configuration refuses to run, the model wastes tokens on debugging instead of learning to solve real programming problems. In the worst cases, a broken environment makes the task completely unsolvable — the model receives no reward signal and simply burns computation in vain. This is expensive and inefficient.

Two-stage bootstrap process

Autoinstall works through a simple yet ingenious scheme. Stage 1: Scout agent determines the goal. The first version of the model (Composer 1.

5) is given a repository in a fixed state. It must propose 10 commands and a high-level description of their output if the environment is properly configured. The model studies README and Makefile, tries language-specific commands (`uv`, `npm install`, `clippy`, `pytest`), and explores the project structure.

The result is a list of setup commands, tests, and run scripts. Stage 2: The second agent implements it. The second version (Composer 2) receives the initial state of the project plus three target commands selected from the proposed ten.

Its task is to call tools (search, compilation, linter), explore the code, and configure the environment so that all three commands run and their output matches the description from stage 1. If it doesn't match — the process repeats. After five failed attempts, the environment is rejected.

• The model explores code and runs search tools
• Installs dependencies through package manager
• Performs configuration (configuration, environment variables)
• Checks output against target description
• Repeats until success or attempt limit

How the model overcomes missing components

Composer is willing to go far to achieve a working environment. The model mocks missing files, creates stubs for images, even fake tables in databases. If a project needs cloud services like S3 or sidecar containers, Composer creates their equivalents — MinIO configs for S3, Docker containers for services. For long-running processes, the system generates a startup script that launches these components at the beginning of the RL session.

"Modern language models will go to great lengths to successfully configure an environment, mock dependencies, and test that the setup works," says the

Cursor team.

What this means for the future

The idea is simple, but carries enormous significance. Composer uses its own older version as a helper to prepare the working foundation for the new version. This not only saves computation, but also improves the signal for reinforcement learning. Each new version of the model now stands on the shoulders of its predecessors. It is logical to assume that in the future, such bootstrapping will become standard in training large language models.