Your build log is 40,000 lines. Your agent's context window is not.

Your build log is 40,000 lines. Your agent's context window is not.

Every time my build failed, I did the same thing: copy the whole log,
paste it to my agent, and watch it burn half its context on progress
spam before it ever reached the actual error. head -100 cuts the
error at the end. tail -100 cuts the setup at the start. grep -i
error cuts everything that explains why the error happened.

So I built a tiny tool that sits in a pipe and keeps all three:
logtrim.

What it does

One command shrinks verbose logs and tool output down to a token
budget — keeping the beginning, the end, and every error line, while
collapsing the repetitive middle into one-line markers that say what
was dropped.

set -o pipefail
npm run build 2>&1 | logtrim --budget 1500

How it trims:

1. Collapse blank runs — 5 blank lines become 1.
2. Collapse identical runs — 8 copies of the same warning become 2 copies plus ... [6 identical lines omitted] ....
3. Collapse similar runs — 12 Processed N/1000 records lines become 2 plus ... [10 similar lines omitted] .... "Similar" means the same shape with only numbers differing. Error lines are never collapsed this way.
4. Truncate absurdly long lines — a 3 KB single-line JSON blob gets cut to --max-line chars with a note.
5. If still over budget — keep head + error lines + tail, drop the middle, and mark each gap. Middle lines go first so the start and end survive.
6. Last resort — if error lines alone exceed the budget, they are truncated to share it. Output never exceeds the budget.

Token counts are estimates (characters / 4). Accurate enough to decide
what to keep, and it keeps the tool dependency-free.

Demo

The repo ships a 62-line build log full of progress spam, repeated
warnings, and one real failure:

node bin/logtrim.js examples/sample.log --stats --budget 300

Result: 62 → 23 lines, 715 → 251 tokens — and the two errors, the
stack trace, and the start of the log all survive. With the default
budget (2000 tokens) the same file goes to 48 lines / 559 tokens,
dropping only the collapsed repeats.

Try it

git clone https://github.com/techdevfun/logtrim.git
cd logtrim
npm link   # makes `logtrim` available everywhere

# Trim a failing build before pasting it to your agent
set -o pipefail
npm run build 2>&1 | logtrim --budget 1500

# Trim a saved log file, see what was cut
logtrim --budget 800 --stats deploy.log

Zero dependencies, plain Node.js 18+. Tests + CI included.

Repo: https://github.com/techdevfun/logtrim

If you try it on a real log and it drops something it shouldn't have,
open an issue — that's the feedback that shapes what gets built next.

Comments

[lastmileops]

I'd put set -o pipefail above the build example if it's going into a Bash CI step. A failed build can look successful when logtrim exits 0 and Bash reports the last command's status. To check the example, swap in a command that prints one line and exits 1, then verify the pipeline exits nonzero.

[TECHDEV]

Good catch — you're right. Without set -o pipefail, a failing build piped through logtrim exits 0, so CI goes green on a broken build. That's exactly the kind of silent failure logtrim exists to surface, so the example as written is a footgun in a CI step — fine at an interactive prompt, risky pasted into CI.

Your test is the right way to prove it, too: a command that prints one line and exits 1 makes the masking obvious in seconds. Thanks for flagging it — this one's going on the list against the example.

Did you hit this on a real pipeline, or spot it reading the snippet?

[lastmileops]

I spotted it reading the snippet, then checked the Bash behavior locally with false | cat. Thanks for updating both examples.

[TECHDEV]

Thanks for checking it locally — false | cat is a neat minimal repro, and good to hear the updated examples read right now. If anything else in the snippets looks off when you run them, say so — that kind of close reading is exactly what keeps the examples honest.

[TECHDEV]

Done — the example now carries set -o pipefail above the pipeline, in the article (both places it appeared) and in the logtrim README: github.com/techdevfun/logtrim/comm...

Thanks again for catching it — if you spot anything else in the examples, say so.