ASPIRE: continual learning for robots where training refines skills instead of weights

Training as skill refinement rather than gradient descent

ASPIRE is presented as a new type of continual learning in which training is skill refinement instead of gradient descent. The README rewrites three familiar concepts to make the point. The trained model is a repo of sensorimotor skills instead of floating weights. Distributed training is a panel of agents each practicing a different skill instead of sharded minibatches.

That reframing is the whole thesis of the project, and it explains why the repository looks nothing like a reinforcement learning codebase. There is no training loop to babysit, no checkpoint to serve, no dataset to shuffle. What you get at the end is code.

The audience is a robotics group that wants a policy to be inspectable, editable and reviewable, and that is willing to let an agent do the iteration. A manipulation policy that is a function in a repository can be diffed, unit tested, and handed to a colleague who does not read machine learning. The cost is equally clear: nothing improves unless something in the loop writes new code and proves it works, so the surrounding infrastructure has to be real.

The published numbers are in the same spirit. The README reports that in the 2026-10 release, ASPIRE can solve a Rubik's Cube and achieves 99% success on 80 LIBERO-Pro Goal, Object, Spatial and Long tasks along with selected Robosuite and BEHAVIOR-1K tasks. An earlier 2026-06 entry claims state of the art results on LIBERO-Pro, Robosuite and BEHAVIOR-1K with Claude Opus 4.6. Those are the project's own claims, and no independent replication is described in the repository.

The pipeline ships as agent skills, not as a training script

The mechanism that produces those results is a coding agent working through a skill library. The repository carries three separate skill directories, .claude/skills/ for Claude Code, .codex/skills/ for Codex, and .agents/ at the top level, and the README names two skills: iterative-debugging and evosearch. The simulation workflow is packaged in both coding agent flavours, which the README calls agent skills, and the project states that ASPIRE is coding agent agnostic.

A separate file, AGENTS.md, holds the execution rules for the real-robot System 2 agent, linked to an operator runbook in docs/system2.md, and the README is explicit that this file is not needed for simulation runs. That separation is a design signal. The real-robot path is treated as a different system with a different safety regime, deliberately walled off from the simulation path.

The rest of the layout supports the same split. There are example directories for behavior, libero, robosuite and yam_real, a configs directory, a scripts directory, a src directory, a tests directory, docs and third_party, plus a .gitmodules file and a uv.lock. The docs referenced from the README include docs/host-setup.md for machine preparation, docs/libero-pro.md for the LIBERO-Pro workflow, docs/yam-real.md and docs/system2.md for the hardware side, and a Playwright style README under tests.

The practical consequence for a user is that you are not running a command with flags. You are briefing an agent, and the agent reads skills, runs experiments and iterates on code until the task succeeds.

The quick start is a prompt, and the host needs credentials before it runs

Getting started means launching a coding agent such as Codex or Claude Code and pasting a prompt. The prompt in the README instructs the agent to clone the main branch, read the iterative-debugging skill and the LIBERO-Pro guide, and run the complete Goal-Swap quick start for all ten tasks in the libero_goal_swap suite. It then tells the agent to report the required GPUs, credentials, gated weights, services, expected runtime, seed partitions and output paths, and to wait for confirmation before launching. The final instruction blocks access to the real-robot code and instructions.

Clone the main branch of https://github.com/NVlabs/ASPIRE/,
read the iterative-debugging skill (.claude/skills/iterative-debugging/SKILL.md) and
docs/libero-pro.md, and run the complete ASPIRE LIBERO-Pro Goal-Swap Quick Start for
all ten tasks in the libero_goal_swap suite.

Before executing, report the required GPUs, credentials, gated weights,
services, expected runtime, seed partitions, and output paths. Wait for
my confirmation before launching. Do not access real-robot code or instructions
(AGENTS.md, docs/system2*.md, docs/yam-real.md, src/cap_harness/yam_real/).

Two things stand out. The agent is expected to plan and report before it spends anything, which matters when the plan includes paid model API calls. And the read-only boundary around the real-robot path is written into the prompt itself rather than left to a policy document, which is a sensible defence in depth for a system that touches hardware.

Before any of it runs, the host has to be prepared. The README points to docs/host-setup.md for setting up CUDA, uv and the Hugging Face token needed for the gated SAM3 weights. Gated weights mean an account with an accepted licence request, so this is a step that can take days of waiting and is not mentioned until the very end of the quick start list.

cap-harness: typed Code-as-Policy APIs split by provider and simulator

The Python package in the repository is called cap-harness, described as typed Code-as-Policy APIs for LIBERO-Pro, Robosuite and real YAM. It is a private project with version 0.1.0, which tells you the packaging is internal to the research code rather than a published library.

[project]
name = "cap-harness"
version = "0.1.0"
description = "Typed Code-as-Policy APIs for LIBERO-Pro, Robosuite, and real YAM."
readme = "README.md"
license = "Apache-2.0"
license-files = ["LICENSE", "NOTICE"]
requires-python = ">=3.10,<3.13"

The Python window is narrow and worth checking before you plan anything: 3.10 up to but not including 3.13. The base dependencies are deliberately light, numpy, requests, scipy and PyYAML, which means the heavy libraries arrive only through extras.

The extras are organised by role, and the comment explaining why is the most useful line in the file. Each model server installs only its own dependencies, so a provider virtual environment named with the pattern .venv-<name> never carries unrelated model stacks, and simulator installs can stay client-only.

