Your AI agent says "done." Reticle checks whether that's true.

It drives your real running app, reads what actually happened, and hands back pass · fail · couldn't tell with the file:line to fix.

Install · Use it · How it works · vs Playwright · Benchmarks · Limits · Docs

_{▶ Two minutes. An agent finds a bug the screen was hiding, and proves the fix.}

Install

Three steps. The first one is the whole install.

1. Run the installer

macOS · Linux

curl -fsSL https://raw.githubusercontent.com/reticlehq/reticle/main/install/install.sh | sh

Windows (PowerShell)

irm https://raw.githubusercontent.com/reticlehq/reticle/main/install/install.ps1 | iex

It puts reticle on your PATH and registers the MCP server with every coding agent it can reach: Claude Code, Cursor, Windsurf, VS Code, Zed, Gemini CLI, Copilot CLI, OpenCode, Warp, Kiro, Amazon Q, Cline, Amp, Continue and Factory Droid. Nothing is asked. Nothing is written outside your agent configs and ~/.reticle.

Codex CLI keeps a TOML config we don't rewrite, so the installer prints the four lines to paste and where they go. It tells you; it doesn't pretend.

2. Open your coding agent

That's it. The tools are already there, because the installer wrote the config before your agent started.

Run the installer first, in a terminal. A coding agent reads its MCP server list once at startup. Install while it's closed and there is nothing to restart. If it was already open, quit and reopen it once.

3. Wire your app

In your project, let your agent run:

RETICLE_INSTALL_SOURCE=readme npx @reticlehq/server init

Like npm init or git init, this is the per-project step. It installs the dev-only SDK, wires your build config, restarts your dev server, and then opens your app and proves a session connected. A config file is not an install, so init doesn't stop until it has seen your app.

Step 1 is once per machine. This step is once per project.

Check it worked

npx @reticlehq/server doctor

Or just ask your agent: "Is Reticle connected to my app?"

npm install -g @reticlehq/server   # 1. the CLI
npx @reticlehq/server setup mcp    # 2. register it with your agents

{ "mcpServers": { "reticle": { "command": "npx", "args": ["@reticlehq/server", "mcp"] } } }

/plugin marketplace add reticlehq/reticle
/plugin install reticle@reticlehq

npx skills add reticlehq/reticle

Use it

You never write test syntax. You say what should be true, in plain English.

Verify what you just built

"I changed checkout. Verify it with Reticle before you tell me it's done."

Find what the screen is hiding

"The page looks fine but something's off. Use Reticle to check what's happening underneath."

Prove a bug is fixed

"Reproduce the bug with Reticle, fix it, then prove the fix with the same steps."

Lock a flow so it can't break

"Record the login flow with Reticle, then re-verify it after every change."

Sweep before you ship

"Walk the main routes with Reticle. Tell me anything broken."

Reticle answers with evidence: the request that fired, the state that changed, the console line, and the file to open.

Why not Playwright?

Playwright, DevTools and browser agents all stand outside the browser looking in. For a site you don't own, that's right. For the app you're building, the bugs that matter never reach the pixels.

Use both. Playwright for sites you don't own, many browsers, real pixels. Reticle for the app you're building, inside your agent's loop.

The problem

Your agent writes code, assumes it worked, and moves on. It never opens the app.

So the broken modal, the silent 500, the "Deploy succeeded" over a failed deploy: they all ship, and you find them by clicking around afterwards. You've become your agent's QA.

The truth was in the running app the whole time. It just never reached the screen.

This isn't something your agent forgot. A coding agent is built to produce a change, and it's optimistic by construction. Verification is the opposite motion: going to find out, and being willing to come back with no.

How it works

You: "Verify login works."

Agent, via Reticle: clicks Sign in → POST /api/login → 200 (14 ms) → dashboard rendered → store holds auth: { email: "admin@…" } → PASS, evidence attached.

flowchart LR
    A["Your agent<br/>(Claude Code, Cursor…)"] -->|"look · act · observe · assert"| B(("Reticle"))
    B <-->|"structured events,<br/>not pixels"| C["Your running app<br/>DOM · network · console<br/>store · React fiber"]
    B -->|"verdict + evidence<br/>+ file:line"| A
    style B fill:#8b7bff,stroke:#5b4bd0,color:#fff
    style A fill:#15131f,stroke:#3a3550,color:#fff
    style C fill:#1c2433,stroke:#2f3d57,color:#fff

One call checks many things at once. Say "save that as a flow" and it replays on every later edit with no model in the loop, so today's fix can't quietly break last week's feature.

// The agent clicked "Pay". Did the right things actually happen?
reticle_assert({
  predicate: { allOf: [
    { kind: "net",     method: "POST", urlContains: "/api/order", status: 200 },
    { kind: "element", query: { role: "dialog", name: "Order confirmed" }, state: "visible" },
    { kind: "signal",  name: "order:saved" },          // the charge actually committed
    { kind: "console", level: "error", absent: true }  // …and nothing errored
  ]}
})
// → { pass: false,
//     failureReason: "POST /api/order returned 500, expected 200",
//     source: { file: "src/checkout/PayButton.tsx", line: 42 } }

Benchmarks

88 real regressions injected into a controlled app, Reticle against a Playwright script. Every number comes from a committed harness. Reproduce it with pnpm bench.

Re-verification has no model in the loop, so a recorded suite is a fixed, tiny read. Reticle is ahead from the second run even when charged a full LLM drive to author the suite.

Faster for a structural reason rather than a browser-speed one: a time-gated transition is verified from the event stream instead of waited out, and a batch of flows runs as a batch.

Limits

A verification tool that oversells its reach is worse than none.

When Reticle can't see something, it says so. A verdict is yes, no, or unknown, where unknown means the evidence couldn't decide. Never a quiet pass.

Cost: zero bytes in production. The SDK sits behind import.meta.env.DEV and is dead-code eliminated; a runtime guard refuses to connect under NODE_ENV=production. No app data leaves your machine.

Supported

On the roadmap

Routing verification flows with TypeSafe AI's Jev. A verification run makes a lot of small decisions — is this page settled, is this finding worth chasing, does this failure warrant a full capture — and today an LLM answers each one at LLM latency and LLM cost. Jev is a System One model: it returns a typed, probabilistic choice from a fixed set instead of prose, in 70–500ms. That is the exact shape of a routing decision inside Reticle's infra, so when we build that layer, Jev is what decides which flow a run takes. Nothing ships against it yet.

Docs

docs.reticle.sh — a page per tool, a page per command, every example captured from a real run.

Quickstart · Frameworks · Troubleshooting · Architecture · Contributing

Community

Join the Discord → Where the work happens in the open: what's being built, what's up for grabs, and design calls before they land.

If Reticle proves useful, a ⭐ helps other developers find it.

License

SDK and adapters are Apache-2.0. The server is FSL (source-available, converts to Apache-2.0 after two years). See LICENSE.

dev-only · localhost-only · your app data stays local