caveman-ai/trim-1

trim-1 is worth a look if you run an agent over logs or long documents and want a cheap, local way to cut context before it reaches the model. Treat it as a focused line filter, not a general summarizer.

The problem

An agent asked "why does the build fail" often gets a whole build log dumped into its context, then has to find one error among thousands of lines. Reading everything costs tokens and attention. trim-1 changes that step: you pass the raw context and the current query, and get back the same lines in their original order with gaps marked where lines were dropped. Identifiers, paths and error text survive untouched because nothing is rewritten.

What's different

This is not a neural network. It is 712 gradient-boosted trees packaged as a 1.2 MB Go program with the model embedded, standard library only. That makes it deterministic and local: no GPU, no network call, the same input always gives the same output, and inference is reported in milliseconds per few thousand tokens on one core. In practice, a pipeline can call it per tool result without a service to operate.

The blunt trade-off is scope. Each removed line is information the downstream model can no longer read, and the author says cutting harder costs quality. For long-document retrieval the tool is aimed at balanced; for coding-agent tool outputs, which are short and dense, it stays at balanced or conservative and savings are modest. It also refuses to act on small or already-processed inputs: blank queries, contexts under 2,000 bytes, over 8 MiB or 200,000 lines, contexts with an existing removal marker, and cuts that would remove less than 10% of bytes all pass through unchanged with a stderr reason. That fail-closed behavior keeps failures predictable, but it means some invocations produce no savings at all. The author's benchmark numbers live in the model card, so quality claims depend on that evidence rather than on a usability assessment.

Who should try it

Good fit: someone building a Go-based agent or ingestion step that regularly sends large logs or documents to a model, who wants a self-contained filter with no extra runtime. You can call Compress directly, or use Score to get per-line keep probabilities and make your own selection, which suits teams that want to tune the policy themselves. Poor fit: workloads dominated by short tool outputs, where the documented expectation is small savings, and non-Go environments, since the install path assumes Go 1.23 or newer from the project instructions. If your pipeline already relies on model-side summarization, this addresses a different problem: exact line retention rather than compression by rewriting.

Requirements and limitations

You need Go 1.23 or newer to install the CLI or import the library; the README gives no other interface, so other languages would need to shell out to the binary. The size limits (2,000 bytes to 8 MiB, 200,000 lines) define the useful range, and the pass-through rules mean silent-looking no-ops that you must handle by reading stderr. Determinism and no dependencies make operation simple, but the model is fixed: improving selection means a new model release rather than local tuning, and there is no documented way to retrain it from this repository. The marker check also means trim-1 output should not be fed back into itself as input.

HotRepo's take

The repository was 11 days old with 188 total stars when HotRepo recorded it at #19 on the NEW-REPOSITORY board (新项目榜) on 2026-10-25; the supplied sample covers only 2026-10-24 to 2026-10-25, so persistence cannot yet be judged. Before adopting, check the model card's benchmark methodology and whether its test inputs resemble your own contexts, since the README's savings guidance is the only signal on expected output.