jfrog/boost: Token Savings for Coding Agents and Shell Commands

The problem Boost targets: scrollback that eats the context window

Coding agents run shell commands constantly. A package install, a test suite, a Docker build. Each of those commands returns far more text than the agent needs to decide what to do next. The README uses npm ci as its example: roughly 9,800 tokens of install noise, of which almost all is deprecation warnings and progress lines. The useful part is a package count and a vulnerability count.

Boost's job is to sit between the agent and the shell and return only that useful part. The README describes it as wrapping "the commands your agents already run, turning noisy logs into compact, structured context that keeps the signal (errors, timings, changed counts, cache hits) while cutting the noise." The intended audience is anyone running long agent sessions, noisy test and build loops, or CI pipelines where job logs are read by humans or by agents.

How the filtering works: command-aware rules, not truncation

The distinction Boost draws is between truncation and filtering. Cutting the tail off a log saves tokens but can delete the failure the agent needed. Boost instead applies command-aware filters, which means the compression rule is tied to the command being run. The README states plainly: "Boost does not just truncate output. It applies command-aware filters that preserve what agents need to reason about the result."

The same example shows the shape of the output. A plain npm ci produces a deprecation-heavy log and the line "added 1285 packages, audited 1286 in 45s". Under Boost the agent sees a single summary line with the package count, the cache source and the vulnerability count. On failures, the README says Boost keeps the failing test, compiler error or stack frame that matters, so the compression is conditional on success.

Two further mechanisms appear in the README's comparison table: versioned retrieval feedback and auto-disable of repeatedly retrieved filters. The table states that Boost supports both and that the three tools it compares against (RTK, Headroom and Caveman) do not. The README does not document the exact algorithm behind either, so treat the table as a capability claim rather than a specification. Custom and internal CLIs are covered by TOML filters, which the README lists as the way to extend compression to tools Boost does not ship rules for.

Installing Boost and wiring it into an agent

The README gives two install paths. On macOS, Linux and Windows WSL it is a shell script piped to bash:

curl -fsSL https://boost.jfrog.com/install.sh | bash

On Windows PowerShell the equivalent is:

irm https://boost.jfrog.com/install.ps1 | iex

Both fetch from boost.jfrog.com. The repository also contains install.sh and install.ps1 at the top level, which is consistent with those being the same scripts, though the README only documents the hosted URLs.

After installing, the next step is to wire Boost into the agents you use. The README names Cursor, Claude Code, GitHub Copilot and Codex CLI:

boost init

The README does not describe what boost init writes or where. It does point agent-driven installs at AGENT-INSTALL.md, which is a top-level file in the repository, so that is the place to look if a coding agent is installing Boost on a user's machine rather than a human doing it.

The first real use is to prefix a command you would run anyway:

boost npm ci

According to the README example, the output collapses to a line like "[OK] npm ci · 1,285 packages restored from boost cache in 2.4s · 0 vulnerabilities". The cache mention is worth noting: the example implies Boost can serve a repeat install from its own cache, which is a different mechanism from output compression and is not explained further in the README.

To see what was saved, run the report:

boost report

The README shows an interactive web dashboard with context tokens saved over time, a CLI filter breakdown and a Code Base Exploration breakdown. A terminal summary is available with boost report -t.

Where Boost is the wrong tool

The comparison table is the clearest statement of a boundary. Assistant reply compression is marked as supported by Caveman and not by Boost, RTK or Headroom. If your token problem is the model writing long answers rather than the shell producing long logs, Boost does not address it. That is a real gap, not a rounding error, and the README is explicit about it.

The preview status is the second constraint. The README carries a Preview Notice pointing at JFrog's Online Preview Agreement, and the repository's licence field resolves to NOASSERTION. That combination means you should read the agreement and the LICENSE file before putting this in a pipeline you depend on. The README does not document rollback, so if boost init changes agent configuration, the repository does not tell you how to undo it.

