Compact git output

git status and git diff are among the most-run commands in any coding session, and among the noisiest. Every run pushes a wall of text into the context window - untracked files, unchanged hunks, branch chatter - most of which the agent does not need. banish compacts that output before it reaches Claude Code, Cursor, or any MCP agent.

The problem - git output is verbose

A plain git status in a working repository can run to a couple of hundred tokens, most of it structure the model can infer. git diff is worse: full context lines around every change, repeated for every file. Multiply that by the number of times an agent checks state during a task and git alone can account for a large share of a session's tokens.

Before and after with banish

banish rewrites git status to banish git status, runs the real command, and pipes the output through the git filter:

$ banish git status
  -> filter: git  -> 12 tokens

The measured savings on a fixed corpus:

Token counts vary with repository state - a busy repository saves more in absolute terms. See the methodology for how these are measured and how to reproduce them.

How the git filter works

The git filter keeps the parts that carry meaning - which files changed and how - and drops the boilerplate. It is one of the filters banish ships with out of the box; see built-in filters for the full set and the directives each one uses. Because it compacts rather than truncates, you never lose a changed path. If the filter fails, banish returns the raw output.

Write your own for another command

The same approach works for any noisy command. The .bsh language lets you define a filter for a new command in about ten lines - no recompile, no plugin system. Drop it in ~/.banish/ext and the command is compacted the next time your agent runs it.