Paritok token gateway: coding agent کا خرچ کم؟

Paritok درخواست کے ساتھ کیا کرتا ہے

Paritok ایک token gateway ہے: یہ ایسا proxy ہے جو آپ کے coding agent اور model API کے درمیان رہتا ہے اور ہر درخواست کو آگے بھیجنے سے پہلے compress کرتا ہے۔ آپ کا agent provider کے بجائے http://127.0.0.1:8080 سے رابطہ کرتا ہے۔ یہ proxy tool schemas، file reads، tool output اور پچھلے turns کو دوبارہ لکھتا ہے، چھوٹا payload upstream بھیجتا ہے، اور جواب کو بغیر تبدیلی کے واپس پہنچا دیتا ہے۔

Provider آپ سے اس data کے مطابق billing کرتا ہے جو 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 ہے، جسے حقیقی 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 کو مختصر شکل اور ایک tag، [REF:id]، سے بدل دیتا ہے اور مکمل متن proxy پر محفوظ رکھتا ہے۔ model read_original یا expand_context کو call کر کے segment بحال کر لیتا ہے۔ اس سے failure mode بدل جاتا ہے۔ Trimmer بھول جانے کی وجہ سے fail ہوتا ہے، اور آپ کو کبھی نہیں بتاتا۔ Compressor model کو lossly summary دے کر fail ہوتا ہے، لیکن جب summary کافی نہ ہو تو model اصل متن طلب کر سکتا ہے۔

Tool filter بھی اسی طرح کام کرتا ہے۔ Filter کیے گئے tool schemas کو حذف کرنے کے بجائے stub کیا جاتا ہے، اور model gateway_search_tools کو call کر کے ایک schema بحال کر لیتا ہے۔ یہ اس لیے اہم ہے کہ جو filter کسی tool کو مستقل طور پر چھپا دے، وہ آپ کے agent کی ممکنہ کارروائیوں کو بدل دیتا ہے، اور آپ کو اس کا علم ایسے task سے ہوتا ہے جو خاموشی سے غلط ہو گیا ہو۔

تین طریقے، اور ان میں سے کون سا مفت ہے

پہلا طریقہ tool-schema filter ہے۔ ہر request میں مکمل tools array شامل ہوتا ہے۔ چند MCP (model context protocol) servers منسلک ہونے والی Claude Code turn میں project کے مطابق اس block کا حجم تقریباً 29,000 tokens ہوتا ہے۔ یہ filter صارف کی request اور ہر tool description کو BAAI/bge-small-en-v1.5، یعنی 130 MB کے embedding model، کے ذریعے embed کرتا ہے، مطابقت رکھنے والے tools برقرار رکھتا ہے اور باقی tools کے عارضی متبادل بناتا ہے۔ اس block کا حجم کم ہو کر تقریباً 8,000 tokens رہ جاتا ہے۔ یہ embedding model CPU پر چلتا ہے۔

دوسرا طریقہ content compression ہے، اور اسی کے لیے GPU پر 4B model درکار ہوتا ہے۔ File reads، tool output اور history کو ان کے اصل حجم کے 25.7% تک مختصر کیا جاتا ہے۔ 74% کا دعویٰ اسی سے حاصل ہوتا ہے۔ اسے غور سے سمجھیں: 74% اس content کی compression rate ہے جسے compress کیا جاتا ہے، آپ کے bill میں کمی نہیں۔

تیسرا طریقہ history summarization ہے۔ جب context budget مکمل ہو جاتا ہے تو recent window سے باہر کی turns کا خلاصہ بنا دیا جاتا ہے، تاکہ طویل session limit تک پہنچ کر رکنے کے بجائے جاری رہے۔

صرف دوسرا طریقہ GPU کا تقاضا کرتا ہے۔ اس صفحے کا سب سے اہم جملہ یہی ہے۔ pip install "paritok[toolselect]" آپ کو عام CPU VPS پر tool filter فراہم کرتا ہے، اور یہ product کا وہ نصف ہے جس کے لیے ماہانہ کوئی لاگت نہیں آتی۔ 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% تک کم کرتا ہے، جبکہ غیر compressed solve rate کا 86.5% برقرار رکھتا ہے۔ gpt-5 کو compressor کے طور پر استعمال کرنے سے معیار زیادہ برقرار رہتا ہے، یعنی 93.6%، لیکن مواد صرف 61.9% تک کم ہوتا ہے۔ اس صورت میں frontier prices بچانے کے لیے frontier prices ادا کرنا پڑیں گے۔

quality column کو دیانت داری سے پڑھیں۔ solve rate کا 86.5% برقرار رہنے کا مطلب ہے کہ compressed runs ان مسائل پر ناکام ہوئے جنہیں uncompressed runs نے حل کیا، یعنی تقریباً ہر سات میں سے ایک solve ناکام ہوا۔ benchmark پر یہ table میں درج ایک عدد ہے۔ آپ کی repository میں یہ وہ task ہے جسے آپ دو بار چلاتے ہیں۔

