Paritok কি coding agent-এর বিল কমাতে পারে?

Paritok একটি অনুরোধের সঙ্গে কী করে

Paritok হলো একটি token gateway: এটি এমন একটি proxy, যা আপনার coding agent এবং model API-এর মধ্যে থাকে এবং ফরওয়ার্ড করার আগে প্রতিটি অনুরোধ সংকুচিত করে। আপনার agent provider-এর পরিবর্তে http://127.0.0.1:8080-এর সঙ্গে যোগাযোগ করে। proxy tool schema, file read, tool output এবং আগের turn-গুলো পুনর্লিখন করে, ছোট payload upstream-এ পাঠায় এবং reply অপরিবর্তিত অবস্থায় ফেরত দেয়।

provider-এর কাছে যা পৌঁছায়, তার ভিত্তিতেই আপনাকে বিল করা হয়। তাই ছোট payload মানে ছোট invoice। এটিই মূল ধারণা। এটি “আপনার context আরও দীর্ঘস্থায়ী হয়” ধরনের দাবির থেকে আলাদা। এই কারণেই tool-টি শুধু গোছানো নয়, বরং আগ্রহের বিষয়।

প্রকল্পটি এখনও নতুন। এর প্রথম public tag-গুলোর তারিখ 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 trajectory থেকে নেওয়া 45,000টি teacher-distilled sample দিয়ে প্রশিক্ষিত।

কেন এটি context trimming নয়

Trimming তথ্য মুছে দেয়। কোনো agent তার context limit-এর কাছাকাছি পৌঁছে পুরোনো turn-গুলো বাদ দিলে, turn 3-এ পড়া file-টি আর থাকে না। turn 20-এ file-টি আবার প্রয়োজন হলে agent সেটি পুনরায় পড়ে। ফলে ওই token-গুলোর জন্য দ্বিতীয়বার খরচ হয়। সাশ্রয়টি আসলে ধার ছিল।

Paritok একটি segment-কে [REF:id] tag-সহ সংক্ষিপ্ত রূপে প্রতিস্থাপন করে এবং সম্পূর্ণ text proxy-তে সংরক্ষণ করে। Model read_original অথবা expand_context কল করে segment পুনরুদ্ধার করে। এতে ব্যর্থতার ধরন বদলে যায়। Trimmer ভুলে গিয়ে ব্যর্থ হয় এবং আপনাকে কখনও জানায় না। Compressor model-কে lossily সংক্ষিপ্ত summary দিয়ে ব্যর্থ হয়। Summary যথেষ্ট না হলে model original text চাইতে পারে।

Tool filter-ও একইভাবে কাজ করে। Filter করা tool schema মুছে ফেলার পরিবর্তে stub হিসেবে রাখা হয় এবং model gateway_search_tools কল করে একটি tool পুনরুদ্ধার করে। এটি গুরুত্বপূর্ণ, কারণ কোনো filter স্থায়ীভাবে একটি tool আড়াল করলে আপনার agent কী করতে পারে তা বদলে যায়। তখন কাজ নীরবে ভুল হওয়ার মাধ্যমে আপনি বিষয়টি জানতে পারেন।

তিনটি নিয়ন্ত্রণ পদ্ধতি, এবং কোনটি বিনামূল্যে

প্রথম পদ্ধতিটি হলো tool-schema filter। প্রতিটি request-এর সঙ্গে সম্পূর্ণ tools array পাঠানো হয়। কয়েকটি MCP (model context protocol) server সংযুক্ত থাকা Claude Code turn-এ project-টি এই block-এর আকার প্রায় 29,000 token হিসেবে মাপে। Filter-টি BAAI/bge-small-en-v1.5, 130 MB-এর একটি embedding model, ব্যবহার করে user-এর request এবং প্রতিটি tool description embed করে। যেসব tool-এর সঙ্গে মিল পাওয়া যায় সেগুলো রেখে বাকি tool-গুলোর stub তৈরি করে। এতে block-এর আকার প্রায় 8,000 token-এ নেমে আসে। এই embedding model CPU-তে চলে।

দ্বিতীয় পদ্ধতিটি হলো content compression। এই অংশের জন্য GPU-তে 4B model প্রয়োজন। File read, tool output এবং history-কে তাদের মূল আকারের 25.7%-এ নামিয়ে লেখা হয়। 74% headline-এর ভিত্তি এটাই। বিষয়টি সতর্কভাবে বুঝুন: 74% হলো compress করা content-এর compression rate, আপনার bill-এর হ্রাস নয়।

তৃতীয় পদ্ধতিটি হলো history summarization। Context budget পূর্ণ হয়ে গেলে recent window-এর বাইরের turn-গুলো সংক্ষেপে লেখা হয়। ফলে limit-এ পৌঁছে session বন্ধ না হয়ে দীর্ঘ সময় চলতে পারে।

শুধু দ্বিতীয় পদ্ধতির জন্য GPU প্রয়োজন। এই পৃষ্ঠার সবচেয়ে গুরুত্বপূর্ণ বাক্য এটাই। pip install "paritok[toolselect]" সাধারণ CPU VPS-এ tool filter চালানোর সুবিধা দেয়, এবং এটি product-এর সেই অংশ যা প্রতি মাসে আপনার কোনো খরচ করে না। কোনো 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
  }
]

এগুলো প্রকল্পটির নিজস্ব প্রকাশিত পরিসংখ্যান, যা SWE-bench Lite-এর বিপরীতে প্রকল্পটির নিজস্ব harness-এ পরিমাপ করা হয়েছে। Paritok-4B-v1 মূল আকারের 25.7%-এ content compress করে এবং uncompressed solve rate-এর 86.5% ধরে রাখে। compressor হিসেবে gpt-5 ব্যবহার করলে গুণমান বেশি থাকে, 93.6%, কিন্তু content মাত্র 61.9%-এ compress হয়। অর্থাৎ frontier price সাশ্রয় করতে frontier price-ই দিতে হবে।

Quality column সঠিকভাবে পড়ুন। Solve rate-এর 86.5% ধরে রাখার অর্থ হলো compressed run যে সমস্যাগুলো সমাধান করতে পারেনি, uncompressed run সেগুলো সমাধান করেছে—প্রায় প্রতি সাতটি 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 সাশ্রয় বাড়ে, কারণ history জমতে থাকে এবং history-ই compress করা হয়। প্রকল্পটি জানায়, single turn-এ প্রায় 25%, turn 5-এ 39%, এবং turn 20-এ 63% সাশ্রয় হয়। কোথায় এই বৃদ্ধি থামে, তাও প্রকল্পটি উল্লেখ করেছে: 200,000 token budget-এ absolute saving প্রতি turn-এ প্রায় 48,000 token-এ স্থির হয়ে যায়, আনুমানিক turn 8 থেকে 12-এর মধ্যে। কারণ context পূর্ণ হয়ে গেলে history আর বাড়ে না। বহুল উদ্ধৃত "past 85%" figure context-saturated session বোঝায়। এটি best case। তাই এর ভিত্তিতে পরিকল্পনা করবেন না।

24GB GPU কি Paritok-এর খরচ তুলে দেয়?

এই আকারের মডেলের জন্য 24 GB কার্ডই সাধারণ rental unit। 7 August 2026 অনুযায়ী, 24 GB-সহ RTX 4090-এর প্রকাশিত on-demand rate-এর median ছিল প্রতি ঘণ্টায় $0.44; সবচেয়ে সস্তা listing-গুলো ছিল প্রায় $0.20। এখানে $0.44 ধরা যাক। পুরো মাস চালু রাখলে মোট 730 ঘণ্টা হয়, অর্থাৎ $321। শুধু কর্মঘণ্টায়, দিনে 8 ঘণ্টা করে 22 দিন চালালে মোট 176 ঘণ্টা হয়, অর্থাৎ $77।

এখন token কমার পরিমাণকে dollar সাশ্রয়ে রূপান্তর করুন। এই হ্রাস input token-এর ক্ষেত্রে প্রযোজ্য। Output token proxy অপরিবর্তিত অবস্থায় পার করে দেয়, তাই সেগুলোর পরিমাণ একেবারেই বদলায় না। ধরুন, আপনার মোট dollar খরচের 80% input token-এর জন্য; coding agent-এর ক্ষেত্রে এটি সাধারণ অনুমান। নিজের bill দেখে এই অনুমান যাচাই করুন। তাহলে dollar সাশ্রয় হবে 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
  }
]

Saturated-session-এর 85% হারে bill-এর 68% সাশ্রয় হয়। তাই GPU card সব সময় চালু রাখলে আপনার মাসিক agent খরচ প্রায় $472 ছাড়ালেই card-এর খরচ উঠে আসে। কর্মঘণ্টার বাইরে instance বন্ধ রাখলে এই সীমা প্রায় $114। Turn-20-এর 63% হারে এই পরিমাণগুলো হয় $637 এবং $154। Turn-5-এর 39% হারে, যা ছোট session-এ বাস্তবে দেখা যায়, card ভাড়া নেওয়া সার্থক হওয়ার আগে মাসে প্রায় $1,030 খরচ করতে হবে।

