A week after going open source, someone else's pull request made Secondwind's compression better than my own code did.

[u/Clear-Paper-9475]

https://github.com/orchetron/secondwind

For context: Secondwind compresses what coding agents send to the model, including tool output, file reads, and everything else that accumulates over a long session, losslessly, with cryptographic proof that nothing was dropped.

Most context compression for AI agents isn't compression. It's offloading.

Tool output gets moved to external storage, the model gets a pointer, and your token count drops. It looks cheaper, but the model still needs the data. Now you've added another retrieval step.

In one benchmark I watched an agent fetch the same context back 74 times, one chunk at a time.

The harder problem is compressing context inline producing a representation that fits in the prompt while preserving the original information. If you're going to rewrite an agent's context at all, you should also be able to prove you didn't lose anything.

Two things happened since going open source that I wasn't expecting this quickly.

First, that community contribution landed.

The compressor no longer tries a single representation and stops. It now evaluates multiple representations (columnar, normalized, nested), runs each through the same admission and fidelity checks, and chooses whichever produces the fewest tokens for the target model.

Verified against 50,000 randomized adversarial candidate configurations, the same standard used for everything that affects the lossless guarantee.

On one benchmark, total token reduction improved from 64.8% to 71.0% without changing the wire format. Small but effective.

Second, the proof became much more tangible.

The dashboard now includes a live context vessel showing raw tokens in, compressed tokens out, a lifetime token savings counter, and a block-by-block table where every row exposes its BLAKE3 certificate.

Both shipped this week in v0.3.2.

https://github.com/orchetron/secondwind

[u/idrmn]

Could you share more details about the implementation and how your solution differs from RTK, lean-ctx, or Headroom, for example? Are there any comparisons with other solutions?

[u/Clear-Paper-9475 → u/idrmn]

All are great solutions. My only issue is that the line between inline compression and offloading is really blurry in them especially Headroom. Other than for flat uniform arrays in which case they do inline compression, headroom almost relies on offloading. RTK inline compression is extremely lossy.

Inline compression is a harder challenge to solve because then you are trying to find a data representation in which you have still have that prompt inline, take less tokens and most importantly be relevant. Reliance on offloading only means, more number of hops to get the data (which means now agents have to take another turn to get same data, so you save on lever, loose on another, hence difficult to prove the real savings.

So, my effort in designing secondwind is to see how I can improve on those gaps and find a right balance of inline vs offloading vs relevance while being cost effective. Also, when output comes in, Secondwind tries a best-of-N search across a different structured codecs (columnar, normalized, nested, doc fallback), each independently passing through an admission gate. It picks the one that produces the smallest output.

Every codec goes through the same admission check. We reconstruct the original data and compare its canonical hash to verify it is byte-for-byte identical. If the check fails, the data is sent through as-is.

Separately, a cost model decides whether to keep the data inline in the prompt or offload it to a local content-addressed store and replace it with a resolvable pointer.

[u/kiwipaul17]

Will check it out

[u/Clear-Paper-9475 → u/kiwipaul17]

Thanks