[
  {
    "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 جمع ہوتی رہتی ہے اور compressed کی جانے والی چیز یہی history ہے۔ منصوبہ ایک turn پر تقریباً 25%، turn 5 تک 39%، اور turn 20 تک 63% کی رپورٹ کرتا ہے۔ یہ بھی واضح کیا گیا ہے کہ یہ اضافہ کہاں رک جاتا ہے: 200,000 token budget پر absolute saving تقریباً 48,000 tokens فی turn پر ہموار ہو جاتی ہے، جو تقریباً turn 8 سے 12 کے درمیان ہے، کیونکہ context بھر جانے کے بعد history بڑھنا بند ہو جاتی ہے۔ عام طور پر نقل کیا جانے والا "past 85%" کا عدد context-saturated sessions کی نمائندگی کرتا ہے۔ یہ بہترین صورت ہے، اس لیے اپنی planning اسی پر نہ کریں۔

کیا 24GB GPU Paritok کے اخراجات پورے کرتا ہے؟

اس سائز کے model کے لیے 24GB card عام rental unit ہے۔ 7 August 2026 تک، 24GB والے RTX 4090 کی شائع شدہ on-demand شرح کا median $0.44 فی گھنٹہ تھا، جبکہ سب سے سستی listings تقریباً $0.20 کے قریب تھیں۔ ہم $0.44 استعمال کرتے ہیں۔ اگر یہ پورا مہینہ چلتا رہے تو یہ 730 hours بنتے ہیں، یعنی $321۔ اگر یہ صرف working hours میں چلے، یعنی روزانہ 8 hours اور 22 دن، تو یہ 176 hours بنتے ہیں، یعنی $77۔

اب token reduction کو dollar reduction میں تبدیل کریں۔ یہ reduction صرف input tokens پر لاگو ہوتی ہے۔ Output tokens proxy سے بغیر تبدیلی گزر جاتے ہیں، اس لیے ان میں کوئی فرق نہیں آتا۔ فرض کریں کہ آپ کے کل dollar bill کا 80% input tokens پر مشتمل ہے، جو coding agent کے لیے معمول کی بات ہے، اور اس مفروضے کو اپنے bill سے verify کریں۔ اس صورت میں 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 figure پر آپ bill کا 68% برقرار رکھتے ہیں۔ اس لیے مسلسل چلنے والا card اس وقت اپنے اخراجات پورے کرتا ہے جب آپ کا ماہانہ agent spend تقریباً $472 سے زیادہ ہو جائے، یا اگر آپ working hours کے بعد instance بند کر دیں تو تقریباً $114۔ 63% کے turn-20 figure پر یہ قدریں بالترتیب $637 اور $154 ہو جاتی ہیں۔ 39% کے turn-5 figure پر، جو مختصر sessions کی حقیقی صورت ہے، card کرائے پر لینا قابلِ قدر بننے سے پہلے آپ کو تقریباً $1,030 ماہانہ خرچ کرنا ہوگا۔

دو چیزیں اس نتیجے کو table سے بہتر بناتی ہیں۔ model کو 24GB درکار نہیں: q4 build تقریباً 2.5GB اور bf16 build تقریباً 8GB ہے۔ اس لیے چھوٹا card، یا وہ GPU box جو آپ پہلے ہی کسی اور کام کے لیے چلا رہے ہیں، chart میں موجود ہر number کم کر دیتا ہے۔ اور جب کوئی coding نہ کر رہا ہو تو instance بند کرنا یہاں سب سے مؤثر قدم ہے، کیونکہ اس سے rent تقریباً تین چوتھائی کم ہو جاتا ہے۔

ایک چیز اس نتیجے کو خراب کرتی ہے۔ compression pass حقیقی computational work ہے۔ 4B model جس token کو compress کرتا ہے، اسے پہلے پڑھنا اور پھر لکھنا پڑتا ہے، جس سے ہر agent turn میں latency بڑھ جاتی ہے۔ جس card کا کرایہ گھنٹوں کے حساب سے ادا کیا جاتا ہے، اس کی یہ لاگت invoice کی الگ line کے طور پر نہیں بلکہ 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"

ورژن کو pin کریں۔ 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 تلاش کرتا ہے۔

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

اس کے ساتھ 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 کرتا ہے اور proxy کو port 8080 پر start کرتا ہے۔ کسی agent کو اس کی طرف بھیجنے سے پہلے proxy check کریں۔

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

/health ایک چھوٹا JSON object واپس کرتا ہے جس میں "status":"ok" اور version string شامل ہوتی ہے۔ /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 کو شروع کرنا زیادہ آسان ہے۔ vLLM concurrent requests کو کہیں بہتر انداز میں handle کرتا ہے، اور ایک ہی 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 کو نظر انداز کرتا ہے، اس لیے project آپ کے لیے ~/.codex/config.toml لکھتا ہے جب codex.enabled: true کو paritok.yaml میں set کیا جائے۔ صرف یہ variable export کرنے سے Codex براہ راست provider سے بات کرتا رہتا ہے۔ اس کی علامت /stats counter ہے جو کام کے دوران کبھی نہیں بڑھتا۔

Listener کو 127.0.0.1 پر رکھیں، 0.0.0.0 پر نہیں۔ Proxy آپ کی provider API key کو upstream forward کرتا ہے، اس لیے internet سے قابل رسائی proxy اس key کے لیے open relay بن جاتی ہے۔ جسے بھی یہ port مل جائے، وہ خود key دیکھے بغیر آپ کے پیسے خرچ کر سکتا ہے۔ Port کھولنے کے بجائے SSH tunnel یا VPN کے ذریعے laptop سے اس تک رسائی حاصل کریں۔

اسے systemd کے تحت چلائیں تاکہ reboot کے بعد بھی یہ جاری رہے۔ Paths کو اپنی 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

اسے sudo systemctl enable --now paritok سے enable کریں، پھر دوبارہ /health کو curl کریں۔ جو unit start ہوتے ہی exit ہو جائے، اس کا مطلب عموماً config file path غلط ہے، اور journalctl -u paritok -n 50 اس کی وجہ دکھاتا ہے۔

میزبانی شدہ اختیار اور اس کی لاگت

یہ پروجیکٹ compression کو بطور سروس بھی فراہم کرتا ہے۔ اپنی API key کے ساتھ use_gpu_server: true سیٹ کریں، تو 4B model اس کے hardware پر چلتا ہے۔ اس کی قیمت process کیے گئے ہر million tokens کے لیے $0.30 ہے، تاہم اس کی اپنی documentation کے مطابق اگست 2026 کے اختتام تک یہ مفت ہے۔ اس سے GPU کرایہ اور اوپر بیان کردہ تمام operations work ختم ہو جاتا ہے۔

اس کا مطلب یہ بھی ہے کہ آپ کے prompts اور وہ files جنہیں آپ کا agent پڑھتا ہے، آپ کی machine سے نکل کر third party تک پہنچتے ہیں، اور اس کے بعد آپ کے model provider تک جاتے ہیں۔ Self-hosting کا مقصد عین اسی hop سے بچنا ہے۔ یہ flag سیٹ کرنے سے پہلے طے کریں کہ آپ ان دونوں میں سے کس چیز کو ترجیح دے رہے ہیں، کیونکہ flag میں تبدیلی صرف ایک سطر کی ہے، لیکن اس کا نتیجہ ایسا نہیں ہے۔

اپنا قبل اور بعد کا نتیجہ کیسے ناپیں

شائع شدہ اعداد و شمار اس project کے اعداد و شمار ہیں، جو project کے 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 کی تعداد گنیں جنہیں آپ کو دوبارہ کرنا پڑا۔ یہی اس تبادلے کا quality والا حصہ ہے، اور کسی بھی dashboard میں اس کی رپورٹ نہیں ہوتی۔
• totals کا موازنہ کرنے سے پہلے week two کے GPU hours بھی شامل کریں۔

input کو output سے الگ دکھانا اس لیے اہم ہے کہ دونوں کی قیمتیں بہت مختلف ہیں اور compressor صرف ان میں سے ایک کو متاثر کرتا ہے۔ August 2026 تک Claude Sonnet 4.6 کی قیمت $3 فی million input tokens اور $15 فی million output tokens ہے، جبکہ prompt-cache read کی قیمت input rate کا 10%، یعنی $0.30 فی million ہے۔ input اور output token کی لاگت میں فرق یہ طے کرتا ہے کہ input-side compressor آپ کے لیے فائدہ مند ہے یا نہیں۔ Claude Code کے tokens حقیقت میں کہاں خرچ ہوتے ہیں یہ بتاتا ہے کہ آپ کے context کا کون سا حصہ اتنا بڑا ہے کہ اسے compress کرنا مفید ہو۔

Prompt caching خاص طور پر tool-filter کے حساب کو پیچیدہ بناتی ہے۔ tool block request کے آغاز میں ہوتا ہے، اس لیے پہلے turn کے بعد یہ عموماً input price کے 10% پر cache hit ہوتا ہے۔ cached block سے 21,000 tokens کم کرنے پر ہر turn میں $0.30 فی million کے حساب سے 21,000 tokens کی بچت ہوتی ہے، یعنی تقریباً $0.006، نہ کہ $0.063 جو uncached rate سے ظاہر ہوتا ہے۔ یہ project session کے دوران filtered block کو تبدیل نہیں کرتا، تاکہ cached prefix برقرار رہے۔ اگر کوئی filter ہر turn میں tools دوبارہ منتخب کرے تو cached prefix invalid ہو جائے گا اور filter کی بچت سے زیادہ لاگت آئے گی۔

اب تک کیا غیرمصدقہ ہے

اوپر دیے گئے کارکردگی کے تمام اعداد خود project سے لیے گئے ہیں۔ SWE-bench Lite کے نتائج کی کوئی آزادانہ توثیق موجود نہیں، اور چونکہ پہلے tags جولائی 2026 کے ہیں، اس لیے code کے پیچھے عملی استعمال کی تاریخ بھی بہت محدود ہے۔ compression rate اور برقرار رہنے والے معیار کا عدد، دونوں اسی فریق نے ناپے ہیں جسے ان کے بہتر دکھائی دینے سے فائدہ ہوتا ہے۔ اس کا مطلب یہ نہیں کہ یہ اعداد غلط ہیں۔ اس کا مطلب یہ ہے کہ ان کی ابھی تصدیق نہیں ہوئی، اس لیے آپ کو انہیں اپنے تیار کردہ عدد سے مختلف درجے کا اعتماد دینا چاہیے۔

ایک documented رویہ جاننا مفید ہے، تاکہ آپ مسئلے کا الزام اپنے setup پر نہ دیں۔ tool filter میں استعمال ہونے والا embedding model startup کے وقت نہیں بلکہ پہلی request پر load ہوتا ہے۔ اسی لیے project کے documentation میں warm-up کے لیے 10 سے 15 seconds، اور اس کے بعد ہر call کے لیے تقریباً 15 ms درج ہیں۔ proxy شروع ہونے کے بعد ایک غیر اہم request بھیج دیں۔ اس طرح agent کی پہلی حقیقی turn رکی ہوئی محسوس نہیں ہوگی۔

آپ ایک دوپہر میں چار باتوں کی خود تصدیق کر سکتے ہیں: آیا proxy شروع ہو کر چلتا رہتا ہے، آیا /stats کام کے دوران تبدیل ہوتا ہے، آیا آپ کے provider کی input-token line واقعی کم ہوتی ہے، اور آیا agent پھر بھی کام مکمل کرتا ہے۔ آپ کے setup کے لیے فیصلہ ان باتوں سے کسی بھی published benchmark کے مقابلے میں زیادہ درست ہوگا۔

یہ آپ کے دوسرے tools کے ساتھ کہاں آتا ہے: ایک self-hosted LiteLLM gateway requests کو ان کے contents میں تبدیلی کیے بغیر route اور meter کرتا ہے، اس لیے دونوں مختلف مسائل حل کرتے ہیں اور انہیں chain کیا جا سکتا ہے، جبکہ Paritok agent کے سب سے قریب رہتا ہے۔ اگر اصل مقصد اسی مخصوص tool کے بجائے bill کم کرنا ہے تو VPS پر agent کے لیے cost controls کا وسیع مجموعہ کئی ایسی تبدیلیاں شامل کرتا ہے جنہیں پہلے آزمانے کی کوئی لاگت نہیں۔

FAQ

کیا Paritok میرا API bill کم کرتا ہے یا صرف context usage؟

یہ bill کم کرتا ہے، کیونکہ proxy request کو provider تک پہنچنے سے پہلے rewrite کرتا ہے اور provider وصول ہونے والے مواد کے حساب سے charges لیتا ہے۔ اس کمی کا حجم headline میں دی گئی شرح سے کم ہے۔ 74% کا عدد compress کیے جانے والے content کی compression rate ہے۔ end to end، project ایک turn پر تقریباً 25% اور turn 20 تک 63% کمی report کرتا ہے، اور صرف 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 calculation آپ کے حق میں بدل دیتا ہے۔ 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 کو ضرورت تھی تو کیا ہوگا؟

کچھ بھی remove نہیں ہوتا۔ 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 figure اسی چیز کی پیمائش کرتی ہے۔

میری پہلی request میں پندرہ seconds کیوں لگتے ہیں؟

tool filter کے پیچھے موجود embedding model startup کے وقت load ہونے کے بجائے پہلی request پر load ہوتا ہے۔ Project کے مطابق warm-up میں 10 سے 15 seconds لگتے ہیں، جس کے بعد ہر call میں تقریباً 15 ms لگتے ہیں۔ proxy start کرنے کے بعد curl کے ساتھ ایک غیر اہم request بھیج دیں، تو پہلی حقیقی agent turn میں تاخیر نہیں ہوگی۔

کیا مجھے self-hosting کے بجائے hosted GPU server استعمال کرنا چاہیے؟

اس سے GPU rent اور maintenance ختم ہو جاتے ہیں، اور August 2026 تک اس کی قیمت process کیے گئے ہر million tokens کے لیے $0.30 ہے۔ لیکن یہ آپ کے prompts اور وہ files بھی third party کو بھیجتا ہے جنہیں آپ کی agent پڑھتی ہے، اس سے پہلے کہ وہ آپ کے model provider تک پہنچیں۔ اگر آپ code کو اپنے زیرِ انتظام infrastructure پر رکھنے کے لیے self-hosting کر رہے ہیں، تو یہ setting آپ کے آغاز کی وجہ ختم کر دیتی ہے۔ Self-hosting سے context اور provider API key دونوں آپ کے اپنے box پر رہتے ہیں۔