द्वारे Matt Connor 2026-08-07 · अपडेटेड 2026-08-30

Paritok token gateway: coding agent चा खर्च कमी होतो का?

Q: Compressor ने agent ला आवश्यक असलेली एखादी गोष्ट काढून टाकली तर काय होते?

काहीही काढून टाकले जात नाही. Compressed segments मध्ये [REF:id] tag असतो आणि model read_original किंवा expand_context वापरून पूर्ण text पुन्हा मिळवतो. Filter केलेले tool schemas delete करण्याऐवजी stub केले जातात आणि model gateway_search_tools वापरून त्यांपैकी एक पुन्हा मिळवतो. प्रत्यक्ष धोका missing file पेक्षा सूक्ष्म आहे: model lossy summary वर काम करतो आणि त्याला original मागणे आवश्यक आहे हे कधीच लक्षात येत नाही. SWE-bench Lite वरील 86.5% quality-retained हा आकडा हाच परिणाम मोजतो.

Paritok file reads आणि tool output compress करून provider कडे जाणारे tokens कमी करते. प्रकल्पाचा दावा 74% कपातीचा आहे; यंत्रणा आणि break-even गणित पाहा.

Paritok विनंतीवर काय परिणाम करते

Paritok हा token gateway आहे: तो तुमच्या coding agent आणि model API यांच्या दरम्यान बसणारा proxy आहे आणि प्रत्येक विनंती पुढे पाठवण्यापूर्वी ती compress करतो. तुमचा agent provider ऐवजी http://127.0.0.1:8080 शी संवाद साधतो. हा proxy tool schemas, file reads, tool output आणि जुन्या turns चे पुनर्लेखन करतो, लहान payload upstream कडे पाठवतो आणि मिळालेले उत्तर कोणताही बदल न करता परत देतो.

Provider कडे जे पोहोचते त्यासाठीच तो तुमच्याकडून शुल्क आकारतो. त्यामुळे लहान payload म्हणजे कमी invoice. हीच संपूर्ण संकल्पना आहे. "तुमचा context अधिक काळ टिकतो" या दाव्यापेक्षा हे वेगळे आहे. म्हणूनच हे tool केवळ configuration नीट ठेवणारे साधन न राहता उपयुक्त ठरते.

हा project अद्याप सुरुवातीच्या टप्प्यात आहे. त्याचे पहिले public tags July 2026 दिनांकाचे आहेत आणि सध्याचा tag v1.3.0 असून त्याची तारीख 5 August 2026 आहे. Weights आणि gateway code Apache 2.0 अंतर्गत उपलब्ध आहेत. Compression model हा Qwen3-4B-Instruct-2507 वर आधारित LoRA (low-rank adaptation) adapter आहे. तो real coding-agent trajectories मधून घेतलेल्या 45,000 teacher-distilled samples वर train केला आहे.

हे context trimming का नाही

Trimming मध्ये मजकूर हटवला जातो. Agent त्याच्या context limit जवळ पोहोचल्यावर सर्वांत जुन्या turns काढून टाकतो. त्यामुळे turn 3 मध्ये त्याने वाचलेली file नष्ट होते. turn 20 मध्ये ती file पुन्हा आवश्यक असल्यास, तो ती file पुन्हा वाचतो आणि त्या tokens साठी दुसऱ्यांदा खर्च होतो. झालेली बचत ही प्रत्यक्षात उधार असते.

Paritok एखादा segment त्याच्या लहान स्वरूपाने आणि [REF:id] tag ने बदलतो आणि पूर्ण text proxy वर ठेवतो. Model read_original किंवा expand_context कॉल करून तो segment पुन्हा मिळवतो. त्यामुळे अपयशाचा प्रकार बदलतो. Trimmer विसरतो आणि तुम्हाला कधीच सांगत नाही. Compressor model ला lossपूर्ण summary देतो; summary पुरेशी नसल्यास model मूळ मजकूर मागवू शकतो.

Tool filter देखील याच प्रकारे काम करतो. Filter केलेले tool schemas काढून टाकण्याऐवजी stub केले जातात आणि model gateway_search_tools कॉल करून त्यांपैकी एखादा पुन्हा मिळवू शकतो. हे महत्त्वाचे आहे. एखादे tool कायमचे लपवणारा filter तुमचा agent काय करू शकतो हे बदलतो. आणि एखादे task शांतपणे चुकीचे पूर्ण झाल्यावरच तुम्हाला त्याची माहिती मिळते.

तीन उपाय आणि त्यापैकी विनामूल्य कोणता

पहिला उपाय म्हणजे tool-schema filter. प्रत्येक request मध्ये संपूर्ण tools array असतो. काही MCP (model context protocol) servers जोडलेल्या Claude Code turn मध्ये हा block सुमारे 29,000 tokens इतका असतो, असे project मोजते. हा filter BAAI/bge-small-en-v1.5 या 130 MB embedding model च्या मदतीने user request आणि प्रत्येक tool description चे embedding तयार करतो, जुळणारी tools ठेवतो आणि उर्वरित tools साठी stubs तयार करतो. त्यामुळे block सुमारे 8,000 tokens पर्यंत कमी होतो. हे embedding model CPU वर चालते.

दुसरा उपाय म्हणजे content compression. यासाठी GPU वर 4B model आवश्यक आहे. File reads, tool output आणि history यांचा मूळ आकाराच्या 25.7% पर्यंत संक्षेप केला जातो. 74% हा headline याच प्रक्रियेतून येतो. हे काळजीपूर्वक समजा: 74% हा संक्षेप केला जाणाऱ्या content वरील compression rate आहे; तो तुमच्या bill मधील कपात नाही.

तिसरा उपाय म्हणजे history summarization. Context budget पूर्ण झाल्यावर recent window च्या पलीकडील turns चा सारांश तयार केला जातो. त्यामुळे session limit ला पोहोचून थांबत नाही आणि दीर्घकाळ चालू राहते.

फक्त दुसऱ्या उपायासाठी GPU आवश्यक आहे. या पृष्ठावरील हे सर्वात उपयुक्त वाक्य आहे. pip install "paritok[toolselect]" तुम्हाला सामान्य CPU VPS वर tool filter देते आणि दर महिन्याला कोणताही खर्च न लागणारा product चा अर्धा भाग उपलब्ध करून देते. Card भाड्याने घेण्यापूर्वी हे वापरून पाहा.

प्रकल्पाने काय मोजले आणि कोणत्या harness वर

ChartSWE-bench Lite: compression rate against solve quality retained (project's published figures)

label

compressed_to_pct

quality_retained_pct

Paritok-4B-v1

25.7

86.5

gpt-4.1-mini

50.2

85.6

gpt-5

61.9

93.6

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
  }
]

ही प्रकल्पाने स्वतः प्रकाशित केलेली आकडेवारी आहे. ती SWE-bench Lite विरुद्ध प्रकल्पाच्या स्वतःच्या harness वर मोजली आहे. Paritok-4B-v1 मजकूर मूळ आकाराच्या 25.7% पर्यंत संकुचित करते आणि असंकुचित solve rate पैकी 86.5% राखते. Compressor म्हणून gpt-5 वापरल्यास अधिक गुणवत्ता, 93.6%, राखली जाते; मात्र मजकूर केवळ 61.9% पर्यंत संकुचित होतो. म्हणजे frontier prices वाचवण्यासाठी तुम्हाला frontier prices द्यावे लागतील.

गुणवत्तेच्या स्तंभाचा प्रामाणिकपणे अर्थ लावा. solve rate पैकी 86.5% राखला जातो याचा अर्थ असंकुचित runs ने सोडवलेल्या समस्या compressed runs मध्ये अपयशी ठरल्या; म्हणजे जवळपास सातपैकी एक solve अपयशी ठरला. Benchmark मध्ये हा तक्त्यातील एक आकडा आहे. तुमच्या repository मध्ये मात्र हे तुम्ही दोनदा चालवावे लागणारे task आहे.

ChartReported input-token saving as a session grows (project's own harness)

label

saved_pct

Turn 1

Turn 5

Turn 12

Turn 20

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
  }
]

Session चालू राहिल्याने end-to-end बचत वाढते, कारण history साठत जाते आणि संकुचित केले जाणारे घटक म्हणजे historyच असते. प्रकल्पाच्या अहवालानुसार single turn वर सुमारे 25% बचत होते, turn 5 पर्यंत 39% आणि turn 20 पर्यंत 63% बचत होते. ही वाढ कुठे थांबते हेही अहवालात नमूद आहे: 200,000 token budget वर प्रति turn absolute saving सुमारे 48,000 tokens इतकी स्थिर होते, साधारण turn 8 ते 12 च्या आसपास. कारण context पूर्ण झाल्यावर history वाढत नाही. वारंवार उद्धृत केलेला "past 85%" हा आकडा context-saturated sessions साठी आहे. ही सर्वोत्तम परिस्थिती आहे; त्यामुळे तुमचे नियोजन त्यावर आधारित करू नका.

24GB GPU चा Paritok साठी खर्च वसूल होतो का?

या आकाराच्या मॉडेलसाठी 24 GB कार्ड हे नेहमी भाड्याने घेतले जाणारे युनिट आहे. 7 August 2026 रोजी उपलब्ध असलेल्या प्रकाशित on-demand दरांनुसार, 24 GB असलेल्या RTX 4090 चा मध्य दर प्रति तास $0.44 होता. सर्वात स्वस्त listings जवळपास $0.20 प्रति तास होत्या. आपण $0.44 हा दर धरू. संपूर्ण महिना सुरू ठेवले, तर 730 तास होतात आणि खर्च $321 येतो. फक्त कामाच्या वेळेत, दिवसाला 8 तास आणि 22 दिवस चालवले, तर 176 तास होतात आणि खर्च $77 येतो.

आता token मध्ये झालेली घट डॉलरमधील बचतीत रूपांतरित करा. ही घट input tokens वर लागू होते. Output tokens proxy मधून कोणताही बदल न होता जातात, त्यामुळे त्यांच्या संख्येत किंवा खर्चात बदल होत नाही. तुमच्या एकूण डॉलर खर्चापैकी input tokens चा वाटा 80% आहे असे गृहीत धरा. Coding agent साठी हे प्रमाण सामान्य आहे. तुमच्या स्वतःच्या बिलाशी हे गृहीतक पडताळा. त्यानंतर डॉलरमधील बचत म्हणजे token reduction ला 0.8 ने गुणणे.

ChartMonthly agent bill needed before a $0.44/hour 24GB card pays for itself

label

bill_always_on_usd

bill_workday_only_usd

Turn 5 (39% saved)

1,030

248

Turn 20 (63% saved)

637

154

Saturated (85% saved)

472

114

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
  }
]

सत्र पूर्ण भरलेल्या स्थितीतील 85% आकड्यानुसार, तुमच्या बिलातील 68% रक्कम वाचते. त्यामुळे सतत सुरू ठेवलेले कार्ड तुमचा मासिक agent खर्च सुमारे $472 पेक्षा जास्त झाल्यावर स्वतःचा खर्च वसूल करते. कामाच्या वेळेबाहेर instance बंद केल्यास हा उंबरठा सुमारे $114 असतो. turn-20 मधील 63% आकड्यानुसार हेच उंबरठे अनुक्रमे $637 आणि $154 होतात. turn-5 मधील 39% आकडा लहान सत्रांचे प्रत्यक्ष स्वरूप दर्शवतो. त्या वेळी कार्ड भाड्याने घेणे योग्य ठरण्यापूर्वी तुमचा मासिक खर्च सुमारे $1,030 असणे आवश्यक आहे.

तक्त्यात दिसते त्यापेक्षा हा पर्याय चांगला ठरण्याची दोन कारणे आहेत. मॉडेलला 24 GB आवश्यक नाही. q4 build सुमारे 2.5 GB आणि bf16 build सुमारे 8 GB आहे. त्यामुळे लहान कार्ड वापरल्यास किंवा इतर कामासाठी तुम्ही आधीपासून चालवत असलेल्या GPU box वर हे मॉडेल चालवल्यास तक्त्यातील प्रत्येक रक्कम कमी होते. तसेच कोणी coding करत नसताना instance बंद करणे हा सर्वात प्रभावी उपाय आहे. त्यामुळे भाड्याचा खर्च सुमारे तीन-चतुर्थांशाने कमी होतो.

एक कारण हा पर्याय अधिक महाग ठरवते. Compression pass साठी प्रत्यक्ष संगणकीय काम लागते. 4B model ज्या प्रत्येक token चे compression करते, तो token मॉडेलला आधी वाचावा आणि नंतर लिहावाही लागतो. त्यामुळे प्रत्येक agent turn साठी latency वाढते. तासाच्या हिशोबाने भाड्याने घेतलेल्या कार्डावर हा खर्च invoice वरील स्वतंत्र रक्कम म्हणून दिसत नाही; तो प्रतीक्षेच्या स्वरूपात दिसतो. त्यामुळे प्रत्यक्ष विलंब जाणवेपर्यंत तो सहज लक्षात येत नाही.

सामान्यतः rented GPU hours आणि API tokens यांपैकी निवड करत असाल, तर GPU VPS आणि API tokens यांच्यातील break-even inference साठीही हाच हिशोब करते.

VPS वर Paritok gateway चालवणे

Python 3.10 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. Ubuntu 24.04 मध्ये Python 3.12 समाविष्ट आहे. त्यामुळे CPU-only भागासाठी साधी VPS image पुरेशी आहे.

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"

आवृत्ती निश्चित करा. Repository ने 29 July 2026 रोजी v1.2.8 आणि 5 August 2026 रोजी v1.3.0 tag केली. या वेगाने बदलणाऱ्या project मध्ये releases दरम्यान config keys ची नावे बदलू शकतात. साधे pip install paritok किंवा main चे git clone वापरल्यास पुढील आठवड्यात वेगळे gateway मिळू शकते. तसेच तुम्ही मोजलेले numbers कोणत्या आवृत्तीने तयार केले, याची नोंद राहत नाही.

Default backend Ollama आहे. Model pull करा. त्यानंतर proxy शोधत असलेले short name त्याला द्या.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

Local model compress केलेल्या प्रत्येक segment साठी rewrite लिहितो. त्यामुळे compression pass बराच वेळ चालल्यास agent turn अडकल्यासारखा दिसतो. Ollama मधील output length साठीचा num_predict cap ही मर्यादा निश्चित करणारी setting आहे.

त्याच्या बाजूला paritok.yaml लिहा. use_gpu_server: false मुळे compression तुमच्या स्वतःच्या hardware वरच चालते.

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

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

वरील सर्व प्रक्रियांसाठी paritok up हा shortcut आहे. Model उपलब्ध नसल्यास तो pull करतो आणि port 8080 वर proxy सुरू करतो. Agent ला proxy कडे निर्देशित करण्यापूर्वी proxy तपासा.

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

/health मध्ये "status":"ok" आणि version string असलेला छोटा JSON object मिळतो. /stats compression totals आणि proxy ने वाचवलेल्या प्रमाणाचा स्वतःचा अंदाज परत करते. त्या अंदाजाला proxy ने स्वतःच्या कामाचे केलेले मूल्यमापन समजा. तो तुमच्या provider च्या usage page वरील आकडेवारीशी पडताळा.

सुलभतेपेक्षा throughput महत्त्वाचा असल्यास vLLM base model वर adapter serve करते.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama सुरू करणे अधिक सोपे आहे. Concurrent requests हाताळण्यात vLLM अधिक सक्षम आहे. एकापेक्षा जास्त agents एकाच box चा वापर करू लागल्यावर हे महत्त्वाचे ठरते. Ollama आणि vLLM मधील व्यावहारिक फरक यापैकी योग्य पर्याय ठरवतो.

Base URL environment variables वापरून agent ला proxy कडे निर्देशित करा.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI OPENAI_BASE_URL दुर्लक्षित करते. त्यामुळे paritok.yaml मध्ये codex.enabled: true सेट असल्यास project तुमच्यासाठी ~/.codex/config.toml लिहितो. Variable स्वतंत्रपणे export केल्यास Codex थेट provider शी बोलत राहतो. याचे लक्षण म्हणजे काम करताना /stats counter मध्ये कधीही वाढ होत नाही.

Listener 127.0.0.1 वरच ठेवा; 0.0.0.0 वर कधीही ठेवू नका. Proxy तुमचा provider API key upstream कडे forward करते. त्यामुळे इंटरनेटवरून पोहोचता येणारा proxy त्या key साठी open relay ठरतो. Port शोधणारी कोणतीही व्यक्ती key स्वतः न पाहताही तुमचे पैसे खर्च करू शकते. Port उघडण्याऐवजी SSH tunnel किंवा VPN द्वारे laptop वरून proxy पर्यंत पोहोचा.

Reboot नंतरही तो चालू राहण्यासाठी systemd अंतर्गत चालवा. तुमच्या install शी जुळण्यासाठी paths बदला.

[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

sudo systemctl enable --now paritok वापरून ते enable करा. त्यानंतर पुन्हा /health curl करा. सुरू होऊन लगेच बंद होणारे unit सामान्यतः config file path चुकीचा असल्याचे दर्शवते. journalctl -u paritok -n 50 कारण दाखवते.

होस्ट केलेला पर्याय आणि त्याची किंमत

प्रकल्प compression ही सेवा म्हणूनही उपलब्ध करून देतो. use_gpu_server: true API key सह सेट केल्यास 4B model त्याच्या hardware वर चालतो. त्याची किंमत प्रक्रिया केलेल्या प्रति million tokens मागे $0.30 आहे. त्याच्या documentation नुसार ऑगस्ट 2026 अखेरपर्यंत ही सेवा विनामूल्य आहे. त्यामुळे GPU rent आणि वर वर्णन केलेले सर्व operations work टाळता येते.

मात्र याचा अर्थ असा आहे की तुमचे prompts आणि तुमचा agent वाचत असलेल्या files तुमच्या machine मधून बाहेर पडतात आणि तुमच्या model provider पर्यंत पोहोचण्यापूर्वी third party कडे जातात. नेमका हा hop टाळण्यासाठी self-hosting वापरले जाते. use_gpu_server: true flag सेट करण्यापूर्वी तुम्ही या दोन्हीपैकी कोणत्या बाबीला प्राधान्य देत आहात ते ठरवा. flag मध्ये एकाच ओळीचा बदल करावा लागतो, परंतु त्याचे परिणाम तसे मर्यादित नसतात.

तुमच्या वापरासाठी आधी आणि नंतरचे मोजमाप कसे करावे

प्रकाशित आकडे हे प्रकल्पाचे आकडे आहेत. ते प्रकल्पाच्या harness मधून, SWE-bench Lite वर मिळवलेले आहेत. तुमचा repository SWE-bench Lite नाही. तुमच्या वापराचे मोजमाप करा.

proxy मार्गात नसताना एक सामान्य आठवडा काम करा. तुमच्या provider च्या usage page वरून input tokens, cache-read tokens आणि output tokens स्वतंत्र ओळींमध्ये नोंदवा. त्यांना एकूण dollar रकमेप्रमाणे नोंदवू नका.
पुढील आठवडा proxy समोर ठेवून, त्याच प्रकारचे काम करा.
input आणि cache-read या ओळींची तुलना करा. output साधारण स्थिर असावा, कारण तो compress होत नाही. output मध्ये मोठा बदल झाला असल्यास proxy व्यतिरिक्त काहीतरी बदलले आहे.
पुन्हा करावी लागलेली tasks मोजा. हा या trade-off मधील quality चा भाग आहे आणि कोणताही dashboard त्याचा अहवाल देत नाही.
totals ची तुलना करण्यापूर्वी week two मध्ये GPU hours जोडा.

input आणि output वेगळे नोंदवणे महत्त्वाचे आहे, कारण त्यांचे दर खूप वेगळे आहेत आणि compressor त्यांपैकी फक्त एकावर परिणाम करतो. August 2026 पर्यंत, Claude Sonnet 4.6 साठी दर प्रति million input tokens $3 आणि प्रति million output tokens $15 आहे. prompt-cache read साठी input rate च्या 10% दराने, म्हणजे प्रति million $0.30 आकारले जातात. input आणि output token cost मधील फरक यावरून input-side compressor तुमच्यासाठी उपयुक्त आहे की नाही हे ठरते. Claude Code चे tokens प्रत्यक्षात कुठे खर्च होतात तुमच्या context मधील कोणता भाग compress करण्याइतका मोठा आहे हे दाखवते.

Prompt caching मुळे विशेषतः tool-filter arithmetic अधिक गुंतागुंतीचे होते. tool block request च्या सुरुवातीला असतो. त्यामुळे पहिल्या turn नंतर तो साधारणपणे input price च्या 10% दराने cache hit असतो. cached block मधून 21,000 tokens कमी केल्यास $0.30 प्रति million या दराने प्रत्येक turn ला 21,000 tokens ची बचत होते, म्हणजे सुमारे $0.006. Uncached rate नुसार दिसणारी $0.063 इतकी बचत होत नाही. cached prefix बदलू नये म्हणून project session दरम्यान filtered block अपरिवर्तित ठेवतो. प्रत्येक turn ला tools पुन्हा निवडणारा filter हा prefix invalidate करेल आणि झालेल्या बचतीपेक्षा जास्त खर्च निर्माण करेल.

काय अजून पडताळलेले नाही

वरील प्रत्येक कार्यप्रदर्शनाचा आकडा प्रकल्पानेच दिलेला आहे. SWE-bench Lite परिणामांची स्वतंत्र पुनरुत्पत्ती झालेली नाही. तसेच, पहिले tags July 2026 मध्ये दिनांकित असल्याने या code मागे operational history देखील फारच कमी आहे. Compression rate आणि quality-retained figure हे दोन्ही आकडे ते चांगले दिसल्यास ज्याला फायदा होतो, त्याच पक्षाने मोजले आहेत. त्यामुळे ते चुकीचे आहेत असे होत नाही. मात्र ते अद्याप अपुष्ट आहेत. तुम्ही स्वतः तयार केलेल्या आकड्यांपेक्षा त्यांच्याकडे वेगळ्या प्रकारे पाहिले पाहिजे.

तुमच्या setup ला दोष देण्यापूर्वी एक documented behaviour लक्षात घ्या. Tool filter द्वारे वापरले जाणारे embedding model startup वेळी न लोड होता पहिल्या request वेळी load होते. त्यामुळे प्रकल्पाच्या documentation नुसार सुरुवातीला 10 ते 15 seconds चा warm-up लागतो. त्यानंतर प्रत्येक call सुमारे 15 ms मध्ये पूर्ण होतो. Proxy सुरू झाल्यावर एक throwaway request पाठवा. त्यामुळे पहिला प्रत्यक्ष agent turn अडकलेला दिसणार नाही.

एका दुपारी तुम्ही स्वतः चार गोष्टी निश्चित करू शकता: proxy सुरू होतो आणि चालू राहतो का, काम करताना /stats बदलतो का, तुमच्या provider मधील input-token line प्रत्यक्षात कमी होते का, आणि agent तरीही काम पूर्ण करतो का. तुमच्या setup साठी हे निष्कर्ष कोणत्याही published benchmark पेक्षा अधिक उपयुक्त ठरतील.

हे तुमच्या इतर tooling च्या तुलनेत कुठे बसते याबद्दल: self-hosted LiteLLM gateway request चे contents न बदलता त्यांना route आणि meter करते. त्यामुळे दोन्ही वेगवेगळ्या समस्या सोडवतात आणि त्यांना chain करता येते. यात Paritok agent च्या सर्वात जवळ राहतो. खरा उद्देश या विशिष्ट tool ऐवजी bill कमी करणे हा असेल, तर VPS वरील agent साठी cost controls चा व्यापक संच आधी करून पाहण्यासाठी कोणताही खर्च न लागणारे अनेक बदल समाविष्ट करतो.

FAQ

Paritok माझे API बिल कमी करते की फक्त context वापर कमी करते?

हे बिल कमी करते, कारण proxy provider पर्यंत पोहोचण्यापूर्वी request पुन्हा लिहितो आणि provider ला मिळालेल्या डेटासाठी शुल्क आकारले जाते. या कपातीचे प्रमाण headline मधील दाव्यापेक्षा कमी आहे. 74% हा आकडा compress केलेल्या content वरील compression rate दर्शवतो. End to end, project नुसार single turn मध्ये सुमारे 25% आणि turn 20 पर्यंत 63% कपात होते; तसेच फक्त input tokens मध्येच बदल होतो. Output tokens कोणताही बदल न होता पुढे पाठवले जातात.

Compression model self-host करण्यासाठी मला किती GPU आवश्यक आहे?

q4 build सुमारे 2.5 GB आणि bf16 build सुमारे 8 GB आहे. त्यामुळे model 24 GB card मध्ये मोठी मोकळी जागा शिल्लक ठेवून बसतो. त्यापेक्षा लहान card देखील चालतो आणि त्यामुळे break-even arithmetic तुमच्या बाजूने बदलते. Tool-schema filter साठी GPU ची अजिबात गरज नाही. तो BAAI/bge-small-en-v1.5 वापरतो. हे 130 MB चे embedding model CPU वर चालते. सामान्य VPS वर paritok[toolselect] install करा. त्यामुळे थोड्या RAM च्या खर्चात tool-block reduction मिळते.

Compressor ने agent ला आवश्यक असलेली एखादी गोष्ट काढून टाकली तर काय होते?

काहीही काढून टाकले जात नाही. Compressed segments मध्ये [REF:id] tag असतो आणि model read_original किंवा expand_context वापरून पूर्ण text पुन्हा मिळवतो. Filter केलेले tool schemas delete करण्याऐवजी stub केले जातात आणि model gateway_search_tools वापरून त्यांपैकी एक पुन्हा मिळवतो. प्रत्यक्ष धोका missing file पेक्षा सूक्ष्म आहे: model lossy summary वर काम करतो आणि त्याला original मागणे आवश्यक आहे हे कधीच लक्षात येत नाही. SWE-bench Lite वरील 86.5% quality-retained हा आकडा हाच परिणाम मोजतो.

माझ्या पहिल्या request ला पंधरा सेकंद का लागतात?

Tool filter मागील embedding model startup वेळी load होण्याऐवजी पहिल्या request वेळी load होते. Project मध्ये warm-up साठी 10 ते 15 सेकंद आणि त्यानंतर प्रत्येक call साठी सुमारे 15 ms लागतात असे नमूद केले आहे. Proxy सुरू केल्यानंतर curl वापरून एक निरुपयोगी request पाठवा. त्यामुळे पहिल्या वास्तविक agent turn ला विलंब होणार नाही.

Self-host करण्याऐवजी hosted GPU server वापरावा का?

यामुळे GPU rent आणि maintenance ची गरज राहत नाही. August 2026 पासून process केलेल्या प्रत्येक million tokens साठी किंमत $0.30 आहे. मात्र तुमचे prompts आणि agent ने वाचलेल्या files model provider पर्यंत पोहोचण्यापूर्वी third party कडे पाठवले जातात. तुमच्या नियंत्रणाखालील infrastructure वर code ठेवण्यासाठी self-hosting करत असाल, तर ही setting तुम्ही self-hosting सुरू करण्यामागील कारणच निष्प्रभ करते. Self-hosting मुळे context आणि provider API key दोन्ही तुमच्या स्वतःच्या box वर राहतात.

#paritok#tokens #coding-agents #self-hosting #gpu