Abbreviatory Launches as an Open Source Tool That Cuts Test Runs and Logs Down to What Matters

Abbreviatory v0.1.0 is out. It’s a small command-line tool that takes a big pile of tool output, a test run, a build log, a JSON response, and turns it into a short report that keeps the failures, errors and warnings. It’s open source under the Apache License 2.0 and comes as a single static binary for Linux, macOS and Windows.

The problem is familiar to anyone who has scrolled a CI log. Thousands of lines say everything went fine. A few say it didn’t. People skim past the noise and sometimes past the answer. Coding agents read the whole thing every time they run the tests, and every line costs them time and money.

Abbreviatory reads the output, recognises its format and folds it. Repeats become one line with a count. Passing tests are counted, not listed. Failures and errors come first, with their messages and stack traces. The whole report fits a byte budget you set, 4 kB unless you say otherwise.

Nothing Is Thrown Away

Every line the report leaves out sits behind a reference such as [ref d2f86a61aa96:g10]. Run abbreviatory expand on it and you get the original lines back, byte for byte. The original input is kept gzipped on your own disk for a week. So the report can be short without being a dead end: if the summary line isn’t enough, the real thing is one command away.

That’s the main difference from asking a language model for a summary. A model’s summary can drop the line that mattered, and nothing tells you. Abbreviatory only removes what its rules say is safe to remove, says how much it removed, and keeps a way back to all of it. Same input, same report, every time.

What It Reads Today

go test, plain or -json. pytest, verbose or not. JUnit XML, which Jest, Maven, Gradle and most CI tools can write. Application logs of the usual shapes, with Java stack traces, Python tracebacks and Go panics kept together. JSON documents, outlined as valid JSON with long arrays cut down to their shape and every element that carries an error. Anything else is read as a log.

How It Was Tested

The project makes four promises: the report never goes over the budget, nothing important is lost, the output is the same every time, and every reference expands back exactly. Tests check all four on every fixture, at budgets from 256 bytes to 16 kB, on every push. The fixtures are real go test and pytest runs plus a generated log and API response. How it was tested has the numbers.

What It Doesn’t Do Yet

It’s v0.1.0. It reads formats it knows and can’t judge free prose. It doesn’t compare runs yet. The full list is on the reference page.

Where It Goes

The next release is the one the project is really about: comparing a run with the last one. Three new failures, two fixed, one failing for four runs in a row, instead of the same 5,000 lines again. After that come an HTTP service and an MCP server, and more formats.

Download it, try the quick start, and tell us what it got wrong.