Claude Opus 5-এর নতুন prompt-caching API চ্যাট-স্টাইল অ্যাপগুলোর টোকেন বিল বহুগুণ কমিয়ে দেয়, কারণ এটি মডেলকে অপরিবর্তিত টেক্সট পুনরায় পড়া থেকে বিরত রাখে। প্রথম রিকোয়েস্টের জন্য সামান্য অতিরিক্ত ফি দিতে হয়; কিন্তু পরবর্তী প্রতিটি হিট মূল হারের প্রায় এক-দশমাংশ খরচ করে, যা একটি পুনরাবৃত্তিমূলক খরচকে এককালীন চার্জে পরিণত করে।
কেন ডেভেলপাররা একই শব্দের জন্য দুবার টাকা দেন
বেশিরভাগ কনভারসেশনাল ইন্টারফেস প্রতিটি টার্নে সম্পূর্ণ প্রম্পটটি পুনরায় তৈরি করে: একটি ৮,০০০-টোকেন বিশিষ্ট system prompt, সংযুক্ত PDF এবং সম্পূর্ণ কথোপকথনের ইতিহাস প্রতিবার ব্যবহারকারী যখন ফলো-আপ প্রশ্ন করেন, তখন মডেলের কাছে একসাথে পাঠানো হয়। টেক্সটের বড় অংশ অপরিবর্তিত থাকা সত্ত্বেও মডেল প্রতিটি টোকেন পুনরায় প্রসেস করে। বর্তমান মূল্যের হিসেবে, এই অতিরিক্ত প্রসেসিং একটি ব্যস্ত বটের খরচের সিংহভাগ দখল করে নিতে পারে।
ক্যাশ কীভাবে হিসাব বদলে দেয়
API একটি নির্দিষ্ট ব্রেকপয়েন্ট পর্যন্ত টোকেনের প্রতিটি “ব্লক”-এর জন্য একটি ক্যাশ এন্ট্রি তৈরি করে। যখন পরবর্তী রিকোয়েস্টে শুরুর দিকে একই ব্লক থাকে, তখন সার্ভিসটি এটিকে পুনরায় টোকেনাইজ করার পরিবর্তে ক্যাশ থেকে পড়ে নেয়। মূল্যের বিভাজনটি সাশ্রয় হওয়া কাজের প্রতিফলন ঘটায়:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
বাস্তবে, একটি নতুন ব্লকের প্রথম কলটি একটি সাধারণ রিকোয়েস্টের চেয়ে কিছুটা বেশি খরচ করে। ক্যাশ হিট করা পরবর্তী প্রতিটি কল ৯০% সস্তা, তাই কথোপকথন যত দীর্ঘ হয়, মোট খরচ তত দ্রুত কমে আসে।
প্রম্পট স্ট্রাকচার করার জন্য “গোল্ডেন রুল”
ক্যাশের কার্যকারিতা নির্ভর করে আপনি স্ট্যাটিক (স্থির) এবং ডাইনামিক (পরিবর্তনশীল) কন্টেন্ট কোথায় রাখছেন তার ওপর। যা অপরিবর্তিত থাকে তা শুরুতে রাখুন এবং পরিবর্তনশীল অংশগুলো শেষে পাঠিয়ে দিন। একটি নির্ভরযোগ্য ক্রম দেখতে এমন হতে পারে:
- Tools – মডেল যে কোনো এক্সটার্নাল ফাংশন কল করতে পারে তার সংজ্ঞা।
- System instructions – মডেলটি কোন উচ্চ-স্তরের আচরণ অনুসরণ করবে তার নির্দেশাবলী।
- Documents – দীর্ঘ কনটেক্সট যেমন PDF, নলেজ বেস বা পলিসি উদ্ধৃতি।
- User questions – লাইভ কুয়েরি যা প্রতিটি টার্নে পরিবর্তিত হয়।
আপনি যদি কোনো ব্রেকপয়েন্টের আগে কোনো টোকেন পরিবর্তন করেন, তবে ক্যাশ এন্ট্রিটি ইনভ্যালিড হয়ে যাবে এবং মডেলকে এরপরের সবকিছু পুনরায় প্রসেস করতে হবে।
কিছু লুকানো সীমাবদ্ধতা যা আপনাকে মেনে চলতে হবে
- Minimum block size – Opus 5 শুধুমাত্র সেই ব্লকগুলো ক্যাশ করে যাতে অন্তত ৫১২টি টোকেন থাকে। এর চেয়ে ছোট কিছু হলে তা সম্পূর্ণভাবে ক্যাশ থেকে বাদ পড়ে যাবে।
- Timestamp bug – একটি ক্যাশ করা ব্লকের ভেতরে পরিবর্তনশীল টাইমস্ট্যাম্প যুক্ত করলে ক্যাশ মিস হওয়া নিশ্চিত, কারণ ব্লকের টেক্সট কখনোই হুবহু মিলবে না।
- 20-block look-back – সার্ভিসটি মিল খোঁজার জন্য শুধুমাত্র শেষ ২০টি ব্লক স্ক্যান করে। দীর্ঘস্থায়ী সেশন যা দ্রুত এগিয়ে যায়, তা ক্যাশ উইন্ডো অতিক্রম করে যেতে পারে।
- Parallel requests – একই সময়ে বেশ কয়েকটি অভিন্ন রিকোয়েস্ট পাঠালে সবগুলোই মিস হবে, কারণ প্রথম রিকোয়েস্ট শেষ হওয়ার পরেই কেবল ক্যাশ পপুলেট হয়। একটি সিঙ্গেল কলের মাধ্যমে ক্যাশটি 'ওয়ার্ম' করে নিন, তারপর বাকিগুলো পাঠান।
আপনার API রেসপন্সে সাশ্রয় দেখা
প্রতিটি রেসপন্স তিনটি টোকেন কাউন্টার রিপোর্ট করে:
cache_read_input_tokens– ক্যাশ হিট থেকে আসা টোকেন।cache_creation_input_tokens– এই রিকোয়েস্টে ক্যাশে লেখা টোকেন।input_tokens– নতুন টোকেন যা ক্যাশ করা হয়নি।
ওই টার্নে মডেল মোট কতগুলো টোকেন বিবেচনা করেছে তা জানতে তিনটি সংখ্যা যোগ করুন। যদি উভয় ক্যাশ ফিল্ডই শূন্য হয়, তবে রিকোয়েস্টটি ক্যাশ মিস করেছে; সেক্ষেত্রে আপনার ব্লক সাইজ এবং ব্রেকপয়েন্ট প্লেসমেন্ট পরীক্ষা করুন।
সারসংক্ষেপ: অপরিবর্তনযোগ্য কনটেক্সট শুরুতে রাখার মাধ্যমে এবং Claude Opus 5-এর prompt-caching API-কে মূল কাজ করতে দিয়ে, আপনি একটি পুনরাবৃত্তিমূলক টোকেন খরচকে এককালীন চার্জে পরিণত করতে পারেন। এর ফলে যে কোনো চ্যাটবটের খরচ নাটকীয়ভাবে কমে যাবে যা বারবার একই system prompt বা ডকুমেন্ট সেট রেফারেন্স করে—যদি আপনি টোকেন ফ্লোর মেনে চলেন, ক্যাশ করা ব্লকের ভেতরে পরিবর্তনশীল মার্কার এড়িয়ে চলেন এবং আপনার ক্যাশ-যোগ্য কন্টেন্ট ২০-ব্লক দিগন্তের মধ্যে রাখেন।