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

এই পোস্টের মূল বিষয় হল ক্যাশিং মেকানিজম ব্যবহার করে টোকেন সঞ্চয় করা। লেখক এক সপ্তাহে 3 কোটিরও বেশি টোকেন ক্যাশিং দ্বারা পুনঃব্যবহার করেছেন, যার দৈনিক ক্যাশিং পরিমাণ ছিল 910 লক্ষ। যেহেতু ক্যাশিং টোকেনের খরচ সাধারণ ইনপুট টোকেনের মাত্র 10%, এর অর্থ 910 লক্ষ ক্যাশিং টোকেনের বাস্তব বিলিং পরিমাণ প্রায় 90 লক্ষ সাধারণ টোকেনের সমান। Claude Code-এর দীর্ঘ সেশনগুলি যেহেতু আরও "টেকসই" মনে হয়, তা মডেলটি বিনামূল্যে কাজ করছে বলে নয়, বরং অসংখ্য পুনরাবৃত্তির কনটেক্সট সফলভাবে পুনঃব্যবহার করা হয়েছে।

প্রম্পট ক্যাশিং-এর মূল বিষয় হলো "ক্যাশ বিচ্ছিন্ন করবেন না"। Claude Code সিস্টেম প্রম্পট, টুল সংজ্ঞা, CLAUDE.md, প্রকল্প নিয়ম এবং ইতিহাসের কথোপকথনকে স্তরবদ্ধভাবে ক্যাশ করে; যদি পরবর্তী অনুরোধের প্রাথমিক অংশ একই থাকে, তাহলে Claude সম্পূর্ণ প্রসঙ্গটি পুনরায় প্রক্রিয়াকরণের পরিবর্তে সরাসরি ক্যাশ থেকে পড়তে পারে। Anthropic অভ্যন্তরীণভাবেও প্রম্পট ক্যাশের পুনঃব্যবহারের হার পর্যবেক্ষণ করে, কারণ এটি শুধুমাত্র ব্যবহারকারীর কোটা প্রভাবিত করে না, বরং মডেল সার্ভিসের খরচ এবং চলমান দক্ষতারও সরাসরি সম্পর্কিত।

সাধারণ ব্যবহারকারীদের জন্য, সমস্ত অন্তর্নিহিত বিস্তারিত বুঝতে হবে না, শুধু কয়েকটি গুরুত্বপূর্ণ অভ্যাস অনুসরণ করুন: 1 ঘন্টার বেশি সেশনটি খালি রাখবেন না; টাস্ক পরিবর্তনের সময় session handoff ভালভাবে করুন; মডেল পরিবর্তন করা থেকে এড়িয়ে চলুন; বড় ডকুমেন্টগুলি পুনরায় কপি-পেস্ট না করে Projects-এ রাখুন।

এই নিবন্ধটি একটি টোকেন সঞ্চয়ের কৌশল নিয়ে বলছে না, বরং একটি ইঞ্জিনিয়ারিং চিন্তাভাবনার সাথে বেশি মিলে যাওয়া Claude Code ব্যবহারের পদ্ধতি প্রদান করছে: প্রসঙ্গকে সম্পদ ব্যবস্থাপনা হিসাবে বিবেচনা করুন, ক্যাশ চিরস্থায়ীভাবে পুনরায় ব্যবহার করুন, এবং দীর্ঘ সেশনগুলিতে পুনরাবৃত্তির গণনা কমিয়ে দিন।

নিম্নলিখিত মূল পাঠ:

আমি এই সপ্তাহে 3 শত মিলিয়ন টোকেন সঞ্চয় করেছি, একদিনে 91 মিলিয়ন, এক সপ্তাহে 3 শত মিলিয়নের বেশি।

আমি কোনও সেটিং পরিবর্তন করিনি। এটি শুধুমাত্র পিছনে প্রম্পট ক্যাশিং স্বাভাবিকভাবে কাজ করছে।

কিন্তু আমি যখন ক্যাশ কী এবং ক্যাশকে "বিচ্ছিন্ন" করা থেকে কীভাবে বাঁচা যায় তা বুঝতে পারলাম, তখন একই ব্যবহার সীমার মধ্যে আমার সেশনগুলি আরও বেশি সময় ধরে রইল। তাই, এখানে API-এর গভীর বিস্তারিত ছাড়াই Claude Code prompt caching-এর 80/20 শুরুর গাইড দেওয়া হল।

TL;DR

ক্যাশেড টোকেনের খরচ সাধারণ ইনপুট টোকেনের 10% মাত্র। 91 মিলিয়ন ক্যাশেড টোকেনের বাস্তব চার্জ প্রায় 9 মিলিয়ন টোকেনের সমান।

ক্লড কোড সাবস্ক্রিপশনের ক্যাশ টিটিএল হল 1 ঘন্টা; এপিআই ডিফল্ট হল 5 মিনিট; সাব-এজেন্ট সবসময় 5 মিনিট।

ক্যাশ তিনটি স্তরে বিভক্ত: সিস্টেম লেভেল, প্রজেক্ট লেভেল, ডায়ালগ লেভেল।

সেশনের মধ্যে মডেল পরিবর্তন করলে ক্যাশ বাতিল হয়ে যায়, যার মধ্যে «opus plan» মোড চালু করা অন্তর্ভুক্ত।

ক্যাশ কিভাবে চার্জ করা হয়?

প্রতিটি ক্যাশেড টোকেনের খরচ সাধারণ ইনপুট টোকেনের 10%।

সুতরাং, যখন আমার ড্যাশবোর্ড দেখায় যে একদিনে 91 মিলিয়ন টোকেন ক্যাশে হয়েছে, তখন বাস্তবে বিলিং প্রায় মাত্র 9 মিলিয়ন টোকেনের সমতুল্য। এটাই কারণ যে, ক্যাশ ছাড়া তুলনায়, দীর্ঘসময় ধরে Claude Code ব্যবহার করলে সেশনগুলি প্রায় “ফ্রি”ভাবে বাড়ছে বলে মনে হয়।

ড্যাশবোর্ডে দুটি সংখ্যা বিশেষভাবে মনোযোগ দেওয়ার মতো:

ক্যাশ তৈরি: ক্যাশে কন্টেন্ট লেখার সময় একবারের জন্য যে খরচ হয়। এটি পরবর্তী কথোপকথনে কাজ শুরু করবে।
ক্যাশ পড়া: ক্লাউড দ্বারা ক্যাশ থেকে পুনঃব্যবহৃত টোকেন, যেমন আপনার CLAUDE.md, টুল সংজ্ঞা, পূর্ববর্তী বার্তা ইত্যাদি। পুনরায় ইনপুট হিসাবে প্রক্রিয়া করার তুলনায় এটি 10 গুণ সস্তা।

যদি আপনার ক্যাশ রিড সংখ্যা বেশি হয়, তাহলে আপনি ক্যাশকে কার্যকরভাবে ব্যবহার করছেন; যদি এই সংখ্যা কম হয়, তাহলে আপনি একই সেট কনটেক্সটের জন্য বারবার পেমেন্ট করছেন।

অ্যানথ্রোপিকের থারিকের একটি বাক্য আমাকে গভীরভাবে প্রভাবিত করেছিল: "আমরা প্রম্পট ক্যাশের হিট রেট বাস্তবিকভাবে মনিটর করি, যখন হিট রেট খুব কম হয়, তখন একটি অ্যালার্ম ট্রিগার হয়, এমনকি SEV-লেভেলের দুর্ঘটনা ঘোষণা করা হয়।"

তিনি একটি খুব ভালো X আর্টিকেলও লিখেছেন। ক্যাশ হিট রেট যখন উচ্চ থাকে, তখন চারটি বিষয় একসাথে ঘটে: Claude Code-এর অনুভূতি দ্রুততর হয়, Anthropic-এর সার্ভিস খরচ কমে, আপনার সাবস্ক্রিপশন ক্রেডিট বেশি টিকে, এবং দীর্ঘসময়ের কোডিং সেশনগুলি আরও বাস্তবসম্মত হয়।

কিন্তু যদি হিট রেট খুব কম হয়, তাহলে সবাই ক্ষতিগ্রস্ত হবে।

সুতরাং, উভয় পক্ষের উদ্দেশ্য আসলে একই: Anthropic চায় আপনার ক্যাশ হিট রেট বেশি হোক, আপনিও চান হিট রেট বেশি হোক। প্রকৃতপক্ষে কেবলমাত্র কিছু ছোটখাটো, কিন্তু ক্যাশ রিসেট করে দেওয়ার মতো অদৃশ্য অভ্যাসই বাধা হয়ে দাঁড়ায়।

কিভাবে প্রতিটি কথোপকথনে ক্যাশ বৃদ্ধি পায়?

ক্যাশে প্রিফিক্স ম্যাচিং-এর উপর নির্ভর করে, অর্থাৎ «প্রিফিক্স ম্যাচিং»।

খুব গভীর প্রযুক্তিগত বিস্তারিতে পড়ে যাবেন না, আপনাকে শুধু একটা জিনিস বুঝতে হবে: যদি কোনো অবস্থানের আগের কন্টেন্ট এবং ইতিমধ্যে ক্যাশেড কন্টেন্ট সম্পূর্ণরূপে একই হয়, তাহলে Claude সেই ক্যাশেড Token-এর পুনর্ব্যবহার করতে পারে।

