sqz compresses tool output before it reaches the model, and its real win is a dedup cache
Compress LLM context to save tokens and reduce costs
At a glance
- What is it?
- sqz is a Rust binary that sits between your shell or agent harness and the LLM, compressing command output and replacing repeated file reads with short references. The README's own numbers show single-command compression ranges from 0% to 58%, so the value depends almost entirely on how repetitive your sessions are.
- Who is it for?
- Adopt sqz if your agent sessions re-read the same files or re-run the same commands often, because the documented 13-token reference for cached content is where nearly all the savings come from. Do not adopt it expecting large gains on prose, documentation, or stack traces, since the README's own table lists 2% for prose and 0% for stack traces in safe mode.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is context pollution, not context length
Every tool call an agent makes returns text that goes into the prompt. A file read returns the whole file. A test run returns the whole log. A git diff returns the whole diff. If the agent reads the same configuration file five times in one session, the model pays for it five times, and the earlier copies do not even help, because they are identical to the newest copy. sqz targets that specific pattern. The README states the goal plainly: it compresses command output before it reaches your LLM, as a single Rust binary with zero config. The audience is anyone running agentic coding sessions where the same files and commands come back repeatedly. The README's own framing supports this: the win is dedup, and the single-command compression numbers are secondary. If your sessions are one-shot questions with no repeated reads, the tool has little to work on.
Two mechanisms: content compression and a 13-token reference cache
The first mechanism is per-payload compression. The README does not describe the algorithm, only the outcomes, measured through cargo test -p sqz-engine benchmarks. Repeated log lines go from 148 tokens to 62, a 58% reduction. A large JSON array goes from 259 to 142. A JSON API response drops 17%, a git diff 12%, prose 2%, and a stack trace in safe mode 0%. That spread matters: the compressor is doing structural work on repetitive or tabular text and essentially nothing on natural language or on stack traces it has been told not to touch. The second mechanism is the cache. When the same file is read again in a session, sqz sends it once and returns a 13-token reference for every repeat. The README's worked example shows three reads of a 2,000-token file going from 6,000 tokens to roughly 826, an 86% saving. The arithmetic is straightforward: the first read is compressed to about 800 tokens, and reads two and three cost 13 tokens each. Session-level tables extend this to a test-fix-test cycle of three runs, 15,000 tokens down to 5,186, and to the same JSON response returned three times, 192 down to 79. The data flow, as far as the material shows, is: tool output passes through sqz, gets compressed, gets checked against the session cache, and either the compressed text or a short reference continues to the model.
Install paths, and the Windows linker trap
Prebuilt binaries cover the common cases. On macOS or Linux the README gives curl -fsSL https://raw.githubusercontent.com/ojuschugh1/sqz/main/install.sh | sh. On Windows it gives irm https://raw.githubusercontent.com/ojuschugh1/sqz/main/install.ps1 | iex. There is also npm install -g sqz-cli, and Homebrew via brew tap ojuschugh1/sqz followed by brew install sqz. Building from source uses cargo install sqz-cli sqz-mcp, where sqz-cli provides the sqz binary and sqz-mcp provides the MCP server; sqz-engine is a library dependency that compiles automatically. The README is explicit that the Cargo route needs a C toolchain, and that on Windows you need Visual Studio Build Tools with the Desktop development with C++ workload, otherwise cargo install fails with linker link.exe not found. That is a real friction point, and the README's own advice is to use the PowerShell or npm installer instead if you do not already have those tools. After installing, sqz init --global writes the hook to ~/.claude/settings.json so it fires in every Claude Code session on the machine, while plain sqz init writes to .claude/settings.local.json for one project. The README notes --global is the common case on first install, citing Anthropic's settings scope table.
The savings distribution is the honest part of the README
The headline figures are 3,003 compressions, 178,442 tokens saved, and a 24.7% average reduction, with a peak of 92% on repeated reads. The per-command table undercuts the headline in a useful way. Stack traces in safe mode show 0% saved, which suggests the safe mode deliberately leaves certain content untouched rather than risk mangling it. Prose shows 2%. Those two rows tell you more about fit than the average does. A session dominated by reading documentation, long error traces, or narrative text will land far below 24.7%. The README says this directly: your mileage will vary with how repetitive your tool calls are, and agentic sessions with many file re-reads see the biggest wins. The sqz gain output shown is from one developer's week, with daily totals ranging from 0 to 105,569 tokens saved. A single day carried most of the week's savings. That is a distribution with a long tail, not a steady rate, and it is the number to keep in mind when estimating cost impact.
Where sqz is the wrong tool
Three cases stand out from the material. First, non-repetitive sessions. If an agent reads each file once and never revisits it, the cache never fires, and you are left with the per-command rates: 12% on a git diff, 17% on a JSON response, 2% on prose. That is not nothing, but it is not the 92% the project is known for. Second, content that safe mode refuses to compress. The 0% stack trace row implies that error-heavy debugging sessions get no benefit from the compression path, and only benefit if the same trace is regenerated and deduplicated. Third, environments where you cannot install a hook. sqz works by intercepting tool output, and the documented setup writes to Claude Code settings files. The README lists a VS Code extension, a Firefox add-on, a JetBrains plugin, and an MCP server, so there are other integration surfaces, but the material does not describe how those behave differently from the CLI hook. Anyone outside that ecosystem should verify integration before assuming it applies.
Alternatives: trimming context versus compressing it
The nearest alternative approach is not another compressor but a context manager: tools that decide what to keep in the window and drop or summarize the rest, rather than compressing each payload as it arrives. The difference in mechanism is real. A context manager reduces what the model sees by removing history, which changes what the model knows. sqz keeps the content and changes its representation, plus a cache for exact repeats. That means sqz cannot help when the context is full of unique, non-repetitive material, which is precisely the case a summarization or eviction strategy handles. Conversely, a summarization strategy degrades fidelity for everything, while sqz's dedup path is lossless in the sense that the original file was already sent once in the session. The README also carries a name disambiguation note stating that this repository is independent and not affiliated with other similarly named or similarly working compression projects that shorten squeeze. If you are evaluating options, that note is worth reading before you compare package names, because the namespace is crowded.
Maintenance, licensing, and what to check before adopting
The repository reports NOASSERTION for its licence, which means GitHub could not map the licence file to a known identifier. That is not a red flag by itself, but it does mean you have to open the licence file and read it rather than assume MIT or Apache-2.0. For a binary you pipe your source code and command output through, the terms matter, and this article cannot tell you what they are. On maintenance, the release history shows v1.5.0, v1.6.0, and v1.6.1 all within August 2026, and the last push is dated 2026-08-28, so the project is active on a short cadence. The repository is not archived. Upgrade cost looks low for the prebuilt installers, since they replace a binary, and the configuration surface is a single init command writing to a settings file. The one upgrade concern the material raises is the Windows Cargo path, which depends on Visual Studio Build Tools and will fail at link time without them. Beyond that, the material does not describe a migration story, a config schema version, or a cache format, so anyone running this in a team should check whether the cache is per-session or persisted, and where, before assuming behaviour is consistent across machines.
Editorial conclusion
Adopt sqz if your agent sessions re-read the same files or re-run the same commands often, because the documented 13-token reference for cached content is where nearly all the savings come from. Do not adopt it expecting large gains on prose, documentation, or stack traces, since the README's own table lists 2% for prose and 0% for stack traces in safe mode. Before rolling it out, run sqz gain after a normal week to see whether your workload is repetitive enough to justify the hook, and check the licence file yourself, because the repository reports NOASSERTION rather than a named licence.
Community notes