# boost wraps the shell commands your agent already runs and compresses the output

> A JFrog sponsored shell and Go project that sits between your coding agent and npm, pytest, docker build and git, keeping errors, timings, counts and cache hits while dropping scrollback. It is still labelled preview, and the comparison table shows exactly which features are unique to it.

**jfrog/boost** — Save tokens. Maximize context, Safely

- Repository: https://github.com/jfrog/boost
- Website: https://boost.jfrog.com/
- Stars: 515 · Forks: 23
- Language: Shell
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/jfrog-boost

## Install is a curl pipe, and Windows gets a PowerShell twin

There are two installers and they are one line each. On macOS, Linux and Windows under WSL:

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

On Windows PowerShell the equivalent is:

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

Wiring it into your tools is a second command:

```bash
boost init
```

That step is what connects Cursor, Claude Code, GitHub Copilot and the Codex CLI. Running `boost` on its own, with no wrapped command, is also deliberate: it prints the Frogi mascot. Agents installing Boost on someone else's machine are pointed at a separate document, AGENT-INSTALL.md, rather than the human quick start. The repository ships `install.sh` and `install.ps1` at the root next to a `dist/` directory and a `versions.json`, and there is an `action.yml`, which is the shape a GitHub Action takes, so CI use appears to be supported even though the human-facing guide does not walk through it. Updating is `boost update`.

## The savings claim is 12% lower cost at the same pass rate

The evidence offered is a Terminal-Bench 2.0 benchmark described as showing an identical task pass rate with roughly 12% lower cost. The worked example in the documentation is easier to judge because you can read both sides. An uncompressed install:

```bash
# Without Boost: ~9,800 tokens of install noise
$ npm ci
npm warn deprecated inflight@1.0.6 / rimraf@3.0.2 / glob@7.2.3 …
added 1285 packages, audited 1286 in 45s
found 0 vulnerabilities

# With Boost: ~640 tokens, same outcome, cache-backed
$ boost npm ci
[OK] npm ci · 1,285 packages restored from boost cache in 2.4s · 0 vulnerabilities
```

The two figures given are about 9,800 tokens and about 640. The claim that matters more than the ratio is what survives compression: errors, timings, changed counts and cache hits, and on a failing run the failing test, the compiler error or the relevant stack frame. Truncating from the tail would be easy and would break agents, so the filters have to be command aware. The use cases named follow from that: long coding agent sessions where dozens of shell commands eat the context window, noisy test, build and debug loops covering `npm test`, `pytest`, `go test`, `docker build` and linters, and CI pipelines where shorter job logs with timing and cache signal are easier to scan on GitHub Actions and other runners.

## Two columns in the comparison table are unique to boost

The documentation sets boost against RTK, Headroom and Caveman in a capability grid, and the honest reading is that most rows are a tie. Command output compression and command output recovery are marked present for boost, RTK and Headroom alike. Assistant reply compression is marked only for Caveman, which is a different intervention entirely. The rows where boost stands alone are narrower and more interesting. Full-context and RAG compression is claimed by boost and Headroom but not by RTK. Versioned retrieval feedback, where filters are tracked and improved over time, is boost only. Auto-disable of repeatedly retrieved filters is also boost only, which is a correction loop rather than a saving. The last two rows, end-to-end agent task and cost A/B and native approval seeing the original executable, are marked for boost and left blank or crossed for the others.

## Every wrapped command behaves differently, and the docs show three

Boost is not a single filter but a set of per-command ones, and three examples are spelled out. `boost docker build` returns a compressed build log with a layer-cache summary, which is the case where an agent mostly needs to know whether a layer was reused. `boost npm ci` returns a dependency summary and uses a local package cache, and the output is described as retry-safe. `boost pytest` goes quiet on a green run and stays informative when tests actually break, which is the opposite trade from naive tail truncation and is the behaviour that decides whether the tool is safe for a coding agent. Beyond those, the wrapped list is Docker, npm, pytest, Git and the GitHub CLI, and other shell commands are said to pass through the same wrapper. Internal tools are handled by writing TOML filters for them, which is the extension point if your agents call something of your own.

## boost report opens a browser, -t keeps the summary in the terminal

Savings are inspectable after the fact, in two shapes:

```bash
boost report
```

opens an interactive web report, and the same data is available as a terminal narrative when you do not want to leave the shell:

```bash
boost report -t
# or: boost report --tui
```

