deadeye

He doesn't check twice, and he doesn't spray and pray. One round chambered, one shot on target, and he's done — because the shot you never had to take is the best one. deadeye puts that discipline inside your coding agent.

It watches what your agent is about to do — spawn a subagent, dump a noisy test log, make a big multi-file edit — and fits the model, effort level, and context to the task before the tokens are spent, not after. Left alone, a coding agent spends more than a task needs; deadeye catches that at the choke points it already sits on. Everything it remembers lives in one local file: no hosted service, no API keys, no telemetry.

Full feature tour, with live examples → the site

Numbers

Every figure is measured, not averaged or modelled. The command-output rows are logged to ~/.deadeye/decisions.jsonl; the persona row is measured directly off the two rendered artifacts (full ruleset vs. the card a subagent inherits), since the log carries only an estimate on that path. The rewrite happens before the command runs, so only the part worth keeping ever enters context.

Real run	Before	After	Cut
go test with one genuine failure	485 B	99 B	79.6%
This repo's own suite (202 lines, all passing)	10,301 B	55 B	99.5%
npm install express mocha (progress spam)	553 B	55 B	90.1%
Coder persona a subagent inherits, per spawn	9,499 B	1,099 B	88.4%

Run /deadeye-stats savings to see your own. Quiet no-op events (95% of all rows on one real machine) aren't logged at all — the log holds only the rows where deadeye actually did something.

How it works

1. Look      Cheap, deterministic signals: files touched, recent git activity, whether tests exist nearby, how the request reads, whether the task itself names something real, and whether it's a read-only subagent
2. Decide    The cheapest (model, effort) that should still clear the bar for this task
3. Apply     Rewrites the subagent's model, trims noisy command output, asks before risky multi-file edits
4. Learn     If you manually pick a bigger model than it recommended, it gets more cautious for that kind of task next time

The rule behind all four: when unsure, a capable middle — not the priciest. Thin or shaky evidence defaults to the sonnet tier, reserving opus for genuinely high-complexity work; picking cheaper needs real evidence above a confidence bar. An AI judge (claude -p, no API key, on by default — one config flag to turn off) classifies the ambiguous cases for a sharper call. Every decision is printable: run /deadeye-route to see the full reasoning, never a black box. deadeye advises by default and never touches your settings.json; if anything inside it errors, your call passes through untouched.

Benchmark

Two questions, measured separately: does routing to a cheaper model actually save money without losing quality, and does the PR reviewer actually catch real bugs?

Routing savings

