Query-aware context compression
Send less.
Answer better.
Every AI call is billed by the word — and most of what apps send is
irrelevant to the question being asked. hypercompress reads the pile first,
keeps only what matters, proves nothing was lost, and sends the rest to the shredder.
up to 95% fewer input tokens
100% quality held · 445 judged runs
~1 ms · $0 per token · in your process
every decision has a written reason
Without — a real workbook question sends everything
98,870 tokens
With — same question, same answer
3,182
"Give me all of one client's contacts" against a large outreach
workbook — every one of the 89 matching rows survives, 96.8% of the bill doesn't.
Elisions are marked […] so the model knows content was removed.
Why it exists
Seven pressures, one lever
Token waste isn't just a cost line. Cutting it moves seven dials at once.
💸
Cost
The budget line that scales with success — agents resend everything, every step.
🎯
Quality
More context makes answers worse. Filtering is an accuracy control.
🛡️
Control
Dropped text never crosses a third-party boundary — with a reason per block.
⚡
Latency
Fewer tokens in, faster answers out.
🚦
Rate limits
Smaller calls = more calls inside the same quota.
🧭
Horizon
More agent steps before the context ceiling.
📦
Cache economics
Naive compression cancels provider cache discounts; epoch-stable compression stacks them.
The philosophy
Three bets that make it different
🔍
Transparent over learned
No black box — search-engine scoring plus structure; every keep and drop has a named, auditable reason.
🪂
Fail open, always
Unsure, erroring, or thin savings → the original ships. The failure mode is "no savings", never "wrong answer".
🏠
In-process and free
~1 ms on a CPU, no network, no weights on the main path. Competitors need gigabytes and are 15–800× slower.
Under the hood
The journey of one request
Watch it happen step-by-step on your own files in the Live demo — nothing is mocked.
1
Bridge
The query learns the document's vocabulary: acronyms, plurals, "Bearing Point" ↔ "BearingPoint", "met" ↔ "Meeting set".
2
Split
Structure-aware blocks: tables and CSV rows stay whole, code stays atomic, headings keep their sections, errors are isolated.
3
Score
BM25 + exact identifiers, phrases, severity, recency. Every point of score is attributable.
4
Select
Keep what clears the line — with completeness rules for tables, surveys, counts, and lists.
5
Guard
Risk is measured, not vibes. Unsure → send the original. Savings under 15% → send the original.
6
Send
Original order, […] elision marks, full audit trail, measured savings.
Pointed question"What failed at 10:09?" — one block is the answer. 76–95% saved.
Exhaustive question"ALL contacts from X", "how many…" — every matching row kept. 96–99% saved on big sheets.
Survey question"Details of all the changes…" — coverage band, headings, echoes trimmed. 40–55% saved, completeness first.
Engine paths
Three tiers, one rule: earn confidence or hand off
Every request starts on the fast path. It ships only when the result
earns confidence — otherwise the request hands off to a deeper tier, and safety exits can
ship the original at any point. The Dashboard's "Engine paths taken"
card shows which door each of your runs left through.
Tier 1 · Fast
Transparent lexical scoring
BM25 + structure + vocabulary bridges. ~1 ms, zero dependencies, every decision
has a written reason.
Typical share: ~90% of runs
▸not
confident
Tier 2 · Semantic
Paraphrase catcher
30MB embeddings, ~2 ms — for questions that share meaning but no words with the
document. Carries the fast path's exact matches along.
Typical share: ~10% of runs
▸still not
confident
Tier 3 · Neural
Opt-in heavyweight
LLMLingua (2GB, seconds per call), installed separately. The first two tiers beat
it head-to-head — which is why it's last.
Typical share: rare · opt-in
What "confident" means — the hand-off rule, verbatim: the fast result ships when
measured risk is acceptable
and one of these holds:
- ✓A completeness mode produced it — a row-complete table,
an anchored section, a survey band. Deliberate keeps are terminal: no fallback tier
is allowed to "improve" a complete answer away, even at low savings.
- ✓Savings ≥ 20% with a real content match — the top-scoring
block is actual evidence, not just a heading that happens to share a word with the question.
Tiny input → passthrough≤ 256 tokens ships as-is.
No signal → declinedNo match for the question → the original
ships, flagged risk-high.
Thin savings → floorBelow 15% savings the original ships.
Small doc → no lossy tiers≤ 800-token documents never fall to a
lossy fallback tier.
Honest economics
What a question costs — including the expensive ones
Savings are a property of the question, not just the document. Same 78k-token regulatory PDF:
Entity rows from a workbook
96–99%
Status / value filters
~97%
Broad survey ("all the changes…")
40–55%
Counts / "which values appear"
→ 0%*
Tiny docs · thin savings · no signal
0%*
* Zero on purpose — a trimmed table gives a confidently wrong count.
The lever: one survey costs ~50%; the same information as pointed questions
averages 86% saved, and repeats are free with the cache.
Trust, but verify
How we know quality holds
Numbers below are the development campaign's; the Dashboard shows the same charts for your own runs.
📏
Benchmark gates
Seed-pinned suites + a 430-case retention corpus with 51 pinned checks, re-run in CI on every change. One lost answer fails the build.
⚖️
A blind judge, verified
Same model, same question, with and without compression — judged anonymized at temperature 0, every citation checked mechanically against the source.
📊
Your own dashboard
Every run lands on the Dashboard: savings, verdicts, engine paths. Local only; document contents never stored.
Answer-quality verdicts
445 judged runs, mechanically verified evidence
34 compressed better
411 ties
0 losses
Equivalent answers tie by design — the bar to beat is "nothing lost".
Savings by content type
Average per run, including the deliberate 0% safety keeps
Latency, honestly
Server milliseconds per compression
The tail is 100k-token workbooks and semantic-tier hand-offs — still faster than sending the tokens you saved.
Questions & answers
FAQ
For everyone
What does it do, in one sentence?
It reads the pile of text an app is about to send to an AI, keeps only what matters for the question, and cuts the bill 60–95% without changing the answers.
How do I know it doesn't break answers?
Four ways. It refuses to compress when unsure — the failure mode is "no savings", never "wrong answer". Facts like codes, amounts, and dates are structurally protected from deletion. Every code change re-runs benchmarks that fail the build if a single answer is lost. And there's a standing judged comparison — 445 recorded runs where the same AI answers with and without compression and a blind judge scores both — currently at 100% quality held, on the dashboard for anyone to inspect.
Why did this query only save 40%? Why did that one save nothing?
Because savings are a property of the question. A pointed fact is one paragraph — 90%+. "Details of ALL the changes" has an answer that genuinely spans chapters — ~50% is what completeness costs, and we measured that pushing further loses facts. "How many rows…" keeps the whole table on purpose, because a trimmed table gives a confidently wrong count. Below 15% computed savings the original is sent. Zero savings in those cases is the safety system working.
Is our data safe?
Safer than any alternative — compression runs inside your own process, and the dashboard records decisions and token counts locally, never document contents. Commercial competitors route your text through their API.
What did this cost to build vs. buy?
Commercial compression runs about $1 per million tokens plus data-exposure risk. This is $0 per token and self-hosted — the differentiation is the guardrail discipline and the evidence trail, not a trained model someone else can also rent.
For engineers
Walk me through what happens to one request.
Entry → tiny-input passthrough → vocabulary bridging (the query learns this document's acronyms, plurals, compounds, spacing) → structure-aware splitting (rows never cut mid-line) → intent detection: pointed (keep-line + fine trim), exhaustive (every matching row, numeric predicates, negated filters, whole-table-for-counts), or survey (coverage band, headings, exec summary front matter, echo trimming with lists exempt) → measured risk with a fail-open decline → hybrid arbitration (structural results are terminal; small docs never fall to a lossy tier; a semantic tier catches paraphrase) → a 15% floor under which the original ships. The
Live demo shows every stage with the real audit trail.
Why BM25 instead of embeddings or a trained model?
Debuggability — every drop has a named reason; a neural scorer gives a shrug. Latency — about a millisecond with zero dependencies. And the weakness is bounded: lexical scoring fails on paraphrase, which is exactly what the confidence guard detects and the 30MB semantic tier handles. Embeddings weren't avoided — they were demoted to the cases that need them.
The fast path matches words — what about all the ways words don't match?
A bridging layer expands the query using the document's own vocabulary — never a hardcoded dictionary: acronyms from the document's own initials (with ambiguity guards), spacing ("Bearing Point" ↔ "BearingPoint"), plural and verb forms ("cities" → a "City" column, "met" → "Meeting set"), compound tokens ("post" reaches app.post), recency ("most recent" reaches "2021 to Present"). Each bridge exists because a real judged loss demanded it.
What happens on tables and spreadsheets?
Tables are where wrong compression is most dangerous — a partial table produces confidently wrong aggregates. So exhaustive questions keep every matching row across every chunk; rows are never split mid-line; a match landing only on a column header keeps the whole table; numeric predicates ("above $50") and negated filters ("non-billable") are evaluated; and pointed questions that merely brush a table get a spread sample so the model sees its shape without the cost.
What happens when it fails?
Define fail. Weak signal → decline, the original ships. Exception anywhere → original. Savings under 15% → original. Small document with an unconfident result → original. A structurally-complete result is never overridden by a fallback tier. The failure mode is always "no savings", never "wrong answer".
Doesn't compression break provider prompt caching?
Naive compression does — caches reward byte-identical prefixes, and rewriting the prompt every turn cancels the discount. The cache-aware mode compresses history in epochs: one query-aware fold into a byte-stable block, new turns appended verbatim, recompression only when drift outgrows a bound. One cache miss per epoch instead of one per turn — the discounts stack.
Why should I trust benchmarks you wrote yourself?
You shouldn't, alone — there are four layers: self-authored seed-pinned suites (adversarial by design), LongBench (public, zero tuning contact), the judged campaign on real documents with a mechanically-verified judge, and a bring-your-own-data harness so you run it on your traffic. A retention failure without risk=high is a bug we want filed.
Tough questions
Isn't this just LLMLingua with extra steps?
It races LLMLingua head-to-head from their real pip package on the same machine: the hybrid holds 100% retention on both suites at ~82% saved and single-digit milliseconds; LLMLingua-2 retains 0–20% at aggressive rates and LongLLMLingua is 100–800× slower. Architecturally it's the opposite bet — transparent scoring, with the neural approach demoted to an optional tier where their package is used, credited, and beaten on configuration.
The dashboard shows 100% quality held. What aren't you showing?
It's 100% win-or-tie under a mechanically verified evidence standard — not "compressed is always better". The judge is a single model and advisory; the facts check is ground truth. Verdicts whose citations fail verification are ties by documented doctrine. And losses stayed on the board for weeks until fixes genuinely superseded them — the full history of every loss and fix is in the changelog and git.
What's the weakest part today?
Three honest ones. Whole-document summary richness on heading-less prose — a compressed summary can lose a detail contest even with every section present. Intent detection is a transparent cue list, not a classifier — an unseen phrasing can take the wrong path. And the judged campaign, while large, is one team's document mix — the bring-your-own-data harness exists precisely so others expand it.
© Copyright Wissen Technology 2026