That distinction matters for the target audience, since the whole premise is that an agent is driving the terminal and you do not want to break that flow to check whether the saving is real. Full documentation for commands, configuration and OpenTelemetry export lives at boost.jfrog.com/docs/en/overview/, which also means the tool can emit its own telemetry rather than being a black box. The README positions it as local-first, and the sections on privacy and the export configuration are where the detail on what is retained lives.

## Frogbot and Xray scan the same commits the releases come from

The security story is unusually concrete for a preview tool. The source repository is scanned on every push to `main`, and the claim is that these are the same commits every release is built from, which closes the usual gap between what was scanned and what shipped. The scanner is Frogbot running JFrog Xray with JFrog Advanced Security. What gets covered is listed: dependencies through SCA across Go modules and npm trees in every module, contextual analysis that checks whether a reported CVE is actually reachable from boost's own code rather than burying real risk in noise, malicious package detection before a build, secrets scanning across every tracked file, SAST over boost's Go and TypeScript sources, infrastructure as code covering CI workflows and deployment definitions, and an SBOM generated per build target on every scan. Findings arrive as code-scanning alerts and automated fix pull requests, with the full policy in SECURITY.md.

## Preview status, an unasserted licence, and three releases in two days

Two facts sit under everything else. The project carries a preview notice and is subject to JFrog's Online Preview Agreement, which is a different contract from a released tool with a stable licence. And the repository licence metadata reads NOASSERTION while a `LICENSE` file is present at the root, so the terms are whatever that file says rather than a standard identifier you can check at a glance. Cadence, by contrast, is fast: v0.13.33 on 2026-09-30, v0.14.0 the same day, and v0.14.1 on 2026-10-01, with the last push to main on 2026-10-01. Documentation is translated into seven READMEs covering Spanish, French, German, Japanese, Hindi and Hebrew alongside English. The project is sponsored by JFrog and the repository is Shell at the top level, with the Go sources referenced by the security section living alongside it.

## Conclusion

boost is worth installing if your agent spends a large share of its context window reading build and install logs, since wrapping the commands it already runs needs no change to your prompts and the failure detail is retained. It is a poor fit if your workload is mostly short commands, and you should treat the compression claim with the care any vendor benchmark deserves: the 12% figure comes from a Terminal-Bench 2.0 run cited on the vendor's own blog, not from an independent comparison. Before you pipe a curl into bash, read AGENT-INSTALL.md, check what the local-first storage keeps on disk, and decide whether preview status under JFrog's Online Preview Agreement is acceptable for a tool that sits between your agent and your source tree.

## FAQ

### How do I install boost and connect it to my coding agent?

On macOS, Linux or Windows under WSL run curl -fsSL https://boost.jfrog.com/install.sh | bash, and on Windows PowerShell use irm https://boost.jfrog.com/install.ps1 | iex. Then run boost init, which wires it into Cursor, Claude Code, GitHub Copilot and the Codex CLI. Agents installing it for a user are pointed at AGENT-INSTALL.md instead.

### What does boost keep when it compresses command output?

It keeps errors, timings, changed counts and cache hits, and on a failing run it keeps the failing test, compiler error or relevant stack frame. Filters are command aware rather than a tail truncation, and the example given turns roughly 9,800 tokens of npm ci output into about 640 while still reporting the package count, the cache restore and the vulnerability count.

### Which capabilities does boost claim that RTK and Headroom do not have?

The comparison grid marks boost alone for versioned retrieval feedback, auto-disable of repeatedly retrieved filters, and end-to-end agent task and cost A/B testing. Native approval seeing the original executable is also marked for boost. Command output compression and recovery are shared with RTK and Headroom, while assistant reply compression belongs to Caveman alone.

### Is boost released or still in preview?

It is in preview and subject to JFrog's Online Preview Agreement. The repository licence metadata reads NOASSERTION with a LICENSE file present at the root. Releases are frequent, with v0.13.33 and v0.14.0 both on 2026-09-30 and v0.14.1 on 2026-10-01.

## Sources

- [Issues](https://github.com/jfrog/boost/issues)
- [jfrog/boost on GitHub](https://github.com/jfrog/boost)
- [Project website](https://boost.jfrog.com/)
- [README](https://github.com/jfrog/boost/blob/main/README.md)
- [Releases](https://github.com/jfrog/boost/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jfrog-boost