agent = [
  "fastapi>=0.115",
  "uvicorn>=0.34",
  "viser[urdf]>=1.0.30,<2",
  "mcp>=1.26,<2",
  "pillow>=10",
  "jsonschema>=4",
]

The agent extra pulls in FastAPI and Uvicorn for serving, viser with URDF support for visualisation, and an MCP server implementation, which fits a project whose whole premise is that a coding agent drives the loop and therefore needs tool access. There are separate extras for the libero and robosuite simulators, each with gymnasium, imageio with ffmpeg, matplotlib, headless OpenCV and termcolor, and the libero extra adds the simulators and datasets themselves, including libero, robosuite, robomimic and bddl. One dependency is called out by name as an exception: cuRobo is compiled from source by its own bootstrap script and is intentionally not a pip extra, so a full install needs a build step that the extras cannot give you.

Reported results, and the observation that stronger models help

The headline numbers in the README are specific, which makes them checkable in principle. On 10 LIBERO-Pro tasks, success is reported as rising from 15% with GPT-6 Luna to 99% with Claude Opus 5.5, and across LIBERO-Pro, Robosuite and BEHAVIOR-1K, Claude Opus 5.5 is reported at 97 to 100% success on every task. The 2026-10 release adds a Rubik's Cube solved with GPT-6 Astra, and a long horizon table bussing task run with Claude Opus 4.6 in simulation and GPT-5.5 on the real robot.

The most interesting claim is not a success rate. The README says the strongest models are not the most expensive, and points at a cost and success frontier charted across twelve coding agent models. If that holds, the workflow is not simply burning tokens until something works. A stronger code writer finds better strategies at a given budget.

The demos are annotated with behaviour differences that show the claim is about strategy, not luck. On the book under a shelf task, Opus 5.5 and Astra let go of the book and push it under the low shelf. On pushing a plate, Opus 5.5 clears the clutter first while Astra lifts the plate over it. On opening the bottom drawer, both tilt the gripper and hook the low handle the way a human does. Different valid approaches from different models.

The caveat is that all of these figures are self-reported by the project, in a README that also shows video. The repository does not include an independent evaluation, and the claim spans two different model families, so a reader who wants to trust the numbers has to rerun the quick start themselves and compare against the seed partitions the prompt asks the agent to report.

Real hardware lives behind its own runbook, extras and safety rules

The real-robot half of the project is the YAM path, and it is packaged as a separate world. The real-robot extras in pyproject.toml carry a different stack from the simulation ones: imageio with ffmpeg, portal, mink, mujoco pinned to 3.3.0, and pyrealsense2 for RealSense cameras, with a further extra for a damiao motor package in the server role. A vision and manipulation stack with a physics engine and camera drivers is a much heavier install than the simulation path, and it is separated so that a simulation user never pulls it in.

The human-facing side is the System 2 runbook in docs/system2.md, which the AGENTS.md execution rules point to, and the README lists the linked task pages for a Rubik's Cube, inverted cup nesting, unscrewing a bottle cap, pill insertion with bottle closure, and stack cups. Cross-embodiment sim-to-real and online real-world learning are shown side by side in the results table.

For an adopter this is where the risk concentrates. The simulation path is a code review problem. The hardware path is a safety problem, and the repository's own structure acknowledges that: AGENTS.md governs it, the quick start prompt explicitly forbids the agent from touching the real-robot code or instructions, and the operator runbook is written for a person, not an agent. The honest reading is that the hardware experiments are documented, while the automated loop stays in simulation.

Apache-2.0, an unreleased repository and a paper behind the claims

The licence is Apache-2.0, recorded in pyproject.toml as license Apache-2.0 with LICENSE and NOTICE declared as licence files. Apache-2.0 is a permissive licence with an express patent grant, which suits research code that other groups may want to build on. That reading is factual and not legal advice, and the NOTICE file should be reviewed if you redistribute the code or derived work in a product.

The project has no GitHub releases, so there is no tagged version to pin and no changelog of published artefacts. The default branch is main, and the last push was on 2026-10-16, which is recent. The versioning lives inside the repository instead, with the package at 0.1.0 and the README announcing a v1.0 milestone in its 2026-10 news entry, alongside a project page hosted by NVIDIA Research and a paper on arXiv.

The upgrade cost for a user is therefore the cost of tracking a moving main branch. A uv.lock file is present, which helps, but there is no release cadence to plan against and no stability promise beyond the reference agent environments being described as coding agent agnostic. Treat the skills directory and the pyproject extras as the interface that matters, and expect to rebase rather than to upgrade.

Editorial conclusion

ASPIRE is worth a look for a robotics team that already has simulation infrastructure, a strong coding agent available, and a policy that is easier to write as code than to learn as weights, since the deliverable is a readable skill repository rather than a checkpoint. It is the wrong tool for a team without GPUs, without credentials for gated model weights, or without the patience to supervise an agent that reports its plan before it launches. Before adopting, read docs/host-setup.md and the LIBERO-Pro guide in the repository, then check the 3.10 to 3.12 Python window and the per-provider virtual environment layout in pyproject.toml, because the cuRobo stack is compiled from source rather than installed as an extra and will need its own bootstrap step.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. NVlabs/ASPIRE on GitHub
4. Project website
5. README