Paritok: a proxy that rewrites the request, and a savings table built to exclude its own biggest lever

The agent keeps its settings, the request does not

Paritok is positioned in one place, between the agent and the model API, and the diagram in the file is the clearest statement of the design:

Your Agent (Claude Code / Cursor / Codex)
  → builds request (tool schemas + history + tool results / file reads)
     ★ Paritok gateway rewrites the request here ★
  → forwarded to Anthropic / OpenAI  (billed on the compressed tokens)
  ← response flows back unchanged; compressed refs expand on demand

The agent points its base URL at the gateway and changes nothing else, which is why it works with Claude Code, Cursor, Codex, OpenHands and anything that honours a base URL variable. The argument for it is that the bill is dominated by input the agent re-sends every turn: tool schemas, an ever-growing history, and large file reads. The response direction is untouched, and the file is explicit about the trade in one sentence, lossy on the wire, fully recoverable when it counts. Nothing is discarded permanently, because the agent can pull any exact original back on demand.

Tool schemas are frozen per conversation to protect the cache

The first lever targets the largest fixed cost. A coding agent exposes dozens of tools, often more than seventy once MCP servers are added, in full JSON schema on every request. Paritok filters them semantically with tool_discovery.strategy set to embedding, keeping a handful in full schema and stubbing the rest. Three properties make it more than a size trick. The selection is frozen per conversation, so the tools block stays byte-stable turn to turn and does not invalidate the model's KV cache, which is the constraint that ordinary dynamic tool selection breaks. Nothing is lost, since a filtered tool comes back in full when the model calls gateway_search_tools. And the core execution tool, named as shell, exec or apply_patch, is never stubbed, so an agent that exposes only a handful always keeps the one it cannot work without. The selector is a small open embedding model, BAAI/bge-small-en-v1.5 under MIT at roughly 130MB, run locally on CPU with no API and no per-token fee.

Content compression targets about 26 percent and tags every segment

The second lever is the trained model, and this is where the file claims the 4B model earns its keep. Each tool result, each file read, and each stale history turn once the window fills is compressed to roughly 26% of its original size and tagged with a reference marker in square brackets. The description of how it protects content is specific: it knows a function signature from a debug line, so it keeps identifiers, paths and error strings and drops the surrounding noise. Recovery is local and immediate, through read_original or expand_context, which returns the exact untouched bytes. Note the naming there. The news list records that the 1.3.0 release of 2026-07-31 renamed the read_original API from expand_context, so the two names in this sentence are the same endpoint before and after a stability release. Anything written against the old name needs checking.

History summarization is the lever with no measurement

The third lever is the plainest: turns beyond the recent window are summarized once the context fills, so a long session stays inside the model's window instead of overflowing or forcing aggressive client-side compaction that drops detail. Unlike the other two, it comes with no figure at all in the visible text. No percentage, no turn count, no example of what a summary keeps and what it loses. The comparison table further down measures content compression with the tool filter held on for both sides, so the history lever is not represented there either. Summarization is also the one mechanism that changes what the model sees rather than how much it sees, which is why its absence from the numbers is worth noticing rather than glossing over.

The one table isolates the smallest lever on purpose

There is a single measurement table, and the file is upfront about what it does not include. The task is a read-only find-the-bug run over five consecutive turns in one Claude Code session, on Sonnet with a GPU model, and the tool filter was left on for both sides so the delta isolates content compression alone.

| Turns | Paritok (files compressed) | Baseline (files raw) | Content-only saving | | :---: | :------------------------: | :-------------------: | :-----------------: | | 1 | 72,041 | 75,507 | 4.6% | | 5 | 293,389 (cumulative) | 377,099 (cumulative) | 22.2% |

Two things are visible in the shape of those numbers. The growth from 4.6% to 22.2% is the compounding argument, since compressed history keeps being re-sent on later turns. And the sentence that follows the table, which says the real comparison must add the tool filter back, stops mid-word, after and wi. So the combined figure a buyer would want is not in the text.

Headline savings arrive without a table

The opening claims are much larger than the table: input token bills cut by about 25% on turn one, past 85% in long context-saturated sessions, and roughly three times more turns in the same context window. The headline attributes the engine to the first open-source 4B compression model trained specifically for coding agents, from 45K real agent trajectories, and the news list dates the training finish to 2026-06-25 on 45K teacher-distilled samples over the Qwen3-4B backbone, with the weights released on the Hugging Face Hub on 2026-07-14 alongside what is described as a full SWE-bench Lite end-to-end evaluation. None of the three headline percentages is tied to a dataset, a harness or a turn count in the visible text. The table that does exist reports 4.6% on the same measure. Treat the two kinds of number as different kinds of claim.

The manifest says 1.3.13, the news stops at 1.3.8, and there are no releases

Version reporting is loose in three directions at once. The project metadata declares version 1.3.13 for the package named paritok, requires Python 3.10 or newer, and classifies the project as Beta. The news list in the file ends at v1.3.8, dated 2026-08-17, which added a visual stats dashboard showing live token savings and a per-request original to compressed comparison in place of raw JSON, plus a separate VS Code extension repository. The repository has no GitHub releases at all, so a version number appears only in the manifest and in a news line that is one minor version behind. That is workable for a proxy people install from source, and it means there is no artifact to fall back to if a checkout moves under you.

Runtime extras are optional, training pins are tight

The install surface is small. The base dependencies are tiktoken, click, pyyaml and httpx, and four optional groups extend it. dev adds pytest and ruff. proxy adds uvicorn, starlette, fastembed and numpy, with a comment explaining that the embedding selector ships because tool discovery defaults to embedding, and that the quantized ONNX weights for bge-small are bundled inside the wheel under paritok/data/bge-small-onnx/, so nothing downloads at runtime and no torch or CUDA is needed. toolselect is the same selector without the proxy, and redis is for persistent shadow storage so reference markers survive restarts. The training requirements are a different document with much tighter pins: Python 3.10 or 3.11, with a note that 3.12 and later have issues with some flash-attn builds, numpy held below 2.0, transformers between 4.45 and 4.50, and torch commented out on purpose so it is installed separately.

Editorial conclusion

Paritok is worth reading for its architecture rather than its advertising: the three levers attack three different parts of an input bill, and the tool filter is the only one designed around a cache constraint rather than a compression ratio. The numbers need care. The headline claims of about 25% on turn one, past 85% in saturated sessions and roughly three times more turns have no table, no harness and no dataset behind them in the file, while the one table that does exist was built to isolate the smallest lever. Two implementation details decide whether it fits your setup: the tool filter freezes per conversation to keep the cache stable, so a long session pays the selection cost once and the embedding model runs on CPU with weights bundled in the wheel. And compressed segments are recoverable through read_original, renamed from expand_context in the 1.3.0 release, so check that name against whatever you have written against the old API.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Paritok-official/paritok-4b-v1 on GitHub
4. Project website
5. README