snip: a Go proxy that filters shell output before your AI agent reads it

The problem snip targets: agents paying tokens for passing tests

An AI coding agent that runs `go test ./...` receives every package line, every timing, and every `[no test files]` marker. The README's own example shows 18 lines of output for a green run, which it counts as 275 tokens. Almost none of that helps the model decide what to do next. The signal is one bit: did it pass.

snip is built for the people who pay for those tokens. The README names Claude Code, Cursor, GitHub Copilot, Gemini CLI, Codex, Windsurf, Cline, Aider and several others, and the integration table shows a different mechanism per tool: a PreToolUse hook for Claude Code and Codex, a `beforeShellExecution` hook for Cursor, prompt injection via GEMINI.md for Gemini CLI and via .windsurfrules for Windsurf. That variety is the honest part of the pitch. There is no single interception point across these tools, so snip ships per-agent wiring instead of pretending one hook fits all.

How the filter pipeline works: match, run, capture, rewrite

The README's diagram is the clearest description of the data flow. The agent issues a command. snip intercepts it, matches it against a filter, runs the command, captures stdout and stderr, pushes the captured text through a pipeline, records the savings in SQLite, and returns the filtered text to the agent.

The filters themselves are YAML data files, not compiled code. The repository has a top-level `filters/` directory, and the README frames this as the central design choice: `filters are YAML data files, not compiled code`. Adding coverage for a new command means writing YAML, not rebuilding a Go binary.

The `go test` filter is the most illustrative example. It injects `-json` into the command and counts individual test results, so the agent sees `1125 passed, 0 failed` instead of 18 package-level lines. That is a real change in what the model knows: the package summary hides how many tests ran, the JSON count does not. The README states the reduction is 97% on that command in its own repository.

The pass-through rule matters as much as the filtering. If no filter matches, the command runs unchanged. That keeps snip from becoming a universal output mangler, and it means the failure mode is bounded to commands someone wrote a filter for.

Installing snip and hooking it into Claude Code

The README lists three install paths. Homebrew is marked recommended, the release tarballs cover platforms without a package manager, and `go install` works if you already have a Go toolchain. The module requires Go 1.25.8 according to go.mod, and the README states Go 1.25+.

brew install edouard-claude/tap/snip

After that, the quick start is a single command. The README says `snip init` hooks into Claude Code and that every shell command Claude runs then goes through snip. For other agents the flag differs, for example `snip init --agent cursor` or `snip init --agent copilot`.

snip init

If you prefer building from source, the README gives this path. The Makefile defines `install`, `install-lite`, `upgrade` and `upgrade-lite` targets that resolve a destination from `GOBIN`, `go env GOBIN`, or the first `go env GOPATH` entry plus `/bin`.

git clone https://github.com/edouard-claude/snip.git
cd snip && make install

The first thing to run after install is not a filtered command. The Makefile separates `test` from `verify`, with the comment that filter YAML tests are not exercised by `go test`. So the filter definitions have their own verification step, and it is the one that tells you whether the YAML you are relying on actually parses and behaves.

snip verify

A savings report is part of the tool, showing commands filtered, tokens saved, average savings and a per-command table. The README's sample report shows a 14-day trend and a top-commands breakdown by tokens saved.

The filter set is the product, and the README does not say how it fails

The headline number, 60-90%, comes from the project description and the README's command table. The table lists `cargo test` at 99.2%, `go test ./...` at 97.1%, `git log` at 85.7%, `git status` at 85.7% and `git diff` at 81.4%. Those are per-command figures from the project's own measurements, not a guarantee about your repository.

The limitation is structural. A filter that rewrites `git diff` down to 66 tokens is making an editorial decision about which parts of a diff matter. If your agent is debugging a subtle whitespace change or a large rename, the filtered diff may have dropped exactly the hunk it needed. The README does not document a per-invocation bypass flag, a way to see the raw output alongside the filtered output for a single command, or a rollback path for a filter that turns out to be too aggressive. The repository does contain an `internal/tee` package and an `internal/inspect` package, which suggests both raw-output capture and filter inspection exist somewhere in the codebase, but the README does not explain how a user reaches them.

There is also a portability question the README leaves open. The filter for `go test` injects `-json`, which changes the command that actually runs. Any filter that injects flags is coupling snip to a specific tool version's flag surface. When the upstream tool changes its JSON schema, the filter has to change with it, and the README does not describe how that breakage would surface to the user.

How snip differs from rtk

The repository topics include `rtk-alternative`, and the project description calls snip an rtk alternative in Go. The difference in approach is the extension model. snip's filters are YAML files that live in a `filters/` directory and are loaded at runtime, so a user can add coverage for an in-house command without touching Go code. A compiled-filter approach requires a rebuild and a release to do the same thing.

The second difference is distribution. snip ships as a single static binary: the Makefile builds with `CGO_ENABLED=0`, and the SQLite dependency is `modernc.org/sqlite`, a pure-Go implementation, rather than a cgo binding. That is what makes `brew install` and the release tarballs viable without a C toolchain on the user's machine.

The trade-off is that YAML filters cannot express arbitrary logic. Anything that needs real parsing, such as the JSON test counting in the `go test` filter, has to be built into the engine rather than written by a user in YAML. The README does not describe the full set of operations a filter can perform, so it is hard to tell from the documentation where the YAML boundary sits.

Maintenance, releases and the MIT licence

The last push to master was on 2026-09-12, and the most recent release, v0.25.2, was tagged the same day. v0.25.1 landed on 2026-09-03 and v0.25.0 on 2026-08-28. Three releases in roughly two weeks is a fast cadence, and the version numbers suggest the project is still adding surface area rather than stabilising.

That cadence cuts both ways. Filter definitions are coupled to the output formats of the tools they filter, so frequent releases are appropriate for a project whose correctness depends on external tools. It also means pinning a version and reading the release notes before upgrading is reasonable, since a filter change can alter what your agent sees without any change on your side.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is permissive enough for most internal tooling. It says nothing about the licence of the commands snip wraps or the output it processes, and it does not address whether filtered output affects any compliance obligation you have to retain command logs. The repository has a SECURITY.md, so there is a stated channel for reporting problems, but no security review is claimed anywhere in the README.

Upgrade cost is low in the common case: `brew upgrade` or `make upgrade` replaces the binary resolved on `PATH`. The Makefile notes that an explicit `GOBIN` overrides the upgrade destination, which is the one place where an upgrade can silently install somewhere you did not expect.

Editorial conclusion

snip is worth adopting if your agent runs noisy commands such as go test, cargo test or git log and you want the token reduction without changing the agent itself. It is the wrong tool if your agent does not execute shell commands, or if you rely on full command output for debugging and cannot tolerate a filter rewriting it. Before rolling it out, run snip verify so the YAML filters are actually exercised, then check that the filtered form of your most common command still contains the failure lines your agent needs.

Frequently asked questions

Official sources

1. edouard-claude/snip on GitHub
2. License: MIT
3. Project website
4. README
5. Releases