একটি সম্পূর্ণ নতুন সেশন, যা এভাবে শুরু হয়েছিল:

ক্লড কোড ডকুমেন্টের অনুযায়ী, একটি সম্পূর্ণ নতুন সেশন এভাবে চলে:

প্রথম কথোপকথন: কোনো ক্যাশে নেই। সিস্টেম প্রম্পট, আপনার প্রকল্পের প্রেক্ষাপট (যেমন CLAUDE.md, memory, নিয়ম), এবং আপনার প্রথম বার্তা পুনরায় প্রক্রিয়াকরণ করা হবে এবং ক্যাশেতে লেখা হবে।

দ্বিতীয় পর্বের কথোপকথন: প্রথম পর্বের সমস্ত বিষয়বস্তু এখন ক্যাশ করা হয়েছে। Claude শুধুমাত্র আপনার নতুন উত্তর এবং পরবর্তী বার্তা প্রক্রিয়া করবে। এই পর্বের খরচ অনেক কম হবে।

তৃতীয় সংলাপ: যুক্তি একই। পূর্ববর্তী সংলাপগুলি ক্যাশেত রাখা হয়েছে, শুধুমাত্র সর্বশেষ সংলাপটি পুনরায় প্রক্রিয়াকরণের প্রয়োজন।

ক্যাশে নিজেকে তিনটি স্তরে বিভক্ত করা যেতে পারে:

থারিকের এক্স নিবন্ধ:

সিস্টেম স্তর (System layer): বেসিক নির্দেশনা, টুল সংজ্ঞা (read, write, bash, grep, glob) এবং আউটপুট স্টাইল অন্তর্ভুক্ত করে। এই স্তরটি গ্লোবালি ক্যাশেড হয়।

প্রকল্প স্তর (Project layer): এটি CLAUDE.md, memory, প্রকল্প নিয়ম অন্তর্ভুক্ত করে। এই স্তরটি প্রকল্প অনুযায়ী ক্যাশে করা হয়।

কনভারসেশন: উত্তর এবং বার্তা অন্তর্ভুক্ত করে, যা প্রতিটি পর্যায়ে বাড়তে থাকে।

যদি সেশনের মধ্যে সিস্টেম বা প্রোজেক্ট লেভেলের যেকোনো কিছু পরিবর্তন হয়, তাহলে সমস্ত কিছুকে আবার শুরু থেকে ক্যাশ করতে হবে। এটিই সবচেয়ে বেশি "খরচ" হওয়া অপারেশন। কল্পনা করুন: আপনি ১৬তম বার্তা পর্যন্ত কথা বলছেন, হঠাৎ করে সিস্টেম প্রম্পট পরিবর্তন হয়ে গেল, অথবা এক ঘন্টা বিরতি নিলেন—তাহলে ১ম বার্তা থেকে সবগুলো Token-কে আবার প্রসেস করতে হবে।

1 ঘন্টা এবং 5 মিনিটের বিভ্রান্তি

এটি সবচেয়ে বেশি ভুলবোধ করার জায়গা।

ক্লড কোড সাবস্ক্রিপশন: ডিফল্ট টিটিএল হল 1 ঘন্টা।

Claude API: ডিফল্ট TTL হল 5 মিনিট। আপনি বেশি খরচ করে এটিকে 1 ঘন্টায় বাড়াতে পারেন।
যেকোনো পরিকল্পনার অধীনে সাব-এজেন্ট: সর্বদা 5 মিনিট।

Claude.ai ওয়েব চ্যাট: অফিসিয়ালভাবে কোনো রেকর্ড নেই। সম্ভবত সাবস্ক্রিপশন ভার্সনের মতো, কিন্তু আমি এখনও নিশ্চিত হইনি।

কয়েক মাস আগে, অনেকে অভিযোগ করেছিল যে Claude সাবস্ক্রিপশনের ক্রেডিট খুব দ্রুত শেষ হয়ে যাচ্ছে। তখন কেউ কেউ ভাবছিলেন যে Anthropic গোপনে TTL-কে 1 ঘন্টা থেকে 5 মিনিটে কমিয়েছে এবং ব্যবহারকারীদের কোনো জানানো করেনি। কিন্তু বাস্তবতা এটা নয়, Claude Code-এর TTL এখনও 1 ঘন্টা।

সমস্যা হলো, Claude Code এবং API-এর ডকুমেন্টেশন আলাদা আলাদা, আর এই দুটি পুরোপুরি ভিন্ন জিনিস, যার ফলে অনেক বিভ্রান্তি হয়েছে।

যদি আপনি বড় পরিমাণে সাব-এজেন্ট ওয়ার্কফ্লো চালান বা সরাসরি API ব্যবহার করেন, তাহলে 5 মিনিটের সংখ্যাটি গুরুত্বপূর্ণ। কিন্তু 95% ক্লেড কোড ব্যবহারকারীর জন্য, আসলে যা মনোযোগ দেওয়ার দরকার তা হল 1 ঘন্টার উইন্ডো।

৯৫% ব্যবহারকারীকে কভার করে এমন তিনটি অভ্যাস

এগুলো হল আমার দৈনন্দিন ব্যবহারের জন্য প্রকৃতপক্ষে উপযোগী অংশ।

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

/compact বা /clear ইতিমধ্যেই ক্যাশ ভাঙবে, তাই এই পয়েন্টে আসলে একবারে রিসেট করে দিন।

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

কমপ্যাক্ট কমান্ড কখনও কখনও ধীরে চলে। আর এই হ্যান্ডঅফ স্কিল সাধারণত এক মিনিটের কম সময়ে শেষ হয়।

Claude.ai-এ ক্যাশ মেকানিজমের জন্য খুব বিস্তারিত অফিসিয়াল বর্ণনা নেই, কিন্তু Projects-এর সাথে সাধারণ কথোপকথন থ্রেডগুলির অপ্টিমাইজেশন ভিন্ন। তাই, যদি আপনি বড় ডকুমেন্ট পেস্ট করতে চান, তবে এগুলিকে কথোপকথনের মধ্যে না রেখে Projects-এ রাখুন।

কোন অপারেশনগুলি ক্যাশ ধ্বংস করে ফেলে?

কিছু বিষয় ছাড়াই স্পষ্ট সতর্কবার্তা ছাড়াই ক্যাশ সম্পূর্ণভাবে রিসেট হয়ে যায়।

মডেল পরিবর্তন করুন: ক্যাশে প্রিফিক্স মিলের উপর নির্ভর করে, এবং প্রতিটি মডেলের নিজস্ব ক্যাশে রয়েছে। যখনই মডেল পরিবর্তন করা হয়, পরবর্তী অনুরোধটি কোনো ক্যাশে হিট ছাড়াই সম্পূর্ণ ইতিহাস পুনরায় পড়বে।

「Opus প্ল্যান» মোড: এই সেটিংটি পরিকল্পনা পর্যায়ে Opus ব্যবহার করে এবং বাস্তবায়ন পর্যায়ে Sonnet ব্যবহার করে। আমি আগে কিছু টোকেন অপ্টিমাইজেশন ভিডিওতে এটির প্রস্তাব দিয়েছিলাম, যার কারণ আছে। তবে বুঝতে হবে যে, প্রতিবার প্ল্যান পরিবর্তন করা মূলত একটি মডেল পরিবর্তন, যার অর্থ ক্যাশ পুনরায় তৈরি করা। দীর্ঘমেয়াদে, এটি সেশন কোটা বাড়াতে সহায়তা করে, কিন্তু আপনাকে নীচের প্রক্রিয়াটি বুঝতে হবে।

সেশনের মধ্যে CLAUDE.md সম্পাদনা করা যাবে: এই পরিবর্তন তাত্ক্ষণিকভাবে কার্যকর হবে না, পরবর্তী রিস্টার্ট পর্যন্ত অপেক্ষা করতে হবে। তাই, বর্তমানে চলমান ক্যাশ প্রভাবিত হবে না।

আমি আগে যে স্ক্রিনশটটি দেখিয়েছি, তা একটি টোকেন ড্যাশবোর্ড থেকে এসেছে।

এটি একটি খুব সাধারণ GitHub রিপোজিটরি। আপনি লিঙ্কটি Claude Code-এর কাছে দিন, এটি স্থানীয় localhost-এ ডিপ্লয় করবে, এবং এটি শূন্য অবস্থা থেকে গণনা শুরু না করে আপনার অতীতের সমস্ত সেশনের রেকর্ড পড়বে। আপনি প্রথম থেকেই প্রতিদিনের input, output, cache create এবং cache read ডেটা দেখতে পাবেন।

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

সারাংশ

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

কিন্তু আপনাকে সব বিস্তারিত বুঝতে হবে না যাতে আপনি এটি থেকে লাভ পান। আপনাকে শুধুমাত্র সবচেয়ে গুরুত্বপূর্ণ 80/20 টি জানতে হবে: ক্যাশেড টোকেন সাধারণ টোকেনের চেয়ে 10 গুণ সস্তা; Claude Code-এর TTL হল 1 ঘন্টা; মডেল পরিবর্তন করলে ক্যাশে ভাঙবে; কাজগুলির মধ্যে পরিষ্কারভাবে হস্তান্তর করা সাধারণত একটি পুরনো সেশনকে "সময়সীমা শেষ" হওয়ার পরে জোর করে চালিয়ে যাওয়ার চেয়ে বেশি লাভজনক।