দুটি কারণে table-এর তুলনায় ফল আরও ভালো হতে পারে। মডেলটির 24 GB প্রয়োজন হয় না: q4 build প্রায় 2.5 GB এবং bf16 build প্রায় 8 GB। তাই ছোট card ব্যবহার করলে, অথবা অন্য কাজের জন্য আগে থেকেই চালু থাকা GPU box ব্যবহার করলে, chart-এর প্রতিটি পরিমাণ কমে যায়। আর কেউ coding না করলে instance বন্ধ রাখা এখানে সবচেয়ে বড় সাশ্রয়ের উপায়, কারণ এতে rent প্রায় তিন-চতুর্থাংশ কমে যায়।

একটি কারণে ফল খারাপ হতে পারে। Compression pass-এর জন্য বাস্তব computation দরকার। 4B model যে token compress করে, সেটি আগে পড়তে এবং পরে লিখতে হয়। ফলে প্রতিটি agent turn-এ latency বাড়ে। ঘণ্টাভিত্তিক ভাড়ার card-এ এই খরচ invoice-এর আলাদা line হিসেবে দেখা যায় না; waiting time হিসেবে দেখা যায়। তাই নিজে অনুভব না করা পর্যন্ত এটি সহজেই নজর এড়িয়ে যায়।

সাধারণভাবে rented GPU hours এবং API token-এর খরচ তুলনা করলে, GPU VPS এবং API token-এর 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 release-এর মধ্যে config key-এর নাম বদলে দিতে পারে। একটি সাধারণ pip install paritok বা main-এর git clone ব্যবহার করলে পরের সপ্তাহে আপনি ভিন্ন gateway পাবেন। কোন gateway আপনার মাপা সংখ্যাগুলো তৈরি করেছে, তারও কোনো record থাকবে না।

Default backend হলো Ollama। Model pull করুন। এরপর proxy যে short name খোঁজে, সেটি model-কে দিন।

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

Local model প্রতিটি compressed segment-এর জন্য একটি rewrite লেখে। তাই compression pass বেশি সময় নিলে agent turn আটকে আছে বলে দেখা যায়। Ollama-এর num_predict output length-এর সীমা এই সময়সীমা নিয়ন্ত্রণ করে।

এর পাশে 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 পরীক্ষা করুন।

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 পরিবেশন করে।

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

Ollama দ্রুত চালু করা যায়। একাধিক agent একই box ব্যবহার করলেই vLLM concurrent request অনেক ভালোভাবে পরিচালনা করে। Ollama এবং vLLM-এর ব্যবহারিক পার্থক্য আপনার জন্য কোনটি উপযুক্ত তা নির্ধারণ করবে।

Base URL environment variable ব্যবহার করে 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-এ পাঠায়। তাই Internet থেকে reachable proxy ওই key-এর জন্য একটি open relay হয়ে যায়। যে ব্যক্তি port খুঁজে পাবে, সে key না দেখেই আপনার অর্থ খরচ করতে পারবে। Port খোলার বদলে SSH tunnel বা VPN ব্যবহার করে laptop থেকে এতে সংযোগ করুন।

systemd-এর অধীনে এটি চালান, যাতে reboot-এর পরেও চালু থাকে। আপনার install অনুযায়ী path পরিবর্তন করুন।

