Paritok token gateway: Mas mura ba ang coding agent?
Alamin kung paano kino-compress ng Paritok ang file reads at tool output, at suriin ang claim na 74% fewer tokens bago gamitin sa coding agent mo.
Ginagawa ng Paritok sa isang request
Ang Paritok ay isang token gateway: proxy ito na nasa pagitan ng coding agent mo at ng model API at nagko-compress ng bawat request bago ito ipasa. Kumokonekta ang agent mo sa http://127.0.0.1:8080 sa halip na direkta sa provider. Muling inaayos ng proxy ang tool schemas, file reads, tool output, at mga naunang turn, ipinapadala ang mas maliit na payload upstream, at ibinabalik ang reply nang walang pagbabago.
Sinisingil ka ng provider batay sa natatanggap nito, kaya mas maliit na payload ay nangangahulugang mas maliit na invoice. Iyan ang buong konsepto. Iba ito sa pahayag na “mas tatagal ang context mo,” at ito ang dahilan kung bakit kawili-wili ang tool na ito sa halip na isa lamang itong mas maayos na setup.
Bago pa ang project. Ang mga unang public tag nito ay may petsang July 2026, at ang kasalukuyang tag ay v1.3.0, na may petsang 5 August 2026. Apache 2.0 ang lisensya ng weights at gateway code. Ang compression model ay isang LoRA (low-rank adaptation) adapter sa Qwen3-4B-Instruct-2507, na sinanay gamit ang 45,000 teacher-distilled sample mula sa mga totoong coding-agent trajectory.
Bakit hindi ito context trimming
Nagtatanggal ang trimming. Kapag malapit na sa context limit ang isang agent at inaalis nito ang pinakamatatandang turn, nawawala ang file na binasa nito sa turn 3. Kung kailangan nito ang file sa turn 20, babasahin nitong muli ang file, kaya magbabayad ka ulit para sa mga token na iyon. Pansamantala lamang ang natipid.
Pinapalitan ng Paritok ang isang segment ng mas maikling anyo at tag, [REF:id], habang pinananatili ang buong text sa proxy. Binabawi ng model ang isang segment sa pamamagitan ng pagtawag sa read_original o expand_context. Binabago nito ang paraan ng pagkakaroon ng failure. Nabibigo ang trimmer dahil nakakalimot ito, at hindi nito ipinapaalam sa iyo. Nabibigo ang compressor dahil nagbibigay ito sa model ng lossy summary, at maaaring hilingin ng model ang orihinal kapag hindi sapat ang summary.
Ganito rin kumikilos ang tool filter. Ginagawang stub ang mga na-filter na tool schema sa halip na alisin ang mga ito, at binabawi ng model ang isa sa pamamagitan ng pagtawag sa gateway_search_tools. Mahalaga ito dahil binabago ng filter na permanenteng nagtatago ng tool kung ano ang kayang gawin ng iyong agent, at malalaman mo lamang ito kapag tahimik na nagkamali ang isang task.
Tatlong lever, at kung alin ang libre
Ang unang lever ay ang tool-schema filter. Dala ng bawat request ang buong tools array. Sa isang Claude Code turn na may ilang MCP (model context protocol) server, tinatantiya ng project na humigit-kumulang 29,000 tokens ang block na ito. Ine-embed ng filter ang request ng user at bawat tool description gamit ang BAAI/bge-small-en-v1.5, isang 130 MB embedding model. Pinapanatili nito ang mga tool na tumutugma at ginagawang stub ang iba. Bumababa ang block sa humigit-kumulang 8,000 tokens. Sa CPU tumatakbo ang embedding model na ito.
Ang ikalawang lever ay content compression. Ito ang bahaging nangangailangan ng 4B model sa GPU. Ang file reads, tool output, at history ay nire-rewrite hanggang 25.7% ng orihinal na laki. Dito nanggagaling ang 74% na headline. Basahin ito nang mabuti: ang 74% ay compression rate sa content na kino-compress, hindi ang bawas sa bill mo.
Ang ikatlong lever ay history summarization. Kapag napuno ang context budget, sini-summarize ang mga turn na lampas sa recent window upang magpatuloy ang mahabang session sa halip na maabot ang limit.
Ang ikalawang lever lamang ang nangangailangan ng GPU. Ito ang pinakamahalagang pangungusap sa page na ito. Binibigyan ka ng pip install "paritok[toolselect]" ng tool filter sa isang ordinaryong CPU VPS, at ito ang kalahati ng product na walang buwanang gastos. Subukan muna ito bago mag-rent ng card.
Ano ang sinukat ng proyekto, at kaninong harness ito isinagawa
The data behind this chart
[
{
"label": "Paritok-4B-v1",
"compressed_to_pct": 25.7,
"quality_retained_pct": 86.5
},
{
"label": "gpt-4.1-mini",
"compressed_to_pct": 50.2,
"quality_retained_pct": 85.6
},
{
"label": "gpt-5",
"compressed_to_pct": 61.9,
"quality_retained_pct": 93.6
}
]Ito ang sariling inilathalang datos ng proyekto, na sinukat gamit ang sarili nitong harness laban sa SWE-bench Lite. Kino-compress ng Paritok-4B-v1 ang content hanggang 25.7% ng orihinal na laki habang napapanatili ang 86.5% ng solve rate ng hindi naka-compress na content. Kapag gpt-5 ang ginamit bilang compressor, mas maraming kalidad ang napapanatili, 93.6%, pero kino-compress lamang nito hanggang 61.9%; magbabayad ka pa rin ng frontier prices para makatipid sa frontier prices.
Basahin nang tapat ang quality column. Ang pagpapanatili ng 86.5% ng solve rate ay nangangahulugang may mga problemang nalutas ng uncompressed runs pero hindi ng compressed runs—halos isa sa bawat pito. Sa benchmark, isa lamang itong numero sa table. Sa sarili mong repository, isa itong task na kailangan mong patakbuhin nang dalawang beses.
The data behind this chart
[
{
"label": "Turn 1",
"saved_pct": 25
},
{
"label": "Turn 5",
"saved_pct": 39
},
{
"label": "Turn 12",
"saved_pct": 57
},
{
"label": "Turn 20",
"saved_pct": 63
}
]Lumalaki ang end-to-end na matitipid habang tumatagal ang session dahil naiipon ang history, at ang history ang kino-compress. Iniulat ng proyekto ang humigit-kumulang 25% na matitipid sa isang turn, 39% pagsapit ng turn 5, at 63% pagsapit ng turn 20. Tinutukoy rin nito kung kailan humihinto ang paglaki: sa 200,000 token budget, nagfa-flatten ang absolute saving sa humigit-kumulang 48,000 tokens bawat turn, bandang turn 8 hanggang 12, dahil kapag puno na ang context, hindi na lumalaki ang history. Ang malawakang binabanggit na "lampas 85%" na figure ay tumutukoy sa mga session na saturated na ang context. Ito ang pinakamagandang sitwasyon, kaya huwag itong gawing batayan ng pagpaplano.
Sulit ba sa Paritok ang 24GB GPU?
Ang 24 GB card ang karaniwang rental unit para sa model na ganito ang laki. Noong 7 August 2026, ang median na published on-demand rate para sa RTX 4090 na may 24 GB ay $0.44 kada oras, at ang pinakamurang listings ay nasa bandang $0.20. Gamitin natin ang $0.44. Kung patuloy itong tatakbo sa buong buwan, 730 oras iyon, kaya $321. Kung gagamitin lamang sa working hours, 8 oras bawat araw sa loob ng 22 araw, 176 oras iyon, kaya $77.
Ngayon, gawing dollar saving ang token reduction. Input tokens lamang ang naaapektuhan. Dumadaan ang output tokens sa proxy nang walang pagbabago, kaya hindi sila gumagalaw. Ipagpalagay na 80% ng kabuuang gastos mo ay para sa input tokens, na karaniwan para sa isang coding agent, at ihambing ang palagay na ito sa sarili mong bill. Ang dollar saving mo ay token reduction na minultiply sa 0.8.
The data behind this chart
[
{
"label": "Turn 5 (39% saved)",
"bill_always_on_usd": "1,030",
"bill_workday_only_usd": 248
},
{
"label": "Turn 20 (63% saved)",
"bill_always_on_usd": 637,
"bill_workday_only_usd": 154
},
{
"label": "Saturated (85% saved)",
"bill_always_on_usd": 472,
"bill_workday_only_usd": 114
}
]Sa saturated-session figure na 85%, 68% ng bill ang matitipid mo. Dahil dito, mababawi ng card na patuloy na tumatakbo ang gastos nito kapag lumampas sa humigit-kumulang $472 ang buwanang agent spend mo, o humigit-kumulang $114 kung ihihinto mo ang instance kapag wala nang working hours. Sa turn-20 figure na 63%, magiging $637 at $154 ang mga halagang iyon. Sa turn-5 figure na 39%, na siyang aktuwal na anyo ng maiikling session, kailangan mong gumastos ng humigit-kumulang $1,030 bawat buwan bago maging sulit rentahan ang card.
May dalawang bagay na nagpapaganda sa resulta kumpara sa ipinapakita ng table. Hindi kailangan ng model ang buong 24 GB: humigit-kumulang 2.5 GB ang q4 build at humigit-kumulang 8 GB ang bf16 build. Kaya kung mas maliit na card ang gagamitin mo, o GPU box na pinapatakbo mo na para sa ibang gawain, bababa ang lahat ng numero sa chart. Ang paghinto sa instance kapag walang nagco-code ang pinakamalaking paraan para bumaba ang gastos, dahil nababawasan nito ang rent ng humigit-kumulang tatlong-kapat.
May isang bagay namang nagpapataas ng gastos. Totoong computation ang compression pass. Bawat token na kino-compress ng 4B model ay kailangang basahin at isulat nito, kaya nadaragdagan ang latency sa bawat agent turn. Sa card na nirentahan batay sa oras, lumilitaw ang gastos na iyon bilang paghihintay, hindi bilang hiwalay na linya sa invoice. Dahil dito, madali itong hindi mapansin hanggang maramdaman mo ang epekto.
Kung ikinukumpara mo ang rented GPU hours sa API tokens sa pangkalahatan, ginagawa ng break-even sa pagitan ng GPU VPS at API tokens ang parehong arithmetic para sa inference mismo.
Pagpapatakbo ng Paritok gateway sa isang VPS
Kailangan ang Python 3.10 o mas bago. Kasama sa Ubuntu 24.04 ang Python 3.12, kaya sapat na ang plain VPS image para sa CPU-only na bahagi.
sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"I-pin ang version. Nag-tag ang repository ng v1.2.8 noong 29 July 2026 at ng v1.3.0 noong 5 August 2026. Ang proyektong ganito kabilis maglabas ng mga release ay maaaring magpalit ng config key sa pagitan ng mga release. Ang isang walang version na pip install paritok, o isang git clone ng main, ay maaaring magbigay sa iyo ng ibang gateway sa susunod na linggo at walang itatalang kung alin ang gumawa ng mga numerong sinukat mo.
Ollama ang default backend. I-pull ang model, pagkatapos ay bigyan ito ng maikling pangalan na hinahanap ng proxy.
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1Dahil gumagawa ang local model ng rewrite para sa bawat segment na kino-compress nito, ang compression pass na tumatagal nang matagal ay lumalabas bilang agent turn na hindi umuusad. Ang num_predict cap ng Ollama sa haba ng output ang naglilimita rito.
Isulat ang paritok.yaml sa tabi nito. use_gpu_server: false ang nagpapanatili sa compression sa sarili mong hardware.
use_gpu_server: false
local_model:
base_url: http://localhost:11434paritok proxy --port 8080 --config-file paritok.yamlAng paritok up ang shortcut para sa lahat ng nasa itaas: pini-pull nito ang model kung wala pa ito at sinisimulan ang proxy sa port 8080. Suriin muna ang proxy bago ituro rito ang isang agent.
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/statsNagbabalik ang /health ng maliit na JSON object na naglalaman ng "status":"ok" at isang version string. Nagbabalik ang /stats ng kabuuang compression at sariling estimate ng proxy kung gaano karami ang natipid nito. Ituring ang estimate na ito bilang pagsusuri ng proxy sa sarili nitong gawain, at kumpirmahin ito sa usage page ng iyong provider.
Para sa throughput sa halip na convenience, sine-serve ng vLLM ang adapter sa ibabaw ng base model.
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Mas mabilis i-set up ang Ollama. Mas mahusay humawak ng concurrent requests ang vLLM, at nagiging mahalaga ito kapag higit sa isang agent ang gumagamit ng server. Ang praktikal na pagkakaiba ng Ollama at vLLM ang tutulong sa iyong magpasya.
Ituro ang agent sa proxy gamit ang base URL environment variables.
export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080Hindi pinapansin ng Codex CLI ang OPENAI_BASE_URL, kaya awtomatikong isinusulat ng proyekto ang ~/.codex/config.toml kapag naka-set ang codex.enabled: true sa paritok.yaml. Kapag ang variable lang ang in-export mo, direktang nakikipag-usap ang Codex sa provider. Makikita ito sa /stats counter na hindi gumagalaw habang nagtatrabaho ka.
Panatilihin ang listener sa 127.0.0.1, at huwag kailanman sa 0.0.0.0. Ipinapasa ng proxy ang provider API key mo upstream. Kaya ang proxy na naaabot mula sa internet ay open relay para sa key na iyon: maaaring gamitin ng sinumang makahanap ng port ang pera mo nang hindi kailanman nakikita ang key mismo. Sa halip na buksan ang port, abutin ito mula sa laptop gamit ang SSH tunnel o VPN.
Patakbuhin ito sa ilalim ng systemd upang manatiling tumatakbo matapos ang reboot. Iangkop ang mga path sa iyong installation.
[Unit]
Description=Paritok compression proxy
After=network-online.target
[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.targetI-enable ito gamit ang sudo systemctl enable --now paritok, pagkatapos ay i-curl muli ang /health. Ang unit na nagsisimula at agad na lumalabas ay karaniwang nangangahulugang mali ang path ng config file. Ipi-print ng journalctl -u paritok -n 50 ang dahilan.
Ang hosted option at ang kapalit nito
Iniaalok din ng proyekto ang compression bilang isang serbisyo. I-configure ang use_gpu_server: true gamit ang API key, at tatakbo ang 4B model sa hardware nito. Ang singil ay $0.30 bawat milyong naprosesong token. Ayon sa sarili nitong documentation, libre ito hanggang sa katapusan ng August 2026. Inaalis nito ang gastos sa GPU rent at ang lahat ng operations work na nabanggit sa itaas.
Nangangahulugan din ito na lalabas sa iyong machine ang mga prompt mo at ang mga file na binabasa ng agent mo, at mapupunta muna sa third party bago makarating sa model provider mo. Ginagamit ang self-hosting upang maiwasan mismo ang ganitong hop. Magpasya muna kung alin sa dalawang ito ang gusto mong i-optimize bago mong i-set ang flag na iyon. Isang line lang ang kailangang baguhin sa flag, pero hindi ganoon kasimple ang magiging epekto.
Paano sukatin ang sarili mong before at after
Ang mga numerong inilathala ay mga numero ng proyekto, mula sa harness ng proyekto, sa SWE-bench Lite. Hindi SWE-bench Lite ang repository mo. Sukatin ang sarili mong resulta.
- Magpatakbo ng isang normal na linggo na walang proxy sa path. Itala sa magkakahiwalay na linya ang input tokens, cache-read tokens, at output tokens mula sa usage page ng provider mo, hindi bilang isang kabuuang halaga sa dolyar.
- Sa susunod na linggo, magpatakbo gamit ang proxy sa unahan, at gawin ang parehong uri ng trabaho.
- Ihambing ang input at cache-read lines. Dapat halos hindi magbago ang output, dahil walang nagko-compress nito. Kung malaki ang ipinagbago ng output, may ibang nagbago bukod sa proxy.
- Bilangin ang mga task na kinailangan mong ulitin. Iyan ang bahagi ng tradeoff na nauugnay sa quality, at walang dashboard saanman ang nag-uulat nito.
- Idagdag ang GPU hours sa week two bago mo ihambing ang mga total.
Mahalagang paghiwalayin ang input sa output dahil magkaiba ang presyo ng mga ito at isa lamang sa mga ito ang naaapektuhan ng compressor. Noong August 2026, ang Claude Sonnet 4.6 ay nagkakahalaga ng $3 bawat million input tokens at $15 bawat million output tokens, habang ang prompt-cache read ay 10% ng input rate, o $0.30 bawat million. Ang pagitan ng halaga ng input at output token ang tumutukoy kung may pakinabang sa iyo ang isang input-side compressor. Ipinapakita ng kung saan talaga napupunta ang mga token ng Claude Code kung aling bahagi ng iyong context ang sapat ang laki para sulit i-compress.
Lalo na pinapahirap ng prompt caching ang arithmetic para sa tool filter. Nasa unahan ng request ang tool block, kaya pagkatapos ng unang turn, karaniwan itong cache hit sa halagang 10% ng input price. Kapag nagbawas ng 21,000 tokens mula sa naka-cache na block, 21,000 tokens ang natitipid sa halagang $0.30 bawat million, o humigit-kumulang $0.006 bawat turn, sa halip na $0.063 na ipahihiwatig ng uncached rate. Pinananatiling hindi nagbabago ng proyekto ang filtered block sa buong session upang hindi magbago ang cached prefix. Kapag pumili muli ng tools ang isang filter sa bawat turn, mai-invalidate nito ang prefix at mas malaki ang magiging gastos kaysa sa matitipid.
Ano pa ang hindi nabe-verify
Ang bawat performance number sa itaas ay mula mismo sa project. Wala pang independent reproduction ng mga resulta sa SWE-bench Lite. Dahil ang mga unang tag ay may petsang July 2026, kakaunti rin ang operational history ng code. Ang compression rate at quality-retained figure ay parehong sinukat ng partidong nakikinabang kapag maganda ang resulta. Hindi ito nangangahulugang mali ang mga ito. Nangangahulugan lamang itong hindi pa nakukumpirma ang mga ito, kaya dapat iba ang pagtrato mo sa mga ito kumpara sa numerong ikaw mismo ang gumawa.
May isang documented behaviour na dapat mong malaman bago sisihin ang setup mo. Naglo-load ang embedding model na ginagamit ng tool filter sa unang request, hindi sa startup. Kaya nagdodokumento ang project ng warm-up na 10 hanggang 15 segundo, at humigit-kumulang 15 ms bawat call pagkatapos nito. Magpadala ng isang throwaway request pagkatapos magsimula ang proxy upang hindi magmukhang nag-hang ang unang totoong agent turn.
May apat na bagay kang maaaring i-settle mismo sa loob ng isang hapon: kung nagsisimula at nananatiling tumatakbo ang proxy, kung gumagalaw ang /stats habang nagtatrabaho ka, kung talagang bumababa ang input-token line ng provider mo, at kung natatapos pa rin ng agent ang trabaho. Mas maaasahan ang mga ito para sa setup mo kaysa sa anumang published benchmark.
Tungkol sa posisyon nito kumpara sa iba mong tooling: ang self-hosted LiteLLM gateway ay nagro-route at nagme-meter ng mga request nang hindi binabago ang laman ng mga ito, kaya magkaibang problema ang nilulutas ng dalawang tool at maaaring gamitin nang magkasunod, kung saan ang Paritok ang pinakamalapit sa agent. Kung ang tunay na layunin ay mas mababang bill at hindi ang partikular na tool na ito, kasama sa mas malawak na hanay ng cost controls para sa isang agent sa VPS ang ilang pagbabagong walang gastos at maaari mong subukan muna.
FAQ
Binabawasan ba ng Paritok ang API bill ko, o ang context usage lang?
Binabawasan nito ang bill dahil nire-rewrite ng proxy ang request bago ito makarating sa provider, at sinisingil ka ng provider batay sa natatanggap nito. Mas maliit ang aktuwal na bawas kaysa sa ipinahihiwatig ng headline. Ang 74% na figure ay compression rate ng content na kino-compress. End to end, nag-uulat ang project ng humigit-kumulang 25% sa isang turn at 63% pagsapit ng turn 20, at input tokens lang ang nagbabago. Dumadaan nang walang pagbabago ang output tokens.
Gaano kalaking GPU ang kailangan ko para i-self-host ang compression model?
Humigit-kumulang 2.5 GB ang q4 build at 8 GB ang bf16 build, kaya kasya ang model sa isang 24 GB card at malaki pa ang matitirang espasyo. Gumagana rin ang mas maliit na card, at mas pabor sa iyo ang break-even calculation nito. Walang GPU na kailangan ang tool-schema filter: gumagamit ito ng BAAI/bge-small-en-v1.5, isang 130 MB embedding model na tumatakbo sa CPU. I-install ang paritok[toolselect] sa ordinaryong VPS at makukuha mo ang tool-block reduction kapalit ng kaunting RAM.
Ano ang mangyayari kung may alisin ang compressor na kailangan ng agent?
Walang inaalis. May [REF:id] tag ang mga compressed segment, at nire-recover ng model ang buong text gamit ang read_original o expand_context. Ginagawang stub ang mga na-filter na tool schema sa halip na burahin, at nire-recover ng model ang isa gamit ang gateway_search_tools. Mas tahimik ang tunay na panganib kaysa sa nawawalang file: gumagana ang model batay sa lossy summary at hindi nito namamalayang kailangan nitong hilingin ang orihinal. Iyon ang sinusukat ng 86.5% quality-retained figure sa SWE-bench Lite.
Bakit umaabot ng labinlimang segundo ang unang request ko?
Nilo-load ang embedding model sa likod ng tool filter sa unang request sa halip na sa startup. Tinutukoy ng project ang warm-up na 10 hanggang 15 segundo, at humigit-kumulang 15 ms bawat call pagkatapos nito. Magpadala ng isang throwaway request gamit ang curl pagkatapos simulan ang proxy, upang hindi maantala ang unang totoong agent turn.
Dapat ko bang gamitin ang hosted GPU server sa halip na mag-self-host?
Inaalis nito ang gastos sa GPU rent at maintenance, na nagkakahalaga ng $0.30 bawat milyong naprosesong token noong August 2026. Ipinapadala rin nito sa third party ang iyong prompts at ang mga file na binabasa ng agent bago makarating ang mga ito sa model provider mo. Kung nagse-self-host ka upang manatili ang code sa infrastructure na kontrolado mo, binabawi ng setting na iyon ang dahilan kung bakit ka nagsimula. Sa self-hosting, nananatili sa sarili mong box ang context at provider API key.