# Compact kubectl output


# 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:

| Command | Raw tokens | Compacted | Saved |
| --- | --- | --- | --- |
| kubectl get pods (20 pods) | 399 | 305 | 24 percent |

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](/docs/reference/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](/docs/reference/built-in-filters) for the
full set.

## Write your own for another command

The same approach works for any noisy command. The [.bsh language](/docs/concepts/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](/docs/getting-started/set-up-an-agent).