The README also does not state which commands have built-in filters. It names npm test, pytest, go test, docker build and linters as examples in the "When to use Boost" list, and describes TOML filters for custom CLIs, but there is no published filter inventory in the README. If your stack is mostly internal tooling, expect to write and maintain those filters yourself.

One more caveat sits in the comparison table itself: the row "Native approval sees original executable" is marked as supported by Boost and unsupported by RTK, with a dash for Headroom and Caveman. A dash is not a yes or a no, so that row tells you less than the checkmarks around it.

How Boost differs from RTK, Headroom and Caveman

The README positions Boost against three named tools, and the differences are structural rather than cosmetic. RTK and Headroom both compress command output, and Headroom also does full-context and RAG compression. Boost covers both of those rows as well. Where Boost claims separation is in the operational feedback loop: versioned retrieval feedback, auto-disable of repeatedly retrieved filters, and an end-to-end agent task plus cost A/B. None of the three alternatives are marked as supporting those.

Caveman is the odd one out. It does not compress command output at all, and it is the only one of the four that compresses assistant replies. So Caveman and Boost are not substitutes; they act on opposite ends of the same conversation, and the README's table implies you could in principle want both.

The honest reading is that the table is Boost's own framing, published by the project, and the README gives no methodology for how the comparison was produced. The Terminal-Bench 2.0 benchmark link is the closest thing to evidence, and it is a blog post on boost.jfrog.com rather than a reproducible harness in the repository.

Maintenance, releases and licence status

The repository is not archived, and the last push was on 2026-09-10, the same day v0.13.15 was released. The two prior releases, v0.13.14 and v0.13.13, landed on 2026-09-09 and 2026-09-08. Three releases in three days is a fast cadence, which is what you would expect from a preview product but also means you should pin a version rather than track main.

The repository ships a versions.json at the top level, which suggests the installer resolves versions from that file rather than always taking the newest build. The README does not document how to pin or roll back, so if reproducibility matters to you, inspect versions.json and install.sh before relying on the curl one-liner in CI.

The licence field resolves to NOASSERTION, meaning GitHub could not map the LICENSE file to a known identifier. The README also points at BETA_AGREEMENT.md and the Online Preview Agreement on boost.jfrog.com. Those two documents, not the README, will govern what you may do with the software. Read them directly; this is a description of what the repository contains, not legal advice.

Boost is sponsored by JFrog and the README notes that dependencies, source, secrets and IaC are scanned on every push to main, with SECURITY.md covering the scope. That is a supply-chain signal about the repository, not a statement about the compressed output your agent receives.

What a boost report actually shows you

The report is the part of Boost that is easiest to evaluate, because it either shows savings on your commands or it does not. The README's dashboard screenshot is captioned as showing context tokens saved over time with a CLI filter breakdown and a Code Base Exploration breakdown. The terminal variant, boost report -t, gives a narrative summary instead.

For a team deciding whether to adopt this, the report is the test. Install Boost, run boost init, work normally for a session, then run boost report and look at whether the filters fired on the commands you actually use. If your commands are not in the built-in set and you have not written TOML filters, the report will show little, and that is the answer.

The README's cost claim is around 12% lower cost at an identical task pass rate, from the Terminal-Bench 2.0 benchmark. That number comes from the project's own benchmark, not from an independent run, and the README does not break it down per command. Treat it as the project's claim and measure your own baseline.

Editorial conclusion

Adopt Boost if your coding agent burns context on repetitive shell output such as test runs, builds and installs, and you want a measurable report of what was saved. Do not adopt it if you need assistant reply compression, since the README's comparison table marks that capability as absent, or if you cannot accept preview terms. Before rolling it out, verify that boost init wires your specific agent correctly, run boost report after a real session to see whether the filters fire on your commands, and read the Online Preview Agreement and the NOASSERTION licence status.

Frequently asked questions

Official sources

1. Issues
2. jfrog/boost on GitHub
3. Project website
4. README
5. Releases