trim-1: a 1.2 MB model that keeps only the lines an agent needs

The problem

Agents read logs, tool results and long documents in full. The first image in the README shows an example. An agent reads a whole log to find one error. Every line that an agent reads costs tokens and fills the context window sooner.

Claude Code, a coding agentcoding agentAn AI program that reads and edits code and runs commands for a developer. Claude Code and Codex are examples., handles the same problem in two ways. Its documentation says that it summarizes earlier history to free space when a conversation nears the context limit. You can say what to preserve, but the summary can still lose details of the original. Compacting is itself a large request. The documentation also gives a hookhookA script registered to run automatically at a set moment. Git, for example, runs hooks right before a commit or a push. that filters a log with grep ERROR before passing it on. That needs no model call. The filter drops the answer if its line lacks the keyword. The maker's READMEs compare trim-1 with summarizing and with | tail -20.

How it solves it

trim-1 only removes lines. It splits the context into lines and scores each line for relevance to the current query. It drops the lines that score below a threshold. Kept lines are the original text in the original order, and a marker line such as "… 25 lines …" stands where lines were removed. The README says that the library returns the input unchanged when the query is empty. trim-1 also returns the input unchanged when the input is under 2,000 bytes or the cut would save less than 10%.

What is different

trim-1 scores the lines with 712 decision trees, not a neural network. The model card says that trim-1 compares each line with the query and computes 67 numeric features. They include lexical matches such as BM25 and query-term coverage. Other features are the kind of line (error, test result, path, heading, stack frame), position, length, indent and the scores of neighbouring lines. Because the model uses trees, it is 1.2 MB and finishes in milliseconds on one CPU core. It is also deterministic. The model card also says that trim-1 works on whole lines, so it cannot shorten a long line. It drops later evidence that shares no words with the query. It was trained on English only. The default setting cuts only 1.9% from short, dense coding-agent tool outputs. The intended use is long-document retrieval. For that use, the card reports that it removes 88.9% of tokens and keeps the evidence in 94.4% of cases.

How it was built

• The repository has four commits from 2026-10-13 and 2026-10-14. Two of them list Claude Opus 5.5 in a Co-authored-by trailer. One pull request from an outside contributor caps the input size to prevent exhausting memory.
• 1,788 lines of Go. features.go computes the features. model.go evaluates the trees and embeds model.bin with go:embed. There are two tests: a bit-for-bit parity check against the training library's predictions, and a golden-output test on a sample log.
• The maker, Julius Brussee, also makes Caveman, a tool that reduces an agent's token use. trim-1 is the model inside Caveman. The model card on Hugging Face is tagged LightGBM.
• The model card says that all training data is public and licensed for commercial use. The benchmark numbers come from a single run.

Running it

1. Build and tests. go build finished in 9.7 seconds and the binary is 4.2 MB. The dependency list contains only this module and the standard library. The two tests passed in 0.166 seconds. The model file's header lists 67 features and 712 trees.
2. 41 KB of code. I combined this site's ten scripts into one file and queried it with "how are visits fetched from Vercel analytics". 785 of 1,092 lines were removed, and 14 KB remained. The analytics script's API address and token variable were kept.
3. 35 KB of HN threads. I queried a thread dump with "did the PS2 recompiler use AI generated code". At the default setting it could not save 10%, so nothing was removed (unchanged). The aggressive setting removed 93 of 150 lines and returned 15 KB.
4. Comparing outputs. I compared both outputs with their inputs line by line. Every output line except the markers was an input line, in the same order. Four runs of the same command gave the same hash.
5. Small input and output fed back in. A 1,800-byte log came back unchanged with a note about its size. When I fed an output back in, it also came back unchanged.
6. Blank query. This is the one case that differed from the README. The README says that the library returns the input unchanged. With --query "", the CLI exited with code 2. It printed only the usage text and left stdout empty. A pipeline that redirects stdout gets an empty file.
7. Timing. The 35 KB input took 23–34 ms. I also joined seven copies of the thread dump into a 245 KB input, and it took 94–121 ms. Both times include process start. The model card's 7.2 ms for 5,000 tokens was measured in-process. That is a different method.

$ trim --query "how are visits fetched from Vercel analytics" scripts.txt
trim: kept 307 lines, removed 785, 41396 -> 14462 bytes
$ trim --query "did the PS2 recompiler use AI generated code" hn-threads.txt
trim: unchanged (cut below the minimum)
$ trim --query "" hn-threads.txt; echo exit=$?
usage: trim --query QUERY [--point POINT] [FILE]   (reads stdin without FILE)
exit=2

Not checked

• The model card's benchmark numbers. No long document was tried, so the 88.9% and 94.4% could not be confirmed.
• The effect inside a real agent loop. The next step is to read the Caveman repository and find where it calls trim-1.
• Korean input. The card says English only, so no Korean log was tried.

Verdict

It works. One query cut 41 KB of code by 65% and kept the lines that held the answer. On the HN thread dump, though, the default setting removed nothing. It is worth a try when an agent reads long logs or documents in full and the original text has to stay unchanged. If the goal is to shrink short, dense contexts such as tool outputs, this product is not the right choice. The model card itself puts the saving there at 2%.

What to take away

• If an agent has to read a long context, try deleting the unneeded lines before summarizing it. Today every line of trim-1's output except the markers was an input line.
• Check that a small model is deterministic before adopting it. Four runs of the same command gave the same sha256.
• Make the blank-query behaviour the same in the library and the CLI. The CLI exited with code 2 and left stdout empty for a blank query.
• Decide what a tool does when fed its own output. trim-1 left input containing its own markers unchanged.