SSD Nodes Learn 🎉 VPS $4.99/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-08

Paritok ব্যবহার করে কোডিং এজেন্টের বিল কমানোর উপায়

Paritok টোকেন গেটওয়ে কীভাবে ফাইল রিড ও টুলের আউটপুট সংকুচিত করে খরচ কমায় তা জানুন। এটি 74% পর্যন্ত টোকেন সাশ্রয় করে। এর কার্যপদ্ধতি ও ব্রেক-ইভেন হিসাব এখানে দেখুন।

Paritok একটি অনুরোধের সাথে যা করে

Paritok হলো একটি টোকেন গেটওয়ে: এটি একটি প্রক্সি যা আপনার কোডিং এজেন্ট এবং মডেল API-এর মাঝে অবস্থান করে এবং প্রতিটি অনুরোধ ফরোয়ার্ড করার আগে সেটিকে সংকুচিত (compress) করে। আপনার এজেন্ট প্রোভাইডারের পরিবর্তে http://127.0.0.1:8080-এর সাথে যোগাযোগ করে। প্রক্সিটি টুল স্কিমা, ফাইল রিড, টুলের আউটপুট এবং পূর্ববর্তী টার্নগুলোকে নতুন করে লিখে, ছোট পেলোডটি আপস্ট্রিমে পাঠায় এবং উত্তরটিকে অপরিবর্তিত অবস্থায় ফেরত দেয়।

প্রোভাইডার আপনার কাছ থেকে সেই পরিমাণ বিল নেয় যা তাদের কাছে পৌঁছায়, তাই পেলোড ছোট হলে ইনভয়েসও ছোট হয়। মূল ধারণাটি এটাই। এটি "আপনার কনটেক্সট দীর্ঘস্থায়ী হয়" এই দাবির চেয়ে ভিন্ন এবং এই কারণেই টুলটি কেবল পরিচ্ছন্ন নয়, বরং বেশ আকর্ষণীয়।

প্রকল্পটি নতুন। এর প্রথম পাবলিক ট্যাগগুলো জুলাই 2026-এর এবং বর্তমান ট্যাগটি হলো v1.3.0, যার তারিখ 5 আগস্ট 2026। ওয়েট এবং গেটওয়ে কোড Apache 2.0 লাইসেন্সের আওতাভুক্ত। কমপ্রেশন মডেলটি হলো Qwen3-4B-Instruct-2507-এর ওপর একটি LoRA (low-rank adaptation) অ্যাডাপ্টার, যা বাস্তব কোডিং-এজেন্ট ট্র্যাজেক্টরি থেকে নেওয়া 45,000 টিচার-ডিস্টিলড স্যাম্পলের ওপর প্রশিক্ষণপ্রাপ্ত।

কেন এটি কনটেক্সট ট্রিমিং নয়

ট্রিমিং বা ছাঁটাই করার অর্থ হলো মুছে ফেলা। যখন কোনো এজেন্ট তার কনটেক্সট সীমার কাছাকাছি পৌঁছায় এবং পুরোনো কথোপকথনগুলো বাদ দেয়, তখন 3 নম্বর টার্নে পড়া ফাইলটি হারিয়ে যায়। যদি 20 নম্বর টার্নে সেই ফাইলটির প্রয়োজন হয়, তবে এজেন্টকে সেটি পুনরায় পড়তে হয়, যার ফলে আপনাকে সেই টোকেনগুলোর জন্য দ্বিতীয়বার মূল্য পরিশোধ করতে হয়। এই সাশ্রয় আসলে একটি ঋণের মতো।

Paritok একটি অংশকে ছোট রূপ এবং একটি ট্যাগ, [REF:id] দিয়ে প্রতিস্থাপন করে এবং মূল টেক্সটটি প্রক্সিতে রেখে দেয়। মডেলটি read_original বা expand_context কল করার মাধ্যমে সেই অংশটি পুনরুদ্ধার করতে পারে। এটি ব্যর্থতার ধরন পরিবর্তন করে। একটি ট্রিমার ভুলে যাওয়ার মাধ্যমে ব্যর্থ হয় এবং এটি আপনাকে কখনোই জানায় না। একটি কম্প্রেসার একটি অসম্পূর্ণ সারাংশ মডেলকে দেওয়ার মাধ্যমে ব্যর্থ হয়, এবং সারাংশটি যথেষ্ট না হলে মডেলটি মূল অংশটি চেয়ে নিতে পারে।

টুল ফিল্টার একই পদ্ধতিতে কাজ করে। ফিল্টার করা টুল স্কিমাগুলো মুছে না ফেলে সেগুলোকে স্টাব (stub) হিসেবে রাখা হয় এবং মডেলটি gateway_search_tools কল করার মাধ্যমে যেকোনো একটি পুনরুদ্ধার করতে পারে। এটি গুরুত্বপূর্ণ কারণ একটি ফিল্টার যা স্থায়ীভাবে কোনো টুল লুকিয়ে ফেলে, তা আপনার এজেন্টের সক্ষমতা পরিবর্তন করে দেয়। আর এমনটি ঘটলে আপনি কেবল তখনই তা জানতে পারবেন যখন কোনো কাজ নীরবে ব্যর্থ হবে।

তিনটি লিভার, এবং কোনটি বিনামূল্যে

প্রথম লিভারটি হলো টুল-স্কিমা ফিল্টার। প্রতিটি অনুরোধে সম্পূর্ণ tools অ্যারে বহন করা হয়। 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% হলো সেই কন্টেন্টের কম্প্রেশন রেট যা কম্প্রেস করা হয়েছে, এটি আপনার বিলের ওপর ছাড় নয়।

তৃতীয় লিভারটি হলো হিস্ট্রি সামারাইজেশন। কনটেক্সট বাজেট পূর্ণ হয়ে গেলে, সাম্প্রতিক উইন্ডোর বাইরের টার্নগুলোকে সামারাইজ করা হয় যাতে লিমিট হিট না করে দীর্ঘ সেশন চলতে থাকে।

শুধুমাত্র দ্বিতীয় লিভারটির জন্য GPU প্রয়োজন। এই পৃষ্ঠার সবচেয়ে গুরুত্বপূর্ণ বাক্যটি এটিই। pip install "paritok[toolselect]" আপনাকে সাধারণ CPU VPS-এ টুল ফিল্টার ব্যবহারের সুবিধা দেয় এবং এটি পণ্যের সেই অর্ধেক অংশ যা আপনাকে প্রতি মাসে কোনো খরচ ছাড়াই ব্যবহার করতে দেয়। একটি কার্ড ভাড়া করার আগে এটি ব্যবহার করে দেখুন।

প্রকল্পটি কী পরিমাপ করেছে এবং কোন হার্নেসের বিপরীতে

ChartSWE-bench Lite: compression rate against solve quality retained (project's published figures)
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-এর বিপরীতে তাদের নিজস্ব হার্নেসে পরিমাপ করা হয়েছে। Paritok-4B-v1 কন্টেন্টকে মূল আকারের 25.7%-এ সংকুচিত করে, যেখানে এটি আনকম্প্রেসড সলভ রেটের 86.5% ধরে রাখতে সক্ষম। কম্প্রেসার হিসেবে gpt-5 ব্যবহার করলে গুণমান কিছুটা বেশি থাকে, যা 93.6%, কিন্তু এটি কেবল 61.9% পর্যন্ত সংকুচিত করতে পারে। এক্ষেত্রে, frontier প্রাইস বাঁচানোর জন্য আপনাকে frontier প্রাইস খরচ করতে হবে।

গুণমানের কলামটি সততার সাথে পড়ুন। সলভ রেটের 86.5% ধরে রাখার অর্থ হলো, আনকম্প্রেসড রান যে সমস্যাগুলো সমাধান করতে পেরেছিল, সংকুচিত রান সেগুলো সমাধান করতে ব্যর্থ হয়েছে—অর্থাৎ প্রতি সাতটি সমাধানের মধ্যে প্রায় একটি ব্যর্থ হয়েছে। একটি বেঞ্চমার্কে এটি কেবল টেবিলের একটি সংখ্যা মাত্র। কিন্তু আপনার রিপোজিটরিতে এটি এমন একটি কাজ যা আপনাকে দুবার করতে হতে পারে।

ChartReported input-token saving as a session grows (project's own harness)
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
  }
]

সেশন যত দীর্ঘ হয়, এন্ড-টু-এন্ড সাশ্রয় তত বাড়ে, কারণ হিস্ট্রি জমা হতে থাকে এবং এই হিস্ট্রিই সংকুচিত করা হচ্ছে। প্রকল্পটি একক টার্নে প্রায় 25%, 5ম টার্নে 39% এবং 20তম টার্নে 63% সাশ্রয়ের কথা জানিয়েছে। এটি এও উল্লেখ করে যে এই প্রবৃদ্ধি কোথায় গিয়ে থামে: 200,000 টোকেন বাজেটে টার্ন প্রতি পরম সাশ্রয় প্রায় 48,000 টোকেনে গিয়ে স্থির হয়, যা সাধারণত 8ম থেকে 12তম টার্নের কাছাকাছি ঘটে। কারণ কনটেক্সট পূর্ণ হয়ে গেলে হিস্ট্রি আর বড় হতে পারে না। বহুল প্রচারিত "85%-এর বেশি" পরিসংখ্যানটি কনটেক্সট-স্যাচুরেটেড সেশনগুলোকে নির্দেশ করে। এটি সেরা পরিস্থিতির ফলাফল, তাই এটিকে ভিত্তি ধরে পরিকল্পনা করবেন না।

একটি 24GB GPU কি Paritok-এর খরচ পুষিয়ে দেয়?

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

এখন টোকেন সাশ্রয়কে ডলারে রূপান্তর করুন। এই সাশ্রয় শুধুমাত্র ইনপুট টোকেনের ক্ষেত্রে প্রযোজ্য। আউটপুট টোকেন প্রক্সির মধ্য দিয়ে অপরিবর্তিত অবস্থায় যায়, তাই সেগুলোর খরচে কোনো পরিবর্তন হয় না। ধরে নিন ইনপুট টোকেন আপনার মোট খরচের 80%, যা একটি কোডিং এজেন্টের জন্য স্বাভাবিক, এবং আপনার নিজের বিলের সাথে এই অনুমানটি মিলিয়ে দেখুন। আপনার ডলার সাশ্রয় হবে টোকেন হ্রাসের সাথে 0.8 গুণ।

ChartMonthly agent bill needed before a $0.44/hour 24GB card pays for itself
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% সাশ্রয় করেন। তাই আপনার মাসিক এজেন্টের খরচ যখন প্রায় $472 ছাড়িয়ে যায়, তখন কার্ডটি নিজের খরচ নিজেই তুলে নেয়। আর যদি কাজের সময়ের বাইরে instance বন্ধ রাখেন, তবে এই সীমা প্রায় $114। 20-টার্ন ফিগারে 63% সাশ্রয়ের ক্ষেত্রে, এই পরিমাণ দাঁড়ায় $637 এবং $154। 5-টার্ন ফিগারে 39% সাশ্রয়ের ক্ষেত্রে, যা ছোট সেশনের প্রকৃত চিত্র, কার্ডটি ভাড়া নেওয়ার সার্থকতা পেতে আপনার মাসে প্রায় $1,030 খরচ হতে হবে।

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

একটি বিষয় পরিস্থিতিকে খারাপ করে। কমপ্রেশন পাসটি বেশ শ্রমসাধ্য। 4B মডেলটি প্রতিটি টোকেন কমপ্রেস করার সময় সেটি আগে পড়ে এবং তারপর লেখে, যা প্রতিটি এজেন্টের টার্নে ল্যাটেন্সি যোগ করে। ঘণ্টায় ভাড়া নেওয়া কার্ডের ক্ষেত্রে এই খরচটি অপেক্ষমাণ সময় হিসেবে দেখা দেয়, ইনভয়েসের কোনো লাইন আইটেম হিসেবে নয়, তাই এটি অনুভব না করা পর্যন্ত সহজে চোখে পড়ে না।

আপনি যদি সাধারণত ভাড়া করা GPU ঘণ্টা এবং API টোকেনের মধ্যে তুলনা করেন, তবে GPU VPS এবং API টোকেনের মধ্যে ব্রেক-ইভেন ইনফারেন্সের ক্ষেত্রে একই হিসাব অনুসরণ করে।

VPS-এ Paritok gateway চালানো

Python 3.10 বা তার পরবর্তী সংস্করণ প্রয়োজন। Ubuntu 24.04-এ Python 3.12 থাকে, তাই শুধুমাত্র CPU-ভিত্তিক কাজের জন্য একটি সাধারণ VPS ইমেজই যথেষ্ট।

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 জুলাই 2026-এ v1.2.8 এবং 5 আগস্ট 2026-এ v1.3.0 ট্যাগ করা হয়েছে। যে প্রজেক্ট এত দ্রুত পরিবর্তিত হয়, তারা রিলিজের মাঝে কনফিগারেশন কি (config keys) পরিবর্তন করে ফেলে। একটি সাধারণ pip install paritok, অথবা main-এর git clone ব্যবহার করলে পরের সপ্তাহে আপনি ভিন্ন একটি গেটওয়ে পাবেন এবং কোন সংস্করণের মাধ্যমে আপনি পরিমাপকৃত ফলাফল পেয়েছেন, তার কোনো রেকর্ড থাকবে না।

ডিফল্ট ব্যাকএন্ড হলো Ollama। মডেলটি পুল (pull) করুন, তারপর প্রক্সি যে ছোট নামটি খোঁজে তা প্রদান করুন।

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

এর পাশে paritok.yaml লিখুন। 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 হলো উপরের সবকিছুর শর্টকাট: এটি মডেলটি অনুপস্থিত থাকলে তা পুল করে এবং 8080 পোর্টে প্রক্সি চালু করে। কোনো এজেন্টকে এর দিকে নির্দেশ করার আগে প্রক্সিটি পরীক্ষা করে নিন।

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

/health একটি ছোট JSON অবজেক্ট রিটার্ন করে যাতে "status":"ok" এবং একটি ভার্সন স্ট্রিং থাকে। /stats কম্প্রেশনের মোট পরিমাণ এবং প্রক্সির নিজস্ব হিসাব অনুযায়ী সাশ্রয়ের পরিমাণ দেখায়। এই হিসাবটিকে প্রক্সির নিজের কাজের মূল্যায়ন হিসেবে দেখুন এবং আপনার প্রোভাইডারের ইউসেজ পেজের সাথে মিলিয়ে নিশ্চিত করুন।

সুবিধার চেয়ে থ্রুপুট (throughput) বেশি গুরুত্বপূর্ণ হলে, vLLM বেস মডেলের উপরে অ্যাডাপ্টারটি সার্ভ করে।

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

Ollama দ্রুত সেটআপ করা যায়। vLLM একই সাথে একাধিক অনুরোধ (concurrent requests) অনেক ভালো সামলাতে পারে, যা একাধিক এজেন্ট একই বক্সে শেয়ার করলে গুরুত্বপূর্ণ হয়ে ওঠে। Ollama এবং vLLM-এর মধ্যে ব্যবহারিক পার্থক্য বিষয়টি আপনার সিদ্ধান্ত নিতে সাহায্য করবে।

বেস URL এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করে এজেন্টকে প্রক্সির দিকে নির্দেশ করুন।

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 লিখে দেয়। শুধুমাত্র ভেরিয়েবলটি এক্সপোর্ট করলে Codex সরাসরি প্রোভাইডারের সাথে যোগাযোগ করবে, যার লক্ষণ হলো /stats কাউন্টারটি আপনার কাজের সময় কখনোই বাড়বে না।

লিসেনারকে সবসময় 127.0.0.1-এ রাখুন, কখনোই 0.0.0.0-এ নয়। প্রক্সি আপনার প্রোভাইডার API কি (key) আপস্ট্রিমে ফরোয়ার্ড করে, তাই ইন্টারনেট থেকে অ্যাক্সেসযোগ্য প্রক্সি সেই কি-এর জন্য একটি ওপেন রিলে হিসেবে কাজ করে: যে কেউ পোর্টটি খুঁজে পেলে আপনার কি না দেখেই আপনার টাকা খরচ করতে পারবে। পোর্টটি ওপেন না করে SSH টানেল বা VPN-এর মাধ্যমে ল্যাপটপ থেকে এটি অ্যাক্সেস করুন।

reboot-এর পরেও যেন সচল থাকে, সেজন্য এটি systemd-এর অধীনে চালান। আপনার ইন্সটলেশন অনুযায়ী পাথগুলো পরিবর্তন করে নিন।

[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 দিয়ে এটি এনাবল করুন, তারপর পুনরায় /health কার্ল (curl) করুন। কোনো ইউনিট চালু হয়েই বন্ধ হয়ে গেলে সাধারণত বুঝতে হবে কনফিগারেশন ফাইলের পাথ ভুল আছে, এবং journalctl -u paritok -n 50 সেই কারণটি প্রিন্ট করবে।

হোস্টেড অপশন এবং এর খরচ

এই প্রজেক্টটি একটি সার্ভিস হিসেবেও কম্প্রেশন সুবিধা বিক্রি করে। একটি API key দিয়ে use_gpu_server: true সেট করলে 4বি মডেলটি তাদের হার্ডওয়্যারে চলে। এর মূল্য প্রতি মিলিয়ন টোকেন প্রসেসিংয়ের জন্য $0.30, তবে তাদের ডকুমেন্টেশন অনুযায়ী আগস্ট 2026 পর্যন্ত এটি বিনামূল্যে ব্যবহার করা যাবে। এতে জিপিইউ ভাড়ার খরচ এবং উপরের সব অপারেশনাল কাজ থেকে মুক্তি পাওয়া যায়।

এর মানে হলো, আপনার প্রম্পট এবং আপনার এজেন্ট যে ফাইলগুলো পড়ে, সেগুলো আপনার মডেল প্রোভাইডারের কাছে পৌঁছানোর আগেই আপনার মেশিন থেকে বেরিয়ে তৃতীয় কোনো পক্ষের কাছে চলে যায়। এই বাড়তি ধাপটি এড়ানোর জন্যই মূলত সেলফ-হোস্টিং করা হয়। সেই ফ্ল্যাগটি সেট করার আগে সিদ্ধান্ত নিন আপনি কোনটির জন্য অপ্টিমাইজ করছেন, কারণ ফ্ল্যাগটি পরিবর্তন করা মাত্র এক লাইনের কাজ হলেও এর ফলাফল অনেক সুদূরপ্রসারী।

কিভাবে নিজের আগে এবং পরের পরিমাপ করবেন

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

  • কোনো proxy ছাড়া স্বাভাবিকভাবে এক সপ্তাহ কাজ করুন। আপনার প্রোভাইডারের usage page থেকে input tokens, cache-read tokens এবং output tokens আলাদা আলাদা লাইনে রেকর্ড করুন, মোট ডলারের অংক হিসেবে নয়।
  • পরের সপ্তাহে proxy সামনে রেখে একই ধরনের কাজ করুন।
  • input এবং cache-read লাইনগুলো তুলনা করুন। output প্রায় একই থাকার কথা, কারণ proxy এটি কম্প্রেস করে না। যদি output-এ বড় ধরনের পরিবর্তন হয়, তবে বুঝতে হবে proxy ছাড়া অন্য কিছু পরিবর্তিত হয়েছে।
  • আপনাকে কতগুলো কাজ পুনরায় করতে হয়েছে তা গণনা করুন। এটি ট্রেড-অফের গুণগত দিক, যা কোনো ড্যাশবোর্ডে দেখা যায় না।
  • মোট খরচের তুলনা করার আগে দ্বিতীয় সপ্তাহের সাথে GPU hours যোগ করুন।

input এবং output আলাদা করা জরুরি কারণ দুটির মূল্য ভিন্ন এবং কম্প্রেসার শুধুমাত্র একটির ওপর কাজ করে। আগস্ট 2026 অনুযায়ী, Claude Sonnet 4.6-এর খরচ প্রতি মিলিয়ন input tokens-এর জন্য $3 এবং প্রতি মিলিয়ন output tokens-এর জন্য $15, আর prompt-cache read-এর খরচ input রেটের 10%, অর্থাৎ প্রতি মিলিয়ন $0.30। input এবং output টোকেন খরচের পার্থক্য নির্ধারণ করে যে input-side কম্প্রেসার আপনার জন্য লাভজনক কি না। Claude Code-এর টোকেনগুলো আসলে কোথায় যায় তা আপনাকে জানাবে আপনার কনটেক্সটের কোন অংশটি কম্প্রেস করার মতো যথেষ্ট বড়।

Prompt caching বিশেষ করে tool-filter হিসাবকে জটিল করে তোলে। tool ব্লকটি রিকোয়েস্টের শুরুতে থাকে, তাই প্রথম টার্নের পর এটি সাধারণত 10% ইনপুট মূল্যে cache hit হিসেবে গণ্য হয়। একটি cached ব্লক থেকে 21,000 টোকেন কমালে প্রতি মিলিয়নে $0.30 হিসেবে প্রায় $0.006 সাশ্রয় হয়, যা uncached রেট অনুযায়ী $0.063 হওয়ার কথা ছিল। প্রজেক্টটি সেশনের জন্য ফিল্টার করা ব্লকটিকে ফ্রিজ করে রাখে যাতে cached প্রিফিক্স পরিবর্তিত না হয়। এমন কোনো ফিল্টার যা প্রতি টার্নে টুল পুনরায় নির্বাচন করে, তা প্রিফিক্সটিকে ইনভ্যালিড করে দেবে এবং সাশ্রয়ের চেয়ে খরচ বাড়িয়ে দেবে।

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

উপরের প্রতিটি পারফরম্যান্স সংখ্যা প্রকল্পটির নিজস্ব উৎস থেকে নেওয়া হয়েছে। SWE-bench Lite-এর ফলাফলের কোনো স্বাধীন পুনরুৎপাদন নেই, এবং জুলাই 2026 তারিখের প্রথম ট্যাগগুলোর কারণে কোডটির পেছনে খুব সামান্য অপারেশনাল ইতিহাস রয়েছে। কম্প্রেশন রেট এবং কোয়ালিটি-রিটেইনড ফিগার—উভয়ই সেই পক্ষ দ্বারা পরিমাপ করা হয়েছে যারা এগুলো ভালো দেখালে লাভবান হয়। এর মানে এই নয় যে এগুলো ভুল। এর মানে হলো এগুলো নিশ্চিত নয়, এবং আপনার নিজের তৈরি করা সংখ্যার চেয়ে এগুলোকে ভিন্নভাবে দেখা উচিত।

আপনার সেটআপকে দোষারোপ করার আগে একটি নথিভুক্ত আচরণ জেনে রাখা ভালো। টুল ফিল্টারে ব্যবহৃত এমবেডিং মডেলটি স্টার্টআপের পরিবর্তে প্রথম অনুরোধের সময় লোড হয়, তাই প্রকল্পটি 10 থেকে 15 সেকেন্ডের একটি ওয়ার্ম-আপের কথা উল্লেখ করে, এরপর প্রতি কলে প্রায় 15 ms সময় লাগে। প্রক্সি শুরু হওয়ার পর একটি অপ্রয়োজনীয় অনুরোধ পাঠান, তাহলে আপনার প্রথম প্রকৃত এজেন্ট টার্নটি হ্যাং হয়ে আছে বলে মনে হবে না।

চারটি বিষয় আপনি নিজেই এক বিকেলে যাচাই করতে পারেন: প্রক্সিটি শুরু হয় এবং চালু থাকে কি না, কাজ করার সময় /stats পরিবর্তিত হয় কি না, আপনার প্রোভাইডারের ইনপুট-টোকেন লাইন প্রকৃতপক্ষে কমে কি না, এবং এজেন্ট এখনও কাজ শেষ করতে পারে কি না। যেকোনো প্রকাশিত বেঞ্চমার্কের চেয়ে এই বিষয়গুলো আপনার সেটআপের জন্য অনেক ভালো সিদ্ধান্ত দেবে।

আপনার অন্যান্য টুলের পাশে এটি কোথায় অবস্থান করে সে বিষয়ে: একটি self-hosted LiteLLM gateway বিষয়বস্তু পরিবর্তন না করেই অনুরোধগুলোকে রুট এবং মিটার করে, তাই এই দুটি ভিন্ন সমস্যার সমাধান করে এবং এদের চেইন করা সম্ভব, যেখানে Paritok এজেন্টের সবচেয়ে কাছে থাকে। যদি প্রকৃত লক্ষ্য এই নির্দিষ্ট টুলের পরিবর্তে বিল কমানো হয়, তবে the wider set of cost controls for an agent on a VPS-এ এমন বেশ কিছু পরিবর্তন অন্তর্ভুক্ত রয়েছে যা আগে চেষ্টা করে দেখতে কোনো খরচ হয় না।

FAQ

Paritok কি আমার API বিল কমায় নাকি শুধু context-এর ব্যবহার কমায়?

এটি বিল কমায়, কারণ প্রোভাইডারের কাছে পৌঁছানোর আগেই প্রক্সি অনুরোধটি (request) নতুন করে লিখে ফেলে এবং প্রোভাইডার যা গ্রহণ করে তার ওপরই চার্জ করে। এই বিল কমার পরিমাণ শিরোনামে যা বলা হয়েছে তার চেয়ে কিছুটা কম। 74% সংখ্যাটি মূলত যে কন্টেন্ট সংকুচিত হচ্ছে তার কম্প্রেশন রেট। এন্ড-টু-এন্ড হিসেবে, প্রজেক্টটি একটি সিঙ্গেল টার্নে প্রায় 25% এবং 20তম টার্নে 63% সাশ্রয়ের রিপোর্ট করে, এবং শুধুমাত্র ইনপুট টোকেনগুলোই পরিবর্তিত হয়। আউটপুট টোকেনগুলো অপরিবর্তিত অবস্থায় পার হয়ে যায়।

কম্প্রেশন মডেলটি সেলফ-হোস্ট করার জন্য আমার কতটুকু GPU প্রয়োজন?

q4 বিল্ডটি প্রায় 2.5 GB এবং bf16 বিল্ডটি প্রায় 8 GB, তাই মডেলটি একটি 24 GB কার্ডে অনায়াসেই চলে এবং অনেক জায়গা খালি থাকে। ছোট কার্ডেও এটি কাজ করবে, যা আপনার ব্রেক-ইভেন হিসাবকে আরও সুবিধাজনক করে তুলবে। টুল-স্কিমা ফিল্টারের জন্য কোনো GPU-এর প্রয়োজন নেই: এটি BAAI/bge-small-en-v1.5 ব্যবহার করে, যা একটি 130 MB-এর এম্বেডিং মডেল এবং CPU-তে চলে। একটি সাধারণ VPS-এ paritok[toolselect] ইনস্টল করুন এবং সামান্য RAM খরচে টুল-ব্লক রিডাকশনের সুবিধা পান।

কম্প্রেসার যদি এমন কিছু মুছে ফেলে যা এজেন্টের প্রয়োজন ছিল, তবে কী হবে?

কিছুই মুছে ফেলা হয় না। সংকুচিত অংশগুলো একটি [REF:id] ট্যাগ বহন করে এবং মডেলটি read_original বা expand_context ব্যবহার করে সম্পূর্ণ টেক্সট পুনরুদ্ধার করে। ফিল্টার করা টুল স্কিমাগুলো মুছে ফেলার পরিবর্তে স্টাব (stub) হিসেবে রাখা হয় এবং মডেলটি gateway_search_tools ব্যবহার করে সেগুলো পুনরুদ্ধার করে। আসল ঝুঁকিটি ফাইল হারিয়ে যাওয়ার চেয়েও সূক্ষ্ম: মডেলটি একটি লসি (lossy) সামারি থেকে কাজ করে এবং কখনোই বুঝতে পারে না যে তার মূল ফাইলটি চাওয়া উচিত ছিল। SWE-bench Lite-এ 86.5% কোয়ালিটি-রিটেইনড সংখ্যাটি মূলত এটিই পরিমাপ করছে।

আমার প্রথম অনুরোধটি সম্পন্ন হতে কেন পনেরো সেকেন্ড সময় লাগে?

টুল ফিল্টারের পেছনে থাকা এম্বেডিং মডেলটি স্টার্টআপের সময় নয়, বরং প্রথম অনুরোধের সময় লোড হয়। প্রজেক্টের ডকুমেন্টেশন অনুযায়ী 10 থেকে 15 সেকেন্ডের একটি ওয়ার্ম-আপ সময় লাগে, এরপর প্রতিটি কলের জন্য প্রায় 15 ms সময় প্রয়োজন হয়। প্রক্সি শুরু করার পর curl দিয়ে একটি অপ্রয়োজনীয় অনুরোধ পাঠান, তাহলে প্রথম আসল এজেন্ট টার্নটি আর আটকে থাকবে না।

আমার কি সেলফ-হোস্টিংয়ের পরিবর্তে হোস্ট করা GPU সার্ভার ব্যবহার করা উচিত?

এটি GPU ভাড়া এবং রক্ষণাবেক্ষণের ঝামেলা দূর করে, যার মূল্য আগস্ট 2026 অনুযায়ী প্রতি মিলিয়ন টোকেন প্রসেস করার জন্য $0.30। এটি আপনার প্রম্পট এবং আপনার এজেন্টের পড়া ফাইলগুলো আপনার মডেল প্রোভাইডারের কাছে পৌঁছানোর আগেই একটি তৃতীয় পক্ষের কাছে পাঠিয়ে দেয়। আপনি যদি আপনার নিয়ন্ত্রণাধীন ইনফ্রাস্ট্রাকচারে কোড রাখার জন্য সেলফ-হোস্ট করে থাকেন, তবে এই সেটিংসটি আপনার শুরুর উদ্দেশ্যকেই ব্যর্থ করে দেবে। সেলফ-হোস্টিং আপনার কনটেক্সট এবং প্রোভাইডার API কি (key) উভয়ই আপনার নিজের বক্সে সুরক্ষিত রাখে।