Output Filtering: Trim Command Logs for Agents

What is output filtering for AI coding agents?

Output filtering is the practice of trimming a tool's or command's output down to the lines that matter before it ever reaches the model's context window. When your agent runs npm install, cargo build, pytest, or terraform plan, the command spews hundreds of lines of progress bars, dependency trees, and deprecation warnings — and by default every one of those lines becomes tokens the model has to read, on this turn and every turn after, while the log lingers in the transcript. I spend a lot of my time staring at token bills, and command output is the one line item that surprises people most. They obsess over the size of the files the agent reads, then run a single pnpm install and pipe 4,000 lines of "resolved / downloaded / linked" straight into a frontier model at frontier-model prices. The agent doesn't need the resolution log. It needs to know whether the install succeeded and, if not, which package broke. Output filtering is how you give it exactly that and nothing else. This is part of the broader discipline of context engineering — deciding what the model sees, in what shape, and in what order. Command output is one of its least-loved corners, which is precisely why there's so much waste to recover there.

Why do command logs cost so much in an agentic loop?

Command logs cost so much because they are re-sent on every subsequent turn, not just the one where the command ran. This is the part people miss. In a one-shot chat, a noisy log costs you once. In an agentic coding loop, the agent keeps the command output in its transcript so it can "remember" what happened, and that transcript is re-submitted as input on each new turn until something compacts or evicts it. A 3,000-token build log isn't a 3,000-token cost. Across ten more turns of the same session, it's closer to 30,000 tokens of input you paid for to tell the model the same thing thirty times. Now price it. On Claude Opus 4.8, input runs $5 per million tokens and output $25; on Sonnet 4.6 it's $3 / $15; on Haiku 4.5, $1 / $5; GPT-5.5 sits at $5 / $30 (Anthropic pricing, OpenAI pricing, 2026). Prompt caching softens the blow — a cache read is roughly 10% of the input rate — but caching only helps when the prefix is stable, and a fresh, verbose command log is a brand-new suffix that hasn't been cached yet. The first time the model reads that log, you pay full freight. There's a second, subtler tax. Models attend least to content stranded in the middle of a long window — the "Lost in the Middle" effect documented by Liu et al. (2023, arxiv.org/abs/2307.03172). A wall of dependency-resolution lines doesn't just cost money; it pushes the one line that mattered — the actual error — into the low-attention zone where the model is most likely to skim past it. Filtering the noise raises the signal-to-noise ratio and makes the model more accurate, not just cheaper.

What does output filtering actually remove?

Output filtering removes the lines that carry no decision-relevant information, while preserving every line the agent needs to choose its next action. In practice that means three buckets. Pure progress noise. Download bars, spinners, percentage counters, "resolving…", "linking…", repeated \r carriage-return redraws. None of it survives to influence a decision; all of it costs tokens. This is the easiest, safest thing to drop. Deduplicated repetition. Test runners, linters, and type checkers love to print the same warning 200 times — once per file. The model needs to know the warning exists and roughly how often, not to read 200 identical copies. Collapsing "this line repeated 200×" into a single line plus a count keeps the signal and discards the redundancy. Bulk success boilerplate. When cargo build finishes with Finished dev [unoptimized] in 14.2s and 600 lines of green "Compiling" above it, the agent only needs the verdict and any warnings. On success, the body of the log is noise; on failure, you keep the error and its surrounding context. What output filtering must never remove is the failure payload: the error message, the stack frame, the failing assertion, the offending package name, the diff that didn't apply. The whole point is to be ruthless with noise and conservative with signal. A filter that drops a real error to save tokens is worse than no filter at all — it makes the agent flail blindly and burn far more tokens recovering than it ever saved. See output filtering for the canonical definition.

How do you apply output filtering today?

You apply output filtering by intercepting command output between the shell and the model, then summarizing or compacting it before it enters the context. Here's the practical sequence I use.

Identify your loudest commands. They're predictable: package installs (npm, pnpm, pip, cargo), builds, full test suites, git status/git log on busy repos, kubectl, terraform plan, docker build. These produce the bulk of the noise.
Decide the verdict-plus-detail shape. For each, the useful output is "did it pass?" plus "if not, what's the smallest log slice that explains the failure?" Design your filter to emit exactly that.
Strip the obvious noise first. Carriage-return redraws, ANSI color codes, progress percentages, and timestamps on every line are pure overhead. Removing them alone often cuts a log by half.
Deduplicate repeated lines with a count, and truncate long success bodies to head + tail + summary. Keep failures intact.
Measure before and after. This is non-negotiable. Pipe a real build through your filter, count tokens on both versions, and confirm the model still answers correctly. If you don't measure, you're guessing — and guessing is how you accidentally delete the one error line that mattered.

If hand-rolling shell wrappers and tuning regexes for terraform versus cargo versus pytest sounds like a side quest you don't want, that's the gap Tokenade fills: it sits between your agent and its tools, applies output filtering (alongside semantic code search, skeleton compression, and lazy MCP loading) automatically, and shows you the saved tokens on a dashboard so the "measure before and after" step is done for you. It works with Claude Code, Cursor, Codex, Copilot, and Windsurf, it's source-available under MIT so you can read exactly what it strips, and the free tier covers up to roughly 10M tokens a month before Pro ($19.90/mo excl. tax in the US, €19.90/mo incl. tax in France, unlimited machines).

How much can output filtering actually save?

Output filtering's savings scale with how loud your commands are and how long your sessions run — the noisier the command and the longer it stays in the transcript, the more you recover. The mechanism is simple multiplication: tokens removed × turns the log would have survived × your input rate. A concrete way to think about it. Say a single pnpm install log is 3,000 tokens of mostly noise that compresses to 200 tokens (the verdict plus any warnings). That's 2,800 tokens saved on the turn it ran. If the session continues for ten more turns with that log in the transcript, and you're on Opus 4.8 input at $5 per million, you've avoided re-sending 28,000 tokens — about 14 cents from one install. Do that across a day of installs, builds, and test runs and it compounds into real money. I'm deliberately not quoting a headline "X% cheaper" figure here, because the honest answer is "it depends on your command mix" — the only number that matters is the one you measure on your own logs. Output filtering also stacks with the other token levers rather than competing with them. Trimming what files the agent reads is one axis; trimming what command output it reads is an orthogonal one. Pull both and the effect multiplies. For the full set of levers and where this one fits, see How to reduce Claude Code token usage.

What goes wrong with output filtering (anti-patterns)?

The failure modes are predictable, and every one of them comes from being too aggressive instead of too cautious. Dropping the error to save the token. The cardinal sin. A filter tuned for maximum compression that swallows the stack trace turns a debuggable failure into a mystery. The agent then re-runs the command, re-reads a now-different log, and spirals — spending more tokens than the filter ever saved. Always preserve failure payloads in full. Filtering interactive or streaming output. Some commands expect a TTY or stream tokens the agent needs in real time. Blindly buffering and summarizing those breaks them. Filter batch command output; leave genuinely interactive flows alone. Compressing already-tiny output. Wrapping a 12-line git status in a filtering layer adds latency and complexity for no token win. Reserve filtering for the genuinely noisy commands; a good filter is a no-op on short output. Filtering without measuring. If you can't see how many tokens went in versus out, you can't tell a working filter from one that's silently mangling logs. Instrument it. A token counter on both sides of the filter is the minimum bar, and a running savings dashboard is what turns "I think this helps" into "this saved 4.2M tokens this week." Output filtering isn't glamorous. It's plumbing. But it's plumbing that sits directly on the most over-paid line item in agentic coding, and that makes it one of the highest-leverage habits a heavy agent user can build.

See also: