What Context Reduction Is and Why Abbreviatory Does It Without a Language Model

Context is whatever a reader has in front of them when they decide what to do next. For a person, it’s the terminal. For a coding agent, it’s the text that goes into the model on its next turn. Either way it’s limited, and most of what tools print is filler.

Context reduction is cutting that down before it reaches the reader, without losing anything they need. A test run of 5,000 lines, of which 4,950 say “ok”, becomes the 50 that don’t, plus a count of the rest. A log where one warning repeats 2,000 times shows it once, with “x1952” in front.

Abbreviatory does this in five steps. It detects the format, reads it into records (a test result, a log line with its stack trace), groups records that are the same event repeated, keeps the ones its rules say matter, and fits the result into a byte budget.

Why Not Ask a Model

You could hand the output to a language model and ask for a summary. Sometimes that’s the right call, for prose especially. For tool output it has three problems.

It can’t be checked. A summary doesn’t list what it dropped, so when it misses the one failing assertion you find out later, the hard way.

It isn’t repeatable. Ask twice and you may get two summaries. That’s a poor fit for CI, where the same run should give the same answer.

And it costs the thing you were trying to save. Summarising 10,000 lines with a model means sending 10,000 lines to a model.

Abbreviatory uses rules instead. They’re boring on purpose. A line with ERROR near its start is an error. Two lines that differ only in their numbers are the same event. A failed test keeps its message. You can read the rules, and you can predict what they’ll do.

What Grouping Means

Logs repeat. The same warning, the same health check, the same retried request, thousands of times with only the timestamp and an ID changing. Abbreviatory compares lines with their numbers, hex IDs, addresses and spacing set aside. Lines that match are one group. The report shows the first one as it was, with a count.

Stack traces stay with the line they belong to. So the same error with two different traces counts as two groups, which is usually what you want: two different code paths failing the same way.

What the Budget Means

The budget is a hard ceiling in bytes. The report never goes over it. If the failures alone don’t fit, the ones that don’t get counted on a “not shown” line, with a reference that brings them back. If even the header and the counts don’t fit, Abbreviatory says so and stops, rather than quietly breaking the limit.

Inside the budget, failures and errors get their one line first. Then their messages are shared out in rounds, so every failure shows a little before any shows a lot.

What References Mean

This is the part that makes the rest safe. When Abbreviatory reduces something, it keeps the original on your disk, gzipped, and every line it leaves out gets a reference. abbreviatory expand d2f86a61aa96:g10 prints the 486 original lines behind one grouped error. :fail prints every failed test. :L200-260 prints a range. Nothing is lost. It’s just not in the way.

For a coding agent this works like progressive disclosure. It reads the short report first, and asks for the details of one failure only when it needs them.

What It Can’t Do

It reads formats it knows: test runners, logs, JSON. Free prose gets only the basics, repeats folded and level words found. Telling which sentence of a design document matters is a job for a person or a model, and Abbreviatory doesn’t pretend otherwise.