Does routing to a cheaper model actually save money, or just do worse work? We measured it: every task run on all three tiers, graded by a hidden test the model never saw, priced from real billed total_cost_usd (deadeye off during runs, so it's raw per-tier model cost).

Identical, verified-correct output cost 3–9× more on opus than haiku (median ~6×). And 5 of 6 well-scoped tasks passed on haiku — including SemVer precedence and a concurrent counter under -race — so downshifting the common case is nearly free in quality. The one task that needed opus (a recursive expression evaluator) is exactly the case routing sends up.

Task	Band	haiku	opus	opus ÷ haiku
counter	hard	$0.034	$0.311	9.1×
wordwrap	standard	$0.046	$0.331	7.1×
clamp	mechanical	$0.026	$0.160	6.1×
semver	hard	$0.055	$0.265	4.8×
csv	standard	$0.060	$0.204	3.4×

Oracle routing (cheapest tier that passed) cut model cost ~63% vs all-opus on this set — illustrative, since it depends on task mix; the per-task ratio above is the robust, mix-independent claim. Full method, honest caveats, and the pass/fail grid: the benchmark page · reproduce it in benchmarks/routing/.

Review quality (held-out)

Does the PR reviewer actually catch real bugs? We measured it on 24 real-world pull requests across 17 projects, each one shipping a bug the project later fixed in a follow-up commit. deadeye reviewed the introducing PR cold — diff and source only, no fix, no comments — and the project's own fix is the answer key. A finding counts as a catch only when it matches what the fix changed; anything ambiguous is scored a miss.

Recall 61% (11/18) at 97% precision — one false positive across 31 findings, every finding re-verified in source by an adversarial pass. It caught every authorization regression in the set (4/4) — the cross-file permission bugs a diff-only reviewer misses — and was weakest on concurrency races (1/4), the honest soft spot. Beyond the 24 seeded bugs it surfaced 17 more real issues on the same PRs.

Held-out, graded against public git history, precision adversarially verified. Full breakdown by bug class: the benchmark page.

Install

deadeye is a Claude Code plugin at its core, and also runs — to varying depth — on four other hosts.

Claude Code

/plugin marketplace add deepaksinghcs14/deadeye-cc

/plugin install deadeye@deadeye

macOS/Linux: that's everything. Hooks and slash commands are live immediately, and the binary bootstraps itself on first use — downloaded once from Releases, sha256-verified, no extra step.

Windows: self-bootstrap isn't built yet, so the binary needs a manual step after the two commands above:

1. Download deadeye_windows_amd64.exe (or _arm64) from Releases.
2. Either put it on PATH as deadeye.exe, or place it at the managed path deadeye's hooks look for: %USERPROFILE%\.deadeye\bin\deadeye.exe.
3. Run deadeye version to confirm it resolves. /deadeye-status flags a version mismatch if a stale copy shadows the plugin later.

Codex CLI (experimental)

Install the binary, then deadeye init codex — it shows the exact Codex hooks file changes ($CODEX_HOME/hooks.json, or ~/.codex/hooks.json) and writes them only after you confirm (deadeye never edits another tool's config silently). You get output trimming, the coder persona, the plan gate, /deadeye-mute, and the full decision log; not Claude-style model routing. Older Codex builds may need [features] hooks = true in the Codex config. Init also installs the $deadeye-pr, $deadeye-review, and $deadeye-vapt user skills. Remove with deadeye uninstall codex.

Gemini CLI (experimental — context-injection tier)

deadeye init gemini writes a self-contained extension under ~/.deadeye/gemini-extension/ and prints the gemini extensions install command — deadeye never edits Gemini's own config. You get the coder persona plus session guidance (codemap, vulnerable-dependency flag, soft plan gate). The tool-level features (exfil guard, output trimming, routing) wait on live schema verification rather than risk firing blind. Remove with deadeye uninstall gemini.

Cursor and Windsurf (persona only)

No hook contract, so these get the coder persona only, as a rules file:

deadeye init cursor      # writes .cursor/rules/deadeye.md
deadeye init windsurf    # writes .windsurf/rules/deadeye.md

Level-filtered to your coder.default_level, and uninstall removes only what deadeye wrote. For the full engine, use Claude Code or Codex.

Review commands on every host (experimental)

deadeye init <host> also installs all three on-demand review commands — /deadeye-pr (a GitHub PR), /deadeye-review (the working diff, or --repo), and /deadeye-vapt (a whole-service pen-test/VAPT pass) — in that host's native format: a Codex user skill, a Gemini TOML command, a Cursor skill, a Windsurf workflow. Windsurf's 12000-char workflow cap drops the "Rigor" habits section and the learning loop/fix-acceleration extras (and, for /deadeye-vapt, the OWASP id-mapping reference tables — the tags and method still carry the full pass) to fit; every other host gets the rubric in full. Experimental until live-verified.

From source

go install github.com/deepaksinghcs14/deadeye-cc/cmd/deadeye@latest

Is it actually working?

deadeye doctor

One read-only pass over the plumbing: which binary is running and whether a stale one on PATH shadows it, whether ~/.deadeye is private, whether config.json parses (it fails open to defaults, so a stray comma silently reverts every setting), the socket path, daemon liveness, whether the routing judge can actually reach claude, whether the hook manifest covers every tool deadeye dispatches, and how large the stores have grown. Each failure prints the command that fixes it, and it exits non-zero if anything failed.

Reach for it whenever deadeye seems to be doing nothing. status reports what the settings are; every silent failure this plugin has shipped was plumbing underneath them, and status looked perfect through all of it.

Uninstall

deadeye uninstall --purge   # removes the binary, the daemon socket, and ~/.deadeye

Then /plugin uninstall deadeye@deadeye in Claude Code.

What it controls

Nine independent controls — each has its own on/off, and switching one off never touches the others.

What	Modes	What it does
Context hygiene	off / on	Trims verbose command output (test suites across nine ecosystems, builds, linters, installs, log tails) before it enters context, and flags wasteful patterns — re-reading unchanged files, re-running the same command, an oversized MCP response, a good moment to /compact.
Coder persona	off / spotter / marksman / sniper	A lean-first coding discipline — including a live security check on what's written and its dependencies — injected each session and into subagents.