[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 start হয়ে সঙ্গে সঙ্গে exit করলে সাধারণত config file path ভুল থাকে। journalctl -u paritok -n 50 কারণটি দেখায়।

হোস্ট করা বিকল্প এবং এর খরচ

প্রকল্পটি compression service হিসেবেও সরবরাহ করে। একটি API key দিয়ে use_gpu_server: true সেট করলে 4B model প্রকল্পটির hardware-এ চলে। প্রক্রিয়াকৃত প্রতি million token-এর মূল্য $0.30। তাদের নিজস্ব documentation অনুযায়ী, 2026 সালের August-এর শেষ পর্যন্ত এটি বিনামূল্যে। এতে GPU ভাড়া এবং উপরে বর্ণিত operations-এর সব কাজ এড়ানো যায়।

তবে এর অর্থ হলো, আপনার prompt এবং agent যে file পড়ে, সেগুলো model provider-এর কাছে পৌঁছানোর আগে আপনার machine ছেড়ে একটি third party-এর কাছে যায়। ঠিক এই hop এড়ানোর জন্যই self-hosting করা হয়। আপনি কোন বিষয়টিকে অগ্রাধিকার দিচ্ছেন, সেই flag সেট করার আগে তা নির্ধারণ করুন। কারণ flag পরিবর্তন করতে এক লাইনই লাগে, কিন্তু এর পরিণতি এক লাইনে সীমাবদ্ধ নয়।

নিজের ক্ষেত্রে আগে ও পরে কীভাবে পরিমাপ করবেন

প্রকাশিত সংখ্যাগুলো প্রকল্পের নিজস্ব সংখ্যা। এগুলো SWE-bench Lite-এ প্রকল্পের harness ব্যবহার করে পাওয়া হয়েছে। আপনার repository SWE-bench Lite নয়। নিজের ব্যবহারের পরিমাপ নিজেই করুন।

• Proxy ছাড়া, অর্থাৎ request path-এ proxy না রেখে, একটি স্বাভাবিক সপ্তাহ চালান। আপনার provider-এর usage page থেকে input tokens, cache-read tokens এবং output tokens আলাদা লাইনে লিখে রাখুন। এগুলোকে একসঙ্গে dollar total হিসেবে লিখবেন না।
• পরের সপ্তাহে proxy সামনে রেখে একই ধরনের কাজ করুন।
• input এবং cache-read-এর লাইন তুলনা করুন। output মোটামুটি অপরিবর্তিত থাকার কথা, কারণ কোনো compressor output compress করে না। output-এ বড় পরিবর্তন হলে proxy ছাড়া অন্য কিছু পরিবর্তিত হয়েছে।
• যে task-গুলো আবার করতে হয়েছে, সেগুলো গুনুন। এটিই trade-off-এর quality অংশ, এবং কোনো dashboard-এ এর রিপোর্ট থাকে না।
• মোট খরচ তুলনা করার আগে দ্বিতীয় সপ্তাহের 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-এর খরচের পার্থক্য নির্ধারণ করে input-side compressor আপনার জন্য আদৌ মূল্যবান কি না। Claude Code-এর token আসলে কোথায় ব্যবহৃত হয় দেখায় আপনার context-এর কোন অংশ compress করার মতো বড়।

বিশেষ করে tool-filter-এর হিসাব prompt caching-এর কারণে জটিল হয়। Tool block request-এর শুরুতে থাকে। তাই প্রথম turn-এর পর এটি সাধারণত input price-এর 10% হারে cache hit হয়। Cached block থেকে 21,000 token বাদ দিলে প্রতি turn-এ সাশ্রয় হয় 21,000 token × প্রতি million-এ $0.30, অর্থাৎ প্রায় $0.006। Uncached rate অনুযায়ী যে $0.063 সাশ্রয় হবে বলে মনে হতে পারে, এটি তার চেয়ে কম। Cached prefix যাতে পরিবর্তিত না হয়, সে জন্য প্রকল্পটি session চলাকালীন filtered block অপরিবর্তিত রাখে। প্রতি turn-এ আবার tool নির্বাচন করা কোনো filter ওই prefix invalid করে দেবে এবং সাশ্রয়ের চেয়ে বেশি খরচ তৈরি করবে।

যা এখনও যাচাই করা হয়নি

উপরের প্রতিটি performance number প্রকল্পটির নিজস্ব তথ্য থেকে এসেছে। SWE-bench Lite-এর ফলাফলের কোনো independent reproduction নেই। তাছাড়া প্রথম tag-গুলোর তারিখ July 2026 হওয়ায় code-টির operational history-ও খুব সীমিত। Compression rate এবং quality-retained figure—দুটিই এমন পক্ষের মাপা, যাদের এগুলো ভালো দেখালে লাভ হয়। এর অর্থ এই নয় যে সংখ্যাগুলো ভুল। এর অর্থ হলো এগুলো এখনও confirmed নয়। তাই নিজে তৈরি করা কোনো সংখ্যার তুলনায় এগুলোকে ভিন্নভাবে বিবেচনা করুন।

আপনার setup-কে দোষ দেওয়ার আগে একটি documented behaviour জানা দরকার। Tool filter যে embedding model ব্যবহার করে, সেটি startup-এর সময় নয়, প্রথম request-এর সময় load হয়। তাই প্রকল্পের documentation-এ 10 থেকে 15 seconds warm-up time এবং এরপর প্রতি call-এ প্রায় 15 ms সময়ের কথা বলা হয়েছে। Proxy start হওয়ার পরে একটি throwaway request পাঠান। তাহলে প্রথম বাস্তব agent turn আটকে আছে বলে মনে হবে না।

এক বিকেলে আপনি নিজেই চারটি বিষয় নির্ধারণ করতে পারেন: proxy start হয়ে চালু থাকে কি না, কাজ করার সময় /stats পরিবর্তিত হয় কি না, আপনার provider-এর input-token line সত্যিই কমে কি না, এবং agent কাজ শেষ করতে পারে কি না। Published benchmark-এর চেয়ে এই বিষয়গুলোই আপনার setup-এর ক্ষেত্রে সিদ্ধান্ত নেওয়ার জন্য বেশি কার্যকর।

আপনার অন্যান্য tooling-এর সঙ্গে এর অবস্থান সম্পর্কে: self-hosted LiteLLM gateway request-এর contents পরিবর্তন না করে সেগুলো route ও meter করে। তাই দুটি ভিন্ন সমস্যার সমাধান করে এবং একসঙ্গে ব্যবহার করা যায়; এই ক্ষেত্রে Paritok agent-এর সবচেয়ে কাছের স্তরে থাকে। আসল লক্ষ্য যদি এই নির্দিষ্ট tool নয়, বরং bill কমানো হয়, তাহলে VPS-এ চলা agent-এর জন্য আরও বিস্তৃত cost control-এর তালিকা-তে এমন কয়েকটি পরিবর্তন আছে, যেগুলো আগে বিনা খরচে চেষ্টা করা যায়।

FAQ

Paritok কি আমার API bill কমায়, নাকি শুধু context usage কমায়?

এটি bill কমায়, কারণ proxy provider-এর কাছে পৌঁছানোর আগে request পুনর্লিখন করে এবং provider যা পায় তার ভিত্তিতেই charge করে। তবে এই হ্রাস headline-এ উল্লেখ করা সংখ্যার চেয়ে কম। 74% figure হলো যে content compress করা হচ্ছে, তার compression rate। শুরু থেকে শেষ পর্যন্ত project-এর রিপোর্ট অনুযায়ী, একটি turn-এ প্রায় 25% এবং 20তম turn-এ 63% হ্রাস হয়; তাও শুধু input token-ই পরিবর্তিত হয়। Output token অপরিবর্তিত থাকে।

Compression model নিজে 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 segment-এ [REF:id] tag থাকে এবং model read_original অথবা expand_context ব্যবহার করে সম্পূর্ণ text পুনরুদ্ধার করে। Filter করা tool schema মুছে ফেলা হয় না; stub হিসেবে রাখা হয় এবং model gateway_search_tools ব্যবহার করে সেটি পুনরুদ্ধার করে। প্রকৃত ঝুঁকি missing file-এর চেয়ে কম দৃশ্যমান। Model একটি lossy summary-এর ভিত্তিতে কাজ করে এবং মূল text চাওয়া দরকার—এটি বুঝতে নাও পারে। SWE-bench Lite-এ 86.5% quality-retained figure এই বিষয়টিই পরিমাপ করে।

আমার প্রথম request নিতে পনেরো সেকেন্ড লাগে কেন?

Tool filter-এর পেছনের embedding model startup-এর সময় নয়, প্রথম request-এর সময় load হয়। Project documentation অনুযায়ী warm-up হতে 10 থেকে 15 সেকেন্ড লাগে। এরপর প্রতিটি call-এ প্রায় 15 ms সময় লাগে। Proxy চালু করার পরে curl ব্যবহার করে একটি throwaway request পাঠান। তাহলে প্রথম প্রকৃত agent turn আটকে থাকবে না।

Self-hosting-এর বদলে hosted GPU server ব্যবহার করা উচিত কি?

এতে GPU rent ও maintenance-এর খরচ থাকে না। August 2026 অনুযায়ী, প্রক্রিয়াকৃত প্রতি million token-এর জন্য এর মূল্য $0.30। তবে আপনার model provider-এর কাছে prompt পৌঁছানোর আগে আপনার prompt এবং agent যে file পড়ে, সেগুলো third party-এর কাছে পাঠানো হয়। Infrastructure-এর নিয়ন্ত্রণ নিজের হাতে রেখে code সংরক্ষণ করার জন্য self-hosting করলে, এই setting সেই উদ্দেশ্য নষ্ট করে। Self-hosting করলে context এবং provider API key—দুটিই আপনার নিজের box-এ থাকে।