Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
Paritok
Spend up to 85% less and run 3× longer coding agent sessions
398 followers
Spend up to 85% less and run 3× longer coding agent sessions
398 followers
Paritok compresses the tools, files, and history your coding agent sends. Save up to 85% on your token bill and run 3× longer sessions. Two commands, nothing lost, fully local.
Paritok
Hey PH community!
We're Jiayu and Luzhuo, two engineers who got tired of watching our coding agents burn through tokens.
Here's what we kept seeing: your agent ships far more than the model actually needs. Full JSON for seventy tools when it will call two. An entire file when it needed one function. Debug output nobody will ever read again. And because the API is stateless, all of it goes back on every single turn, so the waste doesn't just cost you once, it compounds.
So we built Paritok, a non-destructive compression gateway powered by a code-native 4B model we trained on 45K real agent trajectories. It sits between your agent and the API and cuts three things before they leave:
• Tool schemas — 29K down to 8K per turn, no model involved, this one runs on CPU
• File reads and tool output — compressed to about a quarter of their size
• Stale history — turns beyond a recent window get summarized once your context budget fills, so the session never overflows into a lossy compaction
With Paritok, you can cut your token bills 25% on turn 1 to past 85% in long or saturated sessions, and run ~3× more turns in the same context window. Paritok now works with Claude code, Codex, Cursor, and anything OpenAI or Anthropic compatible.
Paritok will continue to enhance functionality and adapt user scenarios, while deepening its model capabilities.
We’re excited to share this with the PH community and would love your honest feedback.
Try Paritok: https://www.paritok.com/
Join our Discord to talk with the team: https://discord.gg/SeBJE5Eucp
Thanks for checking us out, and huge thanks to our hunter Chris Messina for hunting us!
— Jiayu & Luzhuo
AdAnt AI
@jazzwind Congrats on the launch! Very useful and interesting product~ I am highly rely on my coding agents for everything, will try it out.
Paritok
@iris_tu Thanks Iris!
Want to make sure I'm reading the benchmark right. Quality retained = solve rate ÷ uncompressed baseline - so 86.5% means the agent resolves about 86.5% as many issues as it would with full context, a relative 13.5% drop in tasks actually completed? Or is that measuring something else?
If so, the comparison I'd want isn't against other compressors, but against just running a cheaper or lower-effort model at full context. Both routes cost quality and both cut the bill. Has that been measured? A strong model on compressed context vs a cheaper one on complete context, same tasks.
And which model was the scaffold running? Hard to judge 13.5% without knowing the baseline.
Paritok
@mateuszkonik You're reading the benchmark exactly right. Quality retained = compressor solve rate ÷ uncompressed baseline solve rate. So 86.5% means the agent scaffold, fed the compressed context, resolved ~86.5% as many issues as with full context — a relative ~13.5% drop.
However, 86.5% is the RAW 4B model measurement, with no recall enabled. Compressed output goes straight to the agent with no way to ask for the original back if something's missing. What you actually deploy is the gateway, which is different. Every compressed segment gets tagged [REF:id], and the agent can call `read_original` at any point to pull back the exact original bytes. In production, if the model can't work with the compressed version, it recalls the original so zero quality lost on that segment, just a slightly larger prompt on that turn.
So the practical trade in deployment isn't "13.5% worse for cheaper." It's closer to: same model quality (recall recovers when needed), ~25-85% fewer input tokens on turns where compression sticks, plus ~3× more turns fitting in the same context window. That last one is where it starts feeling like your model got smarter, more room to think and remember.
On the strong+compressed vs cheap+full comparison, I don't think they're substitutes, a cheaper model caps at its own reasoning ceiling regardless of context, and still hits the window wall at the certain turn count. Different problems.
Scaffold was running claude-sonnet-4-20250514.
Thanks for the sharp read!
@jazzwind thanks for the detailed explanation. Seen from that angle, it's actually remarkable. Do you maybe have some empirical data showing how much does the cost go down with recall turned on?
Paritok
@mateuszkonik Great follow-up!
We have our empirical data from our 2-week launch on our hosted-GPU: 62,486 compressions cut 447M input tokens across third-party users at ~85% average raw token reduction (recall on by default).
However, raw token % overstates actual dollar saving. Anthropic prices the frozen tool block at ~0.1× (cache_read) after turn 1, so a chunk of what we save was going to be cheap anyway. Cache-aware $ savings in production work out to roughly 60-70% end-to-end — meaningfully lower than the raw token %, but still substantial.
Recall itself doesn't materially hurt savings. the fact is that it fires infrequently.
Thanks for pushing on this.
@jazzwind thanks! I think you sold me on this one, I'm going to try it myself ;)
Triforce Todos
Paritok
@abod_rehman Thanks Abdul, great question!
Quick clarification: the "past 85%" number is the total end-to-end saving for context-saturated deployments specifically. It splits into two mechanisms:
1. Tool schema filter
2. 4B model compression which covers file reads + tool results + stale history summaries. All three go through the same [REF:id] path and share the same stats bucket.
Split of the total saving by config:
Default (~40 tools):
- Turn 1: tool filter 86% / 4B 14%
- Turn 5: tool 56% / 4B 44%
- Turn 15+: tool 37% / 4B 63%
MCP-heavy (70+ tools), turn 20: tool filter 57% / 4B 43%, because tool filter saves ~52K per turn (60K → 8K) instead of the default ~21K per turn (29K → 8K), so tool filter shoulders more of the total.
Context-saturated: 4B compression dominates, no-Paritok baseline saturates at ~200K/turn, so there's much more content to compress relative to the fixed tool block.
Full turn-by-turn breakdown + formulas in our README Compounding section.
Thanks for the well wishes!
@abod_rehman @jazzwind the crossover is the interesting part, tool filter carries turn 1 then the 4B model quietly takes over as the session saturates. way more honest than quoting one blended number
Paritok
@abod_rehman @sabber_ahamed Thanks Sabber
TabAI
Context bloat gets brutal with MCP-heavy setups. Keeping compression local while making the original bytes recoverable is a smart approach. Curious, how much latency does Paritok add per turn in a typical Claude Code session?
Paritok
@igor_martinyuk Good question. Compression normally runs on turns with a big tool output (a file read, a chunky MCP result). When it runs, extra latency scales with the compressor's output tokens. Rough anchor for input 2800 tokens and output 700 tokens: ~13s local on a consumer GPU (RTX 4060 via Ollama), ~3s on our hosted GPU server (network-dependent).
GNGM
Great job! The 3× turns per context window benefit is actually valuable to me. My Claude Code sessions hit compaction on big codebases. Excited to see how much longer they can run with this.
Paritok
@justin2025 Thanks Justin! Your Mom Clock is also a great product, will try it!
Those are some interesting numbers! How are you justifying costing 85% less, and what's the benchmark?
Heym
Congratulations on the launch! Context bloat is becoming a real bottleneck for coding agents, so a fully local way to compress tools, files, and history feels both practical and privacy-conscious. Looking forward to trying Paritok.
Paritok
@ceren_kaya_akgun Thanks Ceren! Really appreciate your support!