Paritok token gateway क्या है और यह बिल कैसे कम करता है

Paritok एक request के साथ क्या करता है

Paritok एक token gateway है: यह एक proxy है जो आपके coding agent और model API के बीच स्थित होता है और आगे भेजने से पहले प्रत्येक request को compress करता है। आपका agent provider के बजाय http://127.0.0.1:8080 से बात करता है। यह proxy tool schemas, file reads, tool output और पुराने turns को rewrite करता है, छोटा payload upstream भेजता है, और उत्तर को बिना किसी बदलाव के वापस सौंप देता है।

Provider आपको उस चीज़ के लिए bill करता है जो उसके पास पहुँचती है, इसलिए छोटा payload मतलब छोटा invoice। यही इसका मुख्य विचार है। यह "आपका context अधिक समय तक चलता है" वाले दावे से अलग है, और यही कारण है कि यह tool केवल व्यवस्थित होने के बजाय दिलचस्प है।

यह project नया है। इसके पहले public tags जुलाई 2026 के हैं और वर्तमान tag v1.3.0 है, जो 5 अगस्त 2026 का है। इसके weights और gateway code Apache 2.0 लाइसेंस के अंतर्गत हैं। इसका compression model Qwen3-4B-Instruct-2507 पर आधारित एक LoRA (low-rank adaptation) adapter है, जिसे वास्तविक coding-agent trajectories से लिए गए 45,000 teacher-distilled samples पर train किया गया है।

यह context trimming क्यों नहीं है

Trimming डेटा को हटा देता है। जब कोई agent अपनी context limit के करीब पहुँचता है और सबसे पुराने turns को हटा देता है, तो turn 3 पर पढ़ी गई फाइल गायब हो जाती है। यदि उसे turn 20 पर उस फाइल की आवश्यकता होती है, तो वह उसे फिर से पढ़ता है, इसलिए आप उन tokens के लिए दूसरी बार भुगतान करते हैं। वह बचत केवल एक उधार थी।

Paritok एक segment को एक छोटे रूप और एक tag, [REF:id], से बदल देता है, और पूर्ण text को proxy पर सुरक्षित रखता है। model read_original या expand_context को call करके segment को पुनः प्राप्त कर लेता है। यह failure mode को बदल देता है। Trimmer भूलकर विफल होता है, और वह आपको कभी बताता भी नहीं है। Compressor एक lossy summary देकर विफल होता है, और जब summary पर्याप्त नहीं होती तो model मूल जानकारी मांग सकता है।

Tool filter भी इसी तरह काम करता है। Filter किए गए tool schemas को हटाने के बजाय stub कर दिया जाता है, और model gateway_search_tools को call करके किसी एक को पुनः प्राप्त कर सकता है। यह महत्वपूर्ण है क्योंकि जो filter किसी tool को स्थायी रूप से छिपा देता है, वह आपके agent की कार्यक्षमता को बदल देता है, और आपको इसके बारे में तब पता चलेगा जब कोई कार्य चुपचाप विफल हो जाएगा।

तीन लीवर, और कौन सा मुफ्त है

पहला लीवर tool-schema फ़िल्टर है। प्रत्येक अनुरोध में पूरा tools ऐरे (array) शामिल होता है। Claude Code के एक टर्न पर, जिसमें कुछ MCP (model context protocol) सर्वर जुड़े हों, प्रोजेक्ट इस ब्लॉक को लगभग 29,000 टोकन मापता है। फ़िल्टर उपयोगकर्ता के अनुरोध और प्रत्येक टूल विवरण को BAAI/bge-small-en-v1.5 (एक 130 MB का एम्बेडिंग मॉडल) के साथ एम्बेड करता है, मेल खाने वाले टूल्स को रखता है, और बाकी को स्टब (stub) कर देता है। यह ब्लॉक घटकर लगभग 8,000 टोकन रह जाता है। वह एम्बेडिंग मॉडल CPU पर चलता है।

दूसरा लीवर कंटेंट कंप्रेशन है, और यह वह हिस्सा है जिसके लिए GPU पर 4B मॉडल की आवश्यकता होती है। फ़ाइल रीड्स, टूल आउटपुट और हिस्ट्री को उनके मूल आकार के 25.7% तक फिर से लिखा जाता है। 74% की हेडलाइन यहीं से आती है। इसे ध्यान से पढ़ें: 74% उस कंटेंट पर कंप्रेशन रेट है जिसे कंप्रेस किया जाता है, न कि आपके बिल में की गई कटौती।

तीसरा लीवर हिस्ट्री समराइजेशन है। एक बार जब कॉन्टेक्स्ट बजट भर जाता है, तो हालिया विंडो से परे के टर्न्स को सारांशित (summarize) कर दिया जाता है ताकि लिमिट तक पहुँचने के बजाय एक लंबा सेशन चलता रहे।

केवल दूसरे लीवर को GPU की आवश्यकता होती है। यह इस पेज का सबसे उपयोगी वाक्य है। pip install "paritok[toolselect]" आपको एक साधारण CPU VPS पर टूल फ़िल्टर देता है, और यह प्रोडक्ट का वह आधा हिस्सा है जिसकी आपको प्रति माह कोई लागत नहीं चुकानी पड़ती। कार्ड किराए पर लेने से पहले इसे आज़माएँ।

परियोजना ने क्या मापा, और किस हार्नेस पर

[
  {
    "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 के विरुद्ध इसके अपने हार्नेस पर मापा गया है। Paritok-4B-v1 सामग्री को मूल आकार के 25.7% तक संकुचित (compress) करता है, जबकि यह असंकुचित (uncompressed) solve rate का 86.5% बनाए रखता है। कंप्रेसर के रूप में gpt-5 का उपयोग करने पर अधिक गुणवत्ता बनी रहती है, यानी 93.6%, लेकिन यह केवल 61.9% तक ही संकुचित होता है, और आप frontier कीमतों को बचाने के लिए frontier कीमतें ही चुका रहे होंगे।

गुणवत्ता कॉलम को ईमानदारी से पढ़ें। Solve rate का 86.5% बनाए रखने का अर्थ है कि संकुचित runs उन समस्याओं को हल करने में विफल रहे जिन्हें असंकुचित runs ने हल कर लिया था, जो लगभग सात में से एक solve के बराबर है। एक बेंचमार्क पर यह केवल एक तालिका की संख्या है। आपके रिपॉजिटरी पर यह एक ऐसा कार्य है जिसे आप दो बार चलाते हैं।

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

End-to-end बचत सत्र चलने के साथ बढ़ती है, क्योंकि history जमा होती है और history ही वह चीज है जिसे compress किया जा रहा है। परियोजना एक single turn पर लगभग 25%, 5वें turn तक 39%, और 20वें turn तक 63% की बचत की रिपोर्ट करती है। यह यह भी बताती है कि यह वृद्धि कहाँ रुकती है: 200,000 token के बजट पर पूर्ण बचत लगभग 8 से 12वें turn के आसपास, प्रति turn 48,000 token पर स्थिर हो जाती है, क्योंकि एक बार context भर जाने के बाद history का बढ़ना रुक जाता है। व्यापक रूप से उद्धृत "85% से अधिक" का आंकड़ा context-saturated सत्रों का वर्णन करता है। यह सबसे अच्छा मामला है, इसलिए इसके आधार पर योजना न बनाएं।

क्या 24GB GPU, Paritok के लिए किफायती है?

इस आकार के मॉडल के लिए 24 GB कार्ड एक सामान्य रेंटल यूनिट है। 7 अगस्त 2026 तक, 24 GB वाले RTX 4090 के लिए प्रकाशित median on-demand दर $0.44 प्रति घंटा थी, जिसमें सबसे सस्ती लिस्टिंग $0.20 के करीब थी। $0.44 को आधार मानें। यदि इसे पूरे महीने चलाया जाए, तो यह 730 घंटे होते हैं, यानी $321। यदि इसे केवल काम के घंटों के दौरान, 22 दिनों तक 8 घंटे प्रतिदिन चलाया जाए, तो यह 176 घंटे होते हैं, यानी $77।

अब token cut को dollar cut में बदलें। यह कटौती input tokens पर लागू होती है। Output tokens प्रॉक्सी से बिना किसी बदलाव के गुजरते हैं, इसलिए उनमें कोई परिवर्तन नहीं होता। मान लें कि input tokens आपके कुल डॉलर खर्च का 80% हैं, जो कि एक कोडिंग एजेंट के लिए सामान्य है, और इस धारणा की तुलना अपने बिल से करें। आपकी डॉलर बचत, token reduction को 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
  }
]

85% के saturated-session आंकड़े पर, आप बिल का 68% बचाते हैं, इसलिए यदि आपका मासिक एजेंट खर्च लगभग $472 से अधिक हो जाता है, तो हर समय चलने वाला कार्ड अपनी लागत निकाल लेता है। यदि आप काम के घंटों के बाहर instance को बंद कर देते हैं, तो यह आंकड़ा लगभग $114 हो जाता है। 63% के turn-20 आंकड़े पर, ये मान $637 और $154 हो जाते हैं। 39% के turn-5 आंकड़े पर, जो कि छोटे सत्रों की वास्तविक स्थिति है, कार्ड को किराए पर लेने से पहले आपको प्रति माह लगभग $1,030 खर्च करने की आवश्यकता होती है।

दो चीजें इसे तालिका के सुझाव से बेहतर बनाती हैं। मॉडल को 24 GB की आवश्यकता नहीं है: q4 बिल्ड लगभग 2.5 GB का है और bf16 बिल्ड लगभग 8 GB का, इसलिए एक छोटा कार्ड, या कोई GPU बॉक्स जिसे आप पहले से ही किसी अन्य कार्य के लिए चला रहे हैं, उस चार्ट की प्रत्येक संख्या को कम कर देता है। और जब कोई कोडिंग नहीं कर रहा हो तो instance को बंद करना यहाँ सबसे बड़ा कारक है, क्योंकि यह किराए को लगभग तीन-चौथाई कम कर देता है।

एक चीज इसे बदतर बनाती है। compression pass एक वास्तविक कार्य है। 4B मॉडल जिस भी token को compress करता है, उसे पहले पढ़ना और फिर लिखना पड़ता है, जो प्रत्येक एजेंट टर्न में latency जोड़ता है। प्रति घंटे किराए पर लिए गए कार्ड पर यह लागत प्रतीक्षा (waiting) के रूप में दिखाई देती है, न कि इनवॉइस पर एक लाइन के रूप में, इसलिए जब तक आप इसे महसूस नहीं करते, इसे नजरअंदाज करना आसान है।

यदि आप सामान्य रूप से किराए के GPU घंटों की तुलना API tokens से कर रहे हैं, तो GPU VPS और API tokens के बीच break-even inference के लिए भी यही गणित अपनाता है।

VPS पर Paritok gateway चलाना

Python 3.10 या उससे नया वर्ज़न आवश्यक है। Ubuntu 24.04 में Python 3.12 आता है, इसलिए केवल CPU वाले हिस्से के लिए एक साधारण 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"

वर्ज़न को पिन (pin) करें। रिपॉजिटरी ने 29 July 2026 को v1.2.8 और 5 August 2026 को v1.3.0 टैग किया था, और इतनी तेज़ी से आगे बढ़ने वाले प्रोजेक्ट्स releases के बीच config keys का नाम बदल देते हैं। एक साधारण pip install paritok, या main का git clone, आपको अगले सप्ताह एक अलग gateway दे सकता है और इस बात का कोई रिकॉर्ड नहीं छोड़ेगा कि आपके द्वारा मापे गए आंकड़े किस वर्ज़न से आए थे।

डिफ़ॉल्ट backend Ollama है। मॉडल को pull करें, फिर उसे वह छोटा नाम दें जिसे proxy ढूँढता है।

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

इसके बगल में paritok.yaml लिखें। use_gpu_server: false ही वह चीज़ है जो compression को आपके अपने हार्डवेयर पर रखती है।

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

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

paritok up ऊपर दी गई सभी प्रक्रियाओं के लिए शॉर्टकट है: यदि मॉडल मौजूद नहीं है तो यह उसे pull करता है और proxy को port 8080 पर शुरू करता है। किसी agent को इसकी ओर निर्देशित करने से पहले proxy की जाँच करें।

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

/health एक छोटा JSON object लौटाता है जिसमें "status":"ok" और एक वर्ज़न स्ट्रिंग होती है। /stats compression का कुल योग और proxy का अपना अनुमान लौटाता है कि उसने कितनी बचत की है। उस अनुमान को proxy द्वारा अपने काम को ग्रेड देने के रूप में देखें, और अपने प्रदाता (provider) के usage page से इसकी पुष्टि करें।

सुविधा के बजाय throughput के लिए, vLLM बेस मॉडल के ऊपर adapter को सर्व (serve) करता है।

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

Ollama को सेटअप करना तेज़ है। vLLM concurrent requests को कहीं बेहतर तरीके से संभालता है, जो तब मायने रखने लगता है जब एक से अधिक agent उस box को साझा करते हैं। Ollama और vLLM के बीच व्यावहारिक अंतर ही वह चीज़ है जो आपके लिए इसका निर्णय करती है।

बेस 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 सेट होता है, तो प्रोजेक्ट आपके लिए ~/.codex/config.toml लिखता है। वेरिएबल को केवल export करने से Codex सीधे प्रदाता से बात करता रहता है, और इसका संकेत यह है कि काम करते समय /stats काउंटर कभी नहीं बढ़ता।

listener को हमेशा 127.0.0.1 पर रखें, कभी भी 0.0.0.0 पर नहीं। Proxy आपके प्रदाता की API key को upstream भेजता है, इसलिए इंटरनेट से सुलभ proxy उस key के लिए एक open relay बन जाता है: जो कोई भी उस port को ढूँढ लेगा, वह key को देखे बिना ही आपके पैसे खर्च कर देगा। Port खोलने के बजाय SSH tunnel या VPN के माध्यम से laptop से इसे एक्सेस करें।

इसे systemd के अंतर्गत चलाएं ताकि reboot के बाद भी यह चलता रहे। अपने इंस्टॉलेशन के अनुसार 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 इसका कारण प्रिंट कर देता है।

Hosted विकल्प और इसकी लागत

यह प्रोजेक्ट compression को एक service के रूप में भी बेचता है। use_gpu_server: true को एक API key के साथ सेट करें और 4B मॉडल उनके hardware पर चलता है। इसकी कीमत $0.30 प्रति मिलियन tokens है, जो उनके documentation के अनुसार अगस्त 2026 के अंत तक मुफ्त है। यह GPU के किराए और ऊपर बताए गए सभी operational कार्यों को समाप्त कर देता है।

इसका यह भी अर्थ है कि आपके prompts और वे files जिन्हें आपका agent पढ़ता है, वे आपके model provider तक पहुँचने से पहले आपकी machine से बाहर निकलकर किसी तीसरे पक्ष (third party) तक पहुँचते हैं। Self-hosting का अस्तित्व ठीक इसी hop से बचने के लिए है। उस flag को सेट करने से पहले यह तय करें कि आप इन दोनों में से किसे प्राथमिकता दे रहे हैं, क्योंकि flag को बदलना तो एक लाइन का काम है, लेकिन इसके परिणाम स्थायी होते हैं।

अपने परिणामों को पहले और बाद में कैसे मापें

प्रकाशित आंकड़े SWE-bench Lite पर प्रोजेक्ट के अपने हार्नेस से लिए गए हैं। आपकी रिपॉजिटरी SWE-bench Lite नहीं है। इसलिए अपने आंकड़े स्वयं मापें।

• एक सामान्य सप्ताह बिना किसी proxy के चलाएं। अपने प्रदाता के usage page से input tokens, cache-read tokens और output tokens को अलग-अलग पंक्तियों में रिकॉर्ड करें, न कि केवल कुल डॉलर राशि के रूप में।
• अगला सप्ताह proxy का उपयोग करते हुए चलाएं और समान कार्य करें।
• input और cache-read पंक्तियों की तुलना करें। output लगभग समान रहना चाहिए, क्योंकि proxy इसे compress नहीं करता है। यदि output में बड़ा बदलाव आता है, तो इसका मतलब है कि proxy के अलावा कुछ और बदला है।
• उन कार्यों की गिनती करें जिन्हें आपको दोबारा करना पड़ा। यह trade-off का गुणवत्ता वाला हिस्सा है, और कोई भी डैशबोर्ड इसकी रिपोर्ट नहीं देता है।
• कुल योग की तुलना करने से पहले दूसरे सप्ताह में GPU hours को जोड़ें।

input को output से अलग करना महत्वपूर्ण है क्योंकि दोनों की कीमत बहुत अलग है और compressor केवल एक को प्रभावित करता है। अगस्त 2026 तक, Claude Sonnet 4.6 की कीमत $3 प्रति मिलियन input tokens और $15 प्रति मिलियन output tokens है, और prompt-cache read की दर input दर का 10% यानी $0.30 प्रति मिलियन है। Input और output token लागत के बीच का अंतर यह तय करता है कि input-side compressor आपके लिए फायदेमंद है या नहीं। Claude Code के tokens वास्तव में कहाँ जाते हैं यह बताता है कि आपके context का कौन सा हिस्सा इतना बड़ा है कि उसे compress करना सार्थक है।

Prompt caching विशेष रूप से tool-filter की गणना को जटिल बनाता है। tool block अनुरोध की शुरुआत में होता है, इसलिए पहले टर्न के बाद यह सामान्यतः 10% input मूल्य पर cache hit होता है। एक cached block से 21,000 tokens कम करने पर $0.30 प्रति मिलियन की दर से लगभग $0.006 प्रति टर्न की बचत होती है, न कि $0.063 की, जो uncached दर के अनुसार होती। यह प्रोजेक्ट filtered block को session के लिए स्थिर रखता है ताकि cached prefix न बदले। यदि कोई filter हर टर्न पर tools को फिर से चुनता है, तो वह उस prefix को अमान्य कर देगा और बचत से अधिक लागत बढ़ा देगा।

क्या अभी भी अपुष्ट है

ऊपर दिए गए सभी प्रदर्शन आंकड़े स्वयं प्रोजेक्ट से लिए गए हैं। SWE-bench Lite परिणामों का कोई स्वतंत्र सत्यापन नहीं है, और जुलाई 2026 की पहली टैग तारीखों के कारण कोड के पीछे बहुत कम परिचालन इतिहास है। कम्प्रेशन दर और गुणवत्ता-प्रतिधारण (quality-retained) के आंकड़े उस पक्ष द्वारा मापे गए हैं जिसे उनके बेहतर दिखने से लाभ होता है। इसका मतलब यह नहीं है कि वे गलत हैं। इसका मतलब है कि वे अपुष्ट हैं, और आपको उन्हें उन आंकड़ों से अलग मानना चाहिए जिन्हें आपने स्वयं तैयार किया है।

एक प्रलेखित व्यवहार (documented behaviour) के बारे में जानना उपयोगी है, इससे पहले कि आप अपने सेटअप को दोष दें। टूल द्वारा उपयोग किया जाने वाला एम्बेडिंग मॉडल स्टार्टअप के बजाय पहली रिक्वेस्ट पर लोड होता है, इसलिए प्रोजेक्ट 10 से 15 सेकंड के वार्म-अप का सुझाव देता है, जिसके बाद प्रति कॉल लगभग 15 ms का समय लगता है। प्रॉक्सी शुरू होने के बाद एक थ्रोअवे रिक्वेस्ट भेजें, ताकि आपका पहला वास्तविक एजेंट टर्न हैंग होता हुआ न दिखे।

चार चीजें जिन्हें आप एक दोपहर में स्वयं परख सकते हैं: क्या प्रॉक्सी शुरू होती है और चालू रहती है, क्या काम करते समय /stats हिलता है, क्या आपके प्रदाता की इनपुट-टोकन लाइन वास्तव में गिरती है, और क्या एजेंट अभी भी काम पूरा करता है। ये चीजें किसी भी प्रकाशित बेंचमार्क की तुलना में आपके सेटअप के लिए बेहतर निर्णय लेंगी।

जहाँ तक यह आपके अन्य टूलिंग के साथ स्थित है: एक self-hosted LiteLLM gateway सामग्री को बदले बिना रिक्वेस्ट को रूट और मीटर करता है, इसलिए दोनों अलग-अलग समस्याओं का समाधान करते हैं और इन्हें एक साथ जोड़ा जा सकता है, जिसमें Paritok एजेंट के सबसे करीब रहता है। यदि वास्तविक लक्ष्य इस विशिष्ट टूल के बजाय बिल कम करना है, तो VPS पर एजेंट के लिए लागत नियंत्रण के व्यापक सेट में कई ऐसे बदलाव शामिल हैं जिन्हें आज़माने में कुछ भी खर्च नहीं होता है।

FAQ

क्या Paritok मेरा API बिल कम करता है या केवल context usage?

यह बिल कम करता है, क्योंकि proxy provider तक पहुँचने से पहले request को rewrite कर देता है और provider को वही मिलता है जो वह प्राप्त करता है। उस कमी का आकार मुख्य दावे से कम है। 74% का आंकड़ा उस content पर compression rate है जिसे compress किया जा रहा है। End-to-end, यह प्रोजेक्ट एक single turn पर लगभग 25% और 20वें turn तक 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 के गणित को आपके पक्ष में बदल देगा। Tool-schema filter को किसी GPU की आवश्यकता नहीं है: यह BAAI/bge-small-en-v1.5 का उपयोग करता है, जो 130 MB का एक embedding model है और CPU पर चलता है। paritok[toolselect] को एक साधारण VPS पर install करें और आपको थोड़ी सी RAM की कीमत पर tool-block reduction मिल जाएगा।

यदि compressor कुछ ऐसा हटा दे जिसकी agent को आवश्यकता थी, तो क्या होगा?

कुछ भी हटाया नहीं जाता है। Compressed segments में [REF:id] tag होता है और model read_original या expand_context के साथ पूरा text recover कर लेता है। Filtered tool schemas को delete करने के बजाय stub कर दिया जाता है, और model gateway_search_tools के साथ एक को recover कर लेता है। वास्तविक जोखिम किसी missing file से अधिक सूक्ष्म है: model एक lossy summary से काम करता है और उसे कभी पता नहीं चलता कि उसे original के लिए पूछना चाहिए था। SWE-bench Lite पर 86.5% quality-retained का आंकड़ा इसी बात को मापता है।

मेरी पहली request को पंद्रह सेकंड क्यों लगते हैं?

Tool filter के पीछे का embedding model startup के बजाय पहली request पर load होता है। प्रोजेक्ट 10 से 15 सेकंड के warm-up का उल्लेख करता है, और उसके बाद प्रति call लगभग 15 ms का समय लगता है। Proxy start करने के बाद curl के साथ एक throwaway request भेजें, तो पहला वास्तविक agent turn रुकेगा नहीं।

क्या मुझे self-hosting के बजाय hosted GPU server का उपयोग करना चाहिए?

यह GPU का किराया और maintenance हटा देता है, जिसकी कीमत अगस्त 2026 तक प्रति मिलियन processed tokens पर $0.30 है। यह आपके prompts और उन files को भी, जिन्हें आपका agent पढ़ता है, आपके model provider तक पहुँचने से पहले एक third party को भेज देता है। यदि आप code को अपने नियंत्रण वाले infrastructure पर रखने के लिए self-hosting कर रहे हैं, तो वह setting उस कारण को ही खत्म कर देती है जिसके लिए आपने शुरुआत की थी। Self-hosting context और provider API key दोनों को आपके अपने box पर सुरक्षित रखती है।