Compact kubectl output

kubectl output is already structured, so the problem is not format - it is size. A kubectl get pods table carries columns the agent did not ask for, and the same data as JSON can be two to three times more tokens again. On a large cluster that adds up fast. banish trims that output before it reaches Claude Code, Cursor, or any MCP agent.

The problem - more tokens than the answer needs

Because kubectl output is a wide table or valid JSON, it is already parseable - the model does not struggle to read it. What it does is spend tokens: full timestamps, columns the agent did not ask for, and repeated structure, multiplied by every object in the list. The bigger the cluster, the larger the bill for the same answer.

Before and after with banish

banish runs the real command and pipes the output through the kube filter:

The default get pods table is already dense, so the saving here is smaller than on log-style commands - but it grows with the object count. See the full spread on the benchmarks page, reproducible with banish bench.

How the kube filter works

The kube filter ships with banish and compacts kubectl get, describe, and logs. On get it trims each row to a readable width and caps very long lists; on describe it drops the empty labels and annotations; on logs it keeps the most recent lines. If a filter fails, banish returns the raw output rather than swallowing it. See built-in filters for the full set.

Write your own for another command

The same approach works for any noisy command. The .bsh language lets you define a filter in about ten lines - no recompile. To start compacting kubectl output in your own agent, set up an agent.