Version 1.0 trains the agent loop, not a chat transcript
Agent Lightning v1.0 separates agent execution from policy training. A rollout controller runs the existing agent locally or as a Kubernetes Job. An API gateway proxies model calls and records events, while a trainer backed by Verl and vLLM turns those events into samples and updates the model. The agent can keep its tools, context, and branching logic in the loop, which is the feature that distinguishes this project from a plain prompt log or preference dataset.
Our checkout contained 164 files, about 14,049 lines of source, and 2.8 MB before installation. The README calls the core framework roughly 3,500 lines, so its claim is using a narrower boundary than our repository-wide source count. Microsoft also reports a coding-agent run that moved SWE-bench Verified from 41.8% to 56.4% using 6K training samples. That is the project's result, not a benchmark we reproduced.
What happened when we ran it
Our sandbox installed 83 packages in 20 seconds and occupied 203 MB. The package build completed in 1 second. That base result is encouraging for developers who want to read the APIs, run light components, or inspect the included Agent Lightning skill. It does not cover the documented training stack, model weights, Calc-X data, an A100, or a Kubernetes cluster. Those were outside this measurement.
Pytest exited 1 after 8 seconds. It reported 82 passed, 0 failed, 2 skipped, 2 warnings, and 2 collection/setup errors. The errors were in tests/verl/test_agl_rollout_manager.py and tests/verl/test_rollout_level_advantage.py. The supplied tail shows Starlette and AnyIO deprecation warnings plus the summary, but not the exception that caused collection to fail. Pip-audit also found 1 known vulnerability, with no severity given in our result.
The 83-package base is the small part of setup
The 83-package environment does not include the whole training route described by Microsoft. Agent Lightning requires Python 3.12. Its installation guide supports CUDA 12.9 and 13.0, recommends Verl 0.8.0 on CUDA 13.0, pins compatible vLLM versions, and builds FlashAttention against that environment. These coupled packages are common sources of friction in GPU work, and the guide acknowledges that FlashAttention installation can be error-prone.
Our base install took 20 seconds, while an actual task also needs data, a model, reward logic, storage, and process cleanup. Weights & Biases receives logs and trajectories by default, so the standard setup includes a W&B login and an explicit decision about what may leave the machine. Kubernetes mode adds cluster access and runnable images. The repository has 5 CI workflow files and a tests directory, but no root Dockerfile that freezes the entire training environment.
One A100 is the documented starting point
The shortest v1.0 quick start asks for one machine with one A100 GPU. It downloads Calc-X data, installs AutoGen, MCP calculator packages, OpenAI client libraries, and starts Ray, the Verl and vLLM backend, the gateway on port 8181, and a local controller. The launcher writes service logs under /tmp/. Native Windows cannot use that local runner, so Microsoft directs Windows users to a Linux environment such as WSL.
The 203 MB measured install therefore answers whether the Python package is approachable, not whether your team can afford or operate training. Kubernetes helps isolate rollouts, but issue 567 describes missing example images leaving jobs in image-pull backoff until a 1,800-second deadline while GPUs wait. An open pull request proposes a readiness check. Before committing compute, test one dataset row through image lookup, agent execution, reward emission, and cleanup.
Version 1.0.1 is active while training questions remain open
Agent Lightning v1.0.1 was released on August 24, 2026, and GitHub recorded the last push on September 17. The repository had 18,329 stars and 160 combined issues and pull requests when fetched. Current September issues and patches show active maintenance. The release also introduced an Agent Lightning skill for Claude Code, Codex, and GitHub Copilot that guides measured changes to an editable agent against a benchmark.
The 2 collection errors in our run land beside two specific open questions. Issue 592 reports that the pinned Verl server cannot load custom vLLM parser plugins, blocking models without a built-in parser. Issue 593 questions whether the default per-rollout loss divides by rows rather than distinct rollouts when one rollout spans several rows. The reporter supplied a reproduction, but the issue remains open, so verify the intended loss semantics before treating a long training run as comparable.
Eighty-two passing tests justify a trial, not a blind run
The 82 passing tests show that most of the collected suite worked in our clean container, while the 2 setup errors keep the checkout from earning a clean bill of health. TRL is the simpler choice for standard fine-tuning and preference work. Verl exposes the lower training layer directly. OpenRLHF fits teams focused on large-scale post-training. Agent Lightning earns its place when rewards must come from a working agent using real tools and environments.
Our 20-second install and 1-second build make source evaluation cheap. Actual adoption starts after that: pin the GPU matrix, reproduce the two failing collections, inspect the single audit finding, and run a small held-out benchmark through the same gateway and controller used in training. If the real harness is the data you need, those jobs buy something. If ordinary model post-training is enough, a narrower framework leaves fewer services and failure modes to own.