Best practices
Debugging prompt compression
When compression removes content that should have been kept, debugging can be tricky. Here is a systematic approach to verify compressed outputs.
Debugging workflow
- Check the compression ratio — If the ratio is unusually high (90%+), compression may be too aggressive
- Review the compressed text — Does it contain the key facts needed for the answer?
- Check oracle recall — Run the compressed and original versions against a known answer
- Compare token distributions — Are important sections being disproportionately removed?
Frequently asked questions
How do I find what was incorrectly removed?
Compare the original and compressed text line by line. The removed lines that should have been kept are your false positives.
Can I log every compression decision?
Yes. SuperCompress returns which lines were kept and removed. Log these for debugging.
Build with less context
Put compression in front of your next LLM call.
Use the hosted API or run SuperCompress locally. Keep the evidence, drop the token waste, and measure the savings before it reaches your model.