# TestSprite's CLI hands your coding agent one clean failure at a time > Source: > Published: 2026-07-12 14:23:09+00:00 TestSprite's CLI makes a design choice most testing tools would never advertise: it refuses to do something. When a coding agent asks for a failure report, `testsprite test failure get` returns exactly one bundle tied to a single `snapshotId` , and the tool will not stitch data from two different runs together. The README calls the alternative a "frankenstein context," and avoiding it is the whole point. The pitch is narrow and specific: AI writes code in minutes, but verifying that code hasn't caught up. `testsprite` opens your live app, uses it like a real user, and hands your coding agent a description of what broke so the agent can fix its own work before the bug reaches you. This repo, testsprite-cli, is the official CLI for the TestSprite platform, which the README says 100,000+ teams use to test frontend and backend in the cloud against the running product rather than mocks. The README leads with one external claim worth flagging as a claim: on the Codercup leaderboard, it says, the cheapest model in the field shipped the most correct app at 89%, at half the cost of the priciest, with this CLI in the loop. That is the repo's headline evidence for "verification beats model size." Take it as the authors' framing, not an independent result. The interesting part is the shape of the workflow, because it is built for an agent to drive, not a human to read. The README walks through a three-command session: `testsprite test create` describes a behavior, runs it, waits, and exits 1 when the run fails.`testsprite test failure get` pulls one self-contained bundle: the failing step, its neighbors, screenshots, DOM snapshots, the test source, a root-cause hypothesis, and a recommended fix target.`testsprite test rerun` replays after the agent edits the code, exiting 0 on pass.Every pass is banked into a durable suite instead of thrown away. The output is agent-shaped by construction: a stable `--output json` contract, predictable exit codes, and a `--dry-run` that exercises the full code path offline with canned data. That last flag matters for anyone who wants to learn the command surface without spending API calls or touching a live app. `testsprite setup` prompts for an API key, verifies it, and installs a verification-loop skill for whatever coding agent you use. The README lists `claude` , `cursor` , `cline` , `windsurf` , `antigravity` , and `codex` , with a separate `agent install` command covering `kiro` and `copilot` as well. The idea is that you point Claude Code or Cursor at TestSprite, have it run `setup` , and the agent then knows how to create, run, and triage tests on its own rather than guessing from the README. There is a non-interactive path too, `TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude` , for CI and onboarding scripts. The command table is broad for a project created in June 2026: read commands (`project list` , `test steps` , `test failure summary` ), write commands (`test create-batch` , `test code put` with etag guarding, `test plan put` ), and run commands (`test run --all` in wave order, `test wait` on a `runId` ). Older names like `init` and `auth configure` survive as deprecated aliases that print a notice, so existing scripts keep working. The CLI is Apache-2.0 and written in TypeScript, requiring Node 20.19+, 22.13+, or 24+. It is a client for a paid cloud platform, so the CLI alone does nothing without an API key, and the "tests against the live product in the cloud" model means your app has to be reachable. The README is thin on pricing, self-hosting, and what the failure bundle looks like on disk. For an agent-first testing loop, though, the core bet is clear: give the model one clean, self-consistent view of a failure, and let it close the loop itself. **GitHub:** [https://github.com/TestSprite/testsprite-cli](https://github.com/TestSprite/testsprite-cli) *Curated by Agent Palisade — practical AI for small and mid-sized businesses.*