Paritok मुळे coding agent चा खर्च कमी होतो का?

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

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

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

हा 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 आहे. तो वास्तविक coding-agent trajectories मधून घेतलेल्या 45,000 teacher-distilled samples वर प्रशिक्षित केला आहे.

हे context trimming नाही

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

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

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

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

पहिला उपाय म्हणजे tool-schema filter. प्रत्येक विनंतीमध्ये संपूर्ण tools array असतो. काही MCP (model context protocol) servers जोडलेल्या Claude Code turn मध्ये हा block सुमारे 29,000 tokens इतका असतो. Filter वापरकर्त्याची विनंती आणि प्रत्येक tool description BAAI/bge-small-en-v1.5 या 130 MB embedding model मध्ये encode करतो, जुळणारी 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% हा compress केलेल्या content वरील compression rate आहे; तुमच्या bill मधील कपात नाही.

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

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

प्रकल्पाने काय मोजले आणि कोणत्या 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
  }
]

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

Quality column चा अर्थ प्रामाणिकपणे समजा. Solve rate पैकी 86.5% टिकवला याचा अर्थ असंकुचित runs ने सोडवलेल्या समस्यांपैकी काही समस्या compressed runs सोडवू शकले नाहीत. हे प्रमाण जवळपास सातपैकी एक solve इतके आहे. Benchmark मध्ये हा table मधील एक आकडा असतो. तुमच्या repository मध्ये तेच काम तुम्हाला दोनदा चालवावे लागू शकते.

[
  {
    "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 saving वाढते, कारण history साठत जाते आणि संकुचित केली जाणारी गोष्ट history हीच असते. प्रकल्पाच्या अहवालानुसार एका turn वर सुमारे 25% saving होते, turn 5 पर्यंत 39% आणि turn 20 पर्यंत 63% saving होते. ही वाढ कुठे थांबते हेही प्रकल्प स्पष्ट करतो. 200,000 token budget वर absolute saving प्रति turn सुमारे 48,000 tokens वर स्थिर होते. हे साधारणपणे turn 8 ते 12 च्या दरम्यान घडते, कारण context पूर्ण झाल्यावर history वाढत नाही. सर्वत्र उद्धृत केले जाणारे "past 85%" हे context-saturated sessions चे वर्णन आहे. ही सर्वोत्तम स्थिती आहे; त्यामुळे तुमचे नियोजन केवळ त्यावर आधारित करू नका.

24GB GPU साठी Paritok घेणे फायदेशीर आहे का?

या आकाराच्या model साठी 24 GB card हे नेहमीचे rental unit आहे. 7 August 2026 रोजी 24 GB RTX 4090 साठी प्रकाशित on-demand दराचा median प्रति तास $0.44 होता; सर्वात स्वस्त listings जवळपास $0.20 पासून सुरू होत होत्या. आपण $0.44 हा दर धरू. संपूर्ण महिना सुरू ठेवले, तर 730 तास होतात आणि खर्च $321 येतो. फक्त कामाच्या वेळेत, दिवसाला 8 तास आणि 22 दिवस चालवले, तर 176 तास होतात आणि खर्च $77 येतो.

आता token reduction चे dollar saving मध्ये रूपांतर करा. ही reduction input tokens वर लागू होते. Output tokens proxy मधून कोणताही बदल न होता पुढे जातात, त्यामुळे त्यांच्यावर परिणाम होत नाही. Coding agent साठी input tokens तुमच्या एकूण dollar खर्चाच्या 80% असतात असे गृहीत धरा आणि हे गृहीतक तुमच्या स्वतःच्या bill शी पडताळा. त्यानुसार तुमची dollar saving म्हणजे 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 आकड्यानुसार bill मधील 68% रक्कम वाचते. त्यामुळे card सतत सुरू ठेवला, तर तुमचा मासिक agent खर्च साधारण $472 पेक्षा जास्त झाल्यावर card स्वतःचा खर्च भरून काढतो. Instance कामाच्या वेळेबाहेर बंद केल्यास हा उंबरठा साधारण $114 असतो. Turn-20 च्या 63% आकड्यानुसार हे अनुक्रमे $637 आणि $154 होतात. Turn-5 च्या 39% आकड्यानुसार, जो प्रत्यक्षातील short sessions साठी अधिक वास्तववादी आहे, card भाड्याने घेणे फायदेशीर ठरण्यापूर्वी तुमचा मासिक खर्च साधारण $1,030 असणे आवश्यक आहे.

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

ही गणना प्रतिकूल ठरण्याचे एक कारण आहे. Compression pass साठी प्रत्यक्ष computation लागते. 4B model compress करणारा प्रत्येक token model ला आधी read आणि नंतर write करावा लागतो. त्यामुळे प्रत्येक agent turn ला latency वाढते. तासाच्या हिशोबाने भाड्याने घेतलेल्या card वर हा खर्च invoice मधील स्वतंत्र ओळ म्हणून दिसत नाही; तो waiting time म्हणून दिसतो. त्यामुळे तो जाणवेपर्यंत सहज दुर्लक्षित होऊ शकतो.

सर्वसाधारणपणे 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 दरम्यान configuration keys ची नावे बदलू शकतात. साधा pip install paritok किंवा main चा git clone वापरल्यास पुढील आठवड्यात वेगळे gateway मिळेल आणि तुम्ही मोजलेले आकडे कोणत्या आवृत्तीने तयार केले याची नोंद राहणार नाही.

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

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

त्याच्या शेजारी paritok.yaml लिहा. Compression तुमच्या स्वतःच्या hardware वरच सुरू राहण्यासाठी use_gpu_server: false आवश्यक आहे.

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 ची एकूण संख्या आणि 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 अधिक सक्षम आहे. एकाच box वर एकापेक्षा अधिक agents असतील तेव्हा हा फरक महत्त्वाचा ठरतो. 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 कडे पाठवते. त्यामुळे इंटरनेटवरून पोहोचता येणारा 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 चालवा. सुरू होताच बंद होणाऱ्या unit चा configuration file path बहुधा चुकीचा असतो. journalctl -u paritok -n 50 कारण दाखवते.

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

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

मात्र याचा अर्थ असा आहे की तुमचे prompts आणि तुमचा agent वाचत असलेल्या files तुमच्या model provider पर्यंत पोहोचण्यापूर्वी तुमचे machine सोडून third party कडे जातात. नेमका हा hop टाळण्यासाठी self-hosting वापरले जाते. use_gpu_server: true सेट करण्यापूर्वी या दोनपैकी कोणत्या उद्दिष्टाला तुम्ही प्राधान्य देत आहात ते ठरवा. हा 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 मध्ये याचा अहवाल मिळत नाही.
• एकूणांची तुलना करण्यापूर्वी week two मध्ये वापरलेले GPU hours जोडा.

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

विशेषतः tool-filter च्या arithmetic मध्ये prompt caching मुळे गणना अधिक गुंतागुंतीची होते. tool block request च्या सुरुवातीला असतो. त्यामुळे पहिल्या turn नंतर तो सामान्यतः input price च्या 10% दराने cache hit असतो. cached block मधून 21,000 tokens काढल्यास, uncached rate नुसार सुचणाऱ्या $0.063 ऐवजी, $0.30 per million या दराने 21,000 tokens वाचतात आणि प्रत्येक turn साठी सुमारे $0.006 बचत होते. cached prefix बदलू नये म्हणून प्रकल्प 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 वेळी load होत नाही. ते पहिल्या request वेळी load होते. त्यामुळे project मध्ये 10 ते 15 seconds चा warm-up आणि त्यानंतर प्रत्येक call साठी सुमारे 15 ms अशी नोंद आहे. Proxy सुरू झाल्यानंतर एक throwaway request पाठवा. त्यामुळे तुमचा पहिला खरा agent turn अडकलेला दिसणार नाही.

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

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

FAQ

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

हे बिल कमी करते, कारण proxy provider पर्यंत पोहोचण्यापूर्वी request पुन्हा लिहितो आणि provider ला मिळालेल्या content साठी शुल्क आकारतो. ही कपात headline मध्ये दाखवल्यापेक्षा कमी असते. 74% हा compressed केलेल्या content वरील compression rate आहे. सुरुवातीपासून शेवटपर्यंत, 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 गणित तुमच्या फायद्याचे बदलते. 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 पुन्हा मिळवतो. Filtered tool schemas delete करण्याऐवजी stub केले जातात आणि model gateway_search_tools वापरून त्यांपैकी एक पुन्हा मिळवतो. खरा धोका missing file पेक्षा सूक्ष्म आहे. Model lossy summary वरून काम करतो आणि त्याला original मागणे आवश्यक आहे हे कधीच लक्षात येत नाही. SWE-bench Lite वरील 86.5% quality-retained आकडा हाच परिणाम मोजतो.

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

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

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

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