Paritok token gateway: Mas mura ba ang agent bills?

Ano ang ginagawa ng Paritok sa isang request

Ang Paritok ay isang token gateway: isang proxy na nasa pagitan ng coding agent mo at ng model API, at nagko-compress ng bawat request bago ito ipasa. Nakikipag-ugnayan ang agent mo sa http://127.0.0.1:8080 sa halip na direkta sa provider. Binabago 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 ang ibig sabihin ay mas maliit na invoice. Iyan ang buong ideya. Iba ito sa claim na "mas tatagal ang iyong context", at ito ang dahilan kung bakit interesante ang tool na ito sa halip na isa lamang itong maayos na optimization.

Bata 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 aktuwal na coding-agent trajectory.

Bakit hindi ito context trimming

Nagbubura 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. Kinukuha muli ng model ang isang segment sa pamamagitan ng pagtawag sa read_original o expand_context. Binabago nito ang uri ng failure. Nabibigo ang trimmer dahil nakakalimot ito, at hindi nito ipinapaalam sa iyo. Nabibigo naman ang compressor dahil nagbibigay ito sa model ng lossy summary, at maaaring hilingin ng model ang orihinal kapag hindi sapat ang summary.

Ganoon din kumikilos ang tool filter. Ginagawang stub ang mga na-filter na tool schema sa halip na alisin, at kinukuha muli 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 may task na tahimik na nagkamali.

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 na naka-attach, tinatayang 29,000 token ang block na ito ng project. Ini-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 tinatayang 8,000 token. 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 nirerewrite sa 25.7% ng orihinal na laki. Dito nagmumula ang headline na 74%. Basahin ito nang mabuti: ang 74% ay compression rate para sa content na kino-compress, hindi ang bawas sa bill mo.

Ang ikatlong lever ay history summarization. Kapag napuno ang context budget, sine-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. Ibinibigay sa iyo ng pip install "paritok[toolselect]" ang tool filter sa isang ordinaryong CPU VPS, at ito ang kalahati ng product na walang buwanang gastos. Subukan muna ito bago umarkila ng card.

Ano ang sinukat ng proyekto, at kaninong harness

[
  {
    "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 mga sariling inilathalang figure ng proyekto, na sinukat gamit ang sarili nitong harness laban sa SWE-bench Lite. Kino-compress ng Paritok-4B-v1 ang content sa 25.7% ng orihinal na laki habang napapanatili ang 86.5% ng uncompressed solve rate. Kapag gpt-5 ang ginamit bilang compressor, mas maraming quality ang napapanatili, 93.6%, pero kino-compress lamang nito ang content sa 61.9%, kaya magbabayad ka 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 hindi nasolve ng compressed runs kahit nasolve ng uncompressed runs—halos isa sa bawat pito. Sa benchmark, numero lang ito sa isang table. Sa repository mo, isa itong task na kailangan mong patakbuhin nang dalawang beses.

[
  {
    "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 natitipid habang tumatagal ang session dahil naiipon ang history, at ang history ang kino-compress. Iniulat ng proyekto ang humigit-kumulang 25% na natitipid 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 token bawat turn, bandang turn 8 hanggang 12, dahil kapag puno na ang context, hindi na lumalaki ang history. Ang madalas sipiing "lampas 85%" na figure ay tumutukoy sa mga session na saturated na ang context. Ito ang pinakamagandang sitwasyon, kaya huwag kang magplano batay rito.

Nagbabayad ba ang 24GB GPU para sa Paritok?

Ang 24 GB card ang karaniwang rental unit para sa model na ganito kalaki. Noong 7 August 2026, ang median na naka-publish na on-demand rate para sa RTX 4090 na may 24 GB ay $0.44 kada oras, at ang pinakamurang listings ay nasa humigit-kumulang $0.20. Gamitin natin ang $0.44. Kung patuloy itong tatakbo buong buwan, 730 oras iyon, kaya $321. Kung gagamitin lamang sa oras ng trabaho, 8 oras bawat araw sa loob ng 22 araw, 176 oras iyon, kaya $77.

Ngayon, i-convert natin ang nabawas na tokens sa natipid na halaga. Input tokens lamang ang naaapektuhan ng reduction. Dumadaan sa proxy ang output tokens nang walang pagbabago, kaya hindi nagbabago ang mga ito. Ipagpalagay na 80% ng kabuuang halaga mo ay mula sa input tokens, na karaniwan para sa isang coding agent, at i-check ang palagay na ito laban sa sarili mong bill. Ang dollar saving mo ay ang token reduction na minultiply sa 0.8.

[
  {
    "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 matitira sa iyo. Dahil dito, mababawi ng card ang gastos nito kapag lumampas sa humigit-kumulang $472 ang buwanang agent spend mo kung patuloy na naka-on ang card, o humigit-kumulang $114 kung ihihinto mo ang instance sa labas ng oras ng trabaho. Sa turn-20 figure na 63%, magiging $637 at $154 ang mga halagang ito. Sa turn-5 figure na 39%, na siyang karaniwang nakikita sa maiikling session, kailangan mo ng humigit-kumulang $1,030 bawat buwan bago maging sulit rentahan ang card.

May 2 bagay na nagpapaganda sa resulta kumpara sa ipinapakita ng table. Hindi kailangan ng model ng 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 mayroon ka nang GPU box na ginagamit para sa ibang gawain, bababa ang bawat numero sa chart na iyon. Ang paghinto sa instance kapag walang nagco-code ang pinakamalaking lever dito, dahil nababawasan nito nang humigit-kumulang tatlong-kapat ang renta.

May 1 bagay na nagpapasama sa resulta. Totoong computation ang compression pass. Bawat token na kino-compress ng 4B model ay kailangan nitong basahin at pagkatapos ay isulat, kaya nadaragdagan ang latency sa bawat agent turn. Sa card na binabayaran kada oras, lumalabas ang gastos na ito bilang oras ng paghihintay, hindi bilang hiwalay na item sa invoice. Dahil dito, madaling hindi ito mapansin hanggang maramdaman mo na ang epekto.

Kung ikinukumpara mo sa pangkalahatan ang rented GPU hours sa API tokens, ginagawa ng break-even sa pagitan ng GPU VPS at API tokens ang parehong arithmetic para sa mismong inference.

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. Kapag ganoon kabilis gumalaw ang project, maaaring magpalit ng config key sa pagitan ng mga release. Ang simpleng pip install paritok, o isang git clone ng main, ay magbibigay sa iyo ng ibang gateway sa susunod na linggo at walang mag-iiwan ng tala kung alin ang nag-produce ng mga numerong sinukat mo.

Ang default backend ay Ollama. 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-v1

Ilagay ang paritok.yaml katabi nito. Ang use_gpu_server: false ang nagpapanatili na sa sarili mong hardware ginagawa ang compression.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

Ang 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. I-check ang proxy bago mo ituro rito ang isang agent.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

Nagbabalik ang /health ng maliit na JSON object na naglalaman ng "status":"ok" at isang version string. Nagbabalik ang /stats ng compression totals at sariling estimate ng proxy kung magkano ang natipid nito. Ituring ang estimate na ito bilang pagsusuri ng proxy sa sarili nitong trabaho, at i-confirm ito sa usage page ng iyong provider.

Para sa throughput sa halip na convenience, sini-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 8000

Mas 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 parehong machine. Ang praktikal na pagkakaiba ng Ollama at vLLM ang magpapasya kung alin ang gagamitin mo rito.

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:8080

Hindi pinapansin ng Codex CLI ang OPENAI_BASE_URL, kaya isinusulat ng project ang ~/.codex/config.toml para sa iyo kapag naka-set ang codex.enabled: true sa paritok.yaml. Kapag in-export mo lang ang variable, direktang kumokonekta 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 sa upstream ang API key ng iyong provider. Kaya ang proxy na reachable mula sa internet ay open relay para sa key na iyon. Ang sinumang makahanap ng port ay maaaring gumastos gamit ang account mo kahit hindi niya nakikita ang key. I-access ito mula sa laptop sa pamamagitan ng SSH tunnel o VPN sa halip na buksan ang port.

Patakbuhin ito sa ilalim ng systemd para manatili itong gumagana matapos ang reboot. I-adjust ang mga path ayon 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.target

I-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 may maling path sa config file. Ipinapakita ng journalctl -u paritok -n 50 ang dahilan.

Ang hosted option, at ang kapalit nito

Ibinebenta rin ng project ang compression bilang isang service. I-set ang use_gpu_server: true gamit ang API key, at tatakbo ang 4B model sa hardware nito sa halagang $0.30 bawat isang milyong naprosesong token. Ayon sa sarili nitong documentation, libre ito hanggang sa katapusan ng August 2026. Inaalis nito ang gastos sa GPU rental at ang lahat ng operations work na nabanggit sa itaas.

Nangangahulugan din ito na lalabas sa machine mo ang prompts at 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 i-set ang flag na iyon, dahil isang linya lang ang kailangang baguhin sa flag ngunit hindi ganoon kasimple ang magiging epekto nito.

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 ang input tokens, cache-read tokens, at output tokens bilang magkakahiwalay na linya mula sa usage page ng provider mo, hindi bilang isang kabuuang halaga sa dolyar.
• Sa susunod na linggo, patakbuhin ang proxy sa harap at gawin ang parehong uri ng trabaho.
• Ihambing ang mga linya para sa input at cache-read. Dapat halos hindi magbago ang output dahil walang nagko-compress nito. Kung malaki ang ipinagbago ng output, may iba pang nagbago bukod sa proxy.
• Bilangin ang mga task na kinailangan mong ulitin. Ito ang bahagi ng tradeoff na nauugnay sa kalidad, at walang dashboard saanman ang nag-uulat nito.
• Idagdag ang GPU hours sa week two bago ihambing ang mga total.

Mahalagang paghiwalayin ang input sa output dahil magkaiba ang presyo ng mga ito at isa lamang sa mga ito ang naaabot ng compressor. Noong August 2026, nagkakahalaga ang Claude Sonnet 4.6 ng $3 bawat milyong input tokens at $15 bawat milyong output tokens, habang ang prompt-cache read ay 10% ng input rate, o $0.30 bawat milyong tokens. Ang agwat sa gastos ng input at output tokens ang nagpapasya 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.

Partikular na pinapalubha ng prompt caching ang pagkukuwenta para sa tool filter. Nasa unahan ng request ang tool block, kaya pagkatapos ng unang turn, karaniwan itong cache hit na sinisingil sa 10% ng presyo ng input. Kapag nagbawas ng 21,000 tokens mula sa naka-cache na block, 21,000 tokens ang natitipid sa halagang $0.30 bawat milyon, o humigit-kumulang $0.006 bawat turn, sa halip na $0.063 na ipapahiwatig ng uncached rate. Pinananatiling hindi nagbabago ng proyekto ang filtered block sa buong session upang hindi magbago ang naka-cache na prefix. Kung pipiliang muli ng tools ang isang filter sa bawat turn, mava-void nito ang prefix at mas malaki ang gagastusin 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, at dahil July 2026 ang petsa ng mga unang tag, napakakaunti pa ng operational history ng code. Ang compression rate at ang figure para sa napanatiling kalidad ay parehong sinukat ng partidong makikinabang kung maganda ang mga ito. Hindi ibig sabihin nito na mali ang mga ito. Ibig sabihin, hindi pa nakukumpirma ang mga ito, kaya dapat iba ang pagtingin mo sa mga numerong ito kumpara sa numerong ikaw mismo ang gumawa.

May isang documented behaviour na dapat mong malaman bago sisihin ang setup mo. Ang embedding model na ginagamit ng tool filter ay naglo-load sa unang request, hindi sa startup. Kaya nagdo-document ang project ng warm-up na 10 hanggang 15 segundo, at humigit-kumulang 15 ms bawat call pagkatapos nito. Magpadala ng isang throwaway request matapos magsimula ang proxy para hindi magmukhang nag-hang ang unang totoong agent turn.

Apat na bagay ang maaari mong i-verify 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 puwesto nito kasabay ng 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 magkaiba ang problemang nilulutas ng dalawang tool at maaari silang pagsabayin, 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 agent sa isang VPS ang ilang pagbabagong walang gastos at maaari mong subukan muna.

FAQ

Binabawasan ba ng Paritok ang API bill ko, o context usage lang?

Binabawasan nito ang bill dahil nire-rewrite ng proxy ang request bago ito makarating sa provider, at sinisingil ng provider ang 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 marami pang natitirang espasyo. Gumagana rin ang mas maliit na card, at mas pabor sa iyo ang break-even calculation. Walang GPU na kailangan ang tool-schema filter: ginagamit nito ang BAAI/bge-small-en-v1.5, isang 130 MB embedding model na tumatakbo sa CPU. I-install ang paritok[toolselect] sa isang ordinaryong VPS para makuha ang tool-block reduction kapalit ng kaunting RAM.

Ano ang mangyayari kung may alisin ang compressor na kailangan ng agent?

Walang inaalis. Ang compressed segments ay may [REF:id] tag, 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 mula sa lossy summary at hindi nito namamalayan na dapat nitong hilingin ang original. Ito ang sinusukat ng 86.5% quality-retained figure sa SWE-bench Lite.

Bakit inaabot 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. Idinodokumento 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, para hindi ma-stall 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 rental at maintenance, na nagkakahalaga ng $0.30 bawat milyong tokens na na-process 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. Kung nagse-self-host ka para mapanatili ang code sa imprastrakturang kontrolado mo, sinisira ng setting na ito ang dahilan kung bakit ka nagsimula. Sa self-hosting, nananatili sa sarili mong machine ang context at provider API key.