@tokz/compress
Compressed context your agent can still edit against
A local MCP server that hands your agent the exact part of a file it asked for — checked byte-for-byte against disk before it's returned.
npm i -g @tokz/compresstokz-compress setupMIT, and local by default — no account, no API key, no network.
Why verbatim is the whole point here
An agent editing against paraphrased code produces an old_string that does not match disk, so the edit fails. Verbatim is not a nicety here — it is the difference between an edit landing and an agent looping.
A summarizer's paraphrase
// what a lossy context tool handed the agent
function handleRateLimit(retry) {
// wait before retrying the call
}✕ old_string not found on disk — edit fails, agent retries blind
A tokz-compress span
// the exact bytes tokz-compress returned
function handleRateLimit(retryAfterMs) {
await sleep(retryAfterMs);
}✓ old_string matches byte-for-byte — edit lands on the first try
Four strategies, picked by what the file is
- Code
- Tree-sitter parse, BM25 ranking over the symbols that match the query.
- Logs
- Collapses identical-shaped lines, keeps the ones that differ.
- JSON
- Extracts the schema, keeps representative samples.
- Prose
- Block selection, offline-first.
- 86%
- recall
- 37 of 43 required spans found verbatim across the eval set.
- ~1 ms
- retrieval
- tokz_retrieve(hash, lines) returns any elided range byte-for-byte from a local cache.
- 12 / 29 ms
- median / p95
- Compression latency, local, no network.
- 0
- verbatim failures
- Across the eval set. Every emitted span matched the file on disk.
The same guarantee, applied to everything your agent reads
This server compresses files on disk for one machine. The hosted API does it for tool results, retrieved documents and transcripts across a team — with byte offsets instead of text, so nothing is stored anywhere.