দ্বারা Claude prompt caching: কখন খরচ উঠে আসে
Cache write-এর খরচ 1.25x, read 0.1x বা কম। তাই Claude prefix দ্বিতীয় ব্যবহারে লাভে যায়। নিজে break-even হিসাব করুন এবং API দিয়ে প্রমাণ দেখুন।
সাশ্রয় শুরু হওয়ার আগে prompt caching-এর খরচ
Prompt caching প্রতিটি call-এ prompt-এর শুরুর অংশ আবার পড়ার পরিবর্তে Claude-কে সেটি পুনর্ব্যবহার করতে দেয়। পুরো সিদ্ধান্তটি model-এর base input price-এর ওপর প্রযোজ্য দুটি multiplier-এর ওপর নির্ভর করে। October 2026 অনুযায়ী, 5 minute lifetime-এর জন্য cache write-এর খরচ সব model-এ base input-এর 1.25x, আর 1 hour lifetime-এর জন্য 2x। বেশিরভাগ model-এ cache read-এর খরচ 0.1x। তবে এখন সব model-এ read multiplier এক নয়। Claude Fable 5.1 এবং Claude Mythos 5.1-এ এটি 0.025x; এই rate-এ সেগুলো September 1, 2026-এ চালু হয়। Claude Opus 5.5 এবং Claude Sonnet 5.5-এ এটি 0.05x। Sonnet 5.5-এর rate October 7, 2026-এ 0.1x থেকে কমিয়ে এই rate করা হয়। নিচের উদাহরণে standard 0.1x read ব্যবহার করা হয়েছে। কম read cost হলে break-even আপনার পক্ষে সামান্য এগিয়ে যায়। পরের section-এ এর পরিমাণ দেখানো হয়েছে।
এখানে এখন একটি surcharge দিয়ে পরে discount পাওয়ার বিনিময় হয়। একটি prefix সংরক্ষণ করতে একবার অতিরিক্ত খরচ হয়। এরপর একই bytes দিয়ে হুবহু শুরু হওয়া প্রতিটি request-এ ওই অংশের জন্য স্বাভাবিক input price-এর এক-দশমাংশ দিতে হয়। উপরে উল্লেখ করা model-গুলোতে খরচ আরও কম। কোনো prefix তার lifetime-এর মধ্যে একবারও পুনর্ব্যবহৃত না হলে, কোনো সুবিধা ছাড়াই তার জন্য 25 percent অতিরিক্ত খরচ হয়।
এক লাইনের বীজগণিতে break-even
ধরা যাক, prefix-টি cache না করে পাঠালে এর base input cost হলো B। Caching ছাড়া Nটি request-এর খরচ হয় B-এর N গুণ। 5 minute cache ব্যবহার করলে প্রথম request-এ prefix লেখার খরচ হয় 1.25B, এবং বাকি N minus 1টি request-এ সেটি পড়ার খরচ হয় 0.1B। দুই খরচ সমান করলে পাওয়া যায় 0.9N = 1.15, তাই N = 1.28। অর্থাৎ caching একেবারেই না করার তুলনায় দ্বিতীয় request থেকেই খরচ কম।
1 hour cache-এর 2x write দিয়ে একই হিসাব করলে পাওয়া যায় 0.9N = 1.9, তাই N = 2.11। দীর্ঘ cache break-even-এ পৌঁছানোর আগে দুটি read প্রয়োজন। এ কারণেই এটি default choice নয়।
Read-এর খরচ আরও কম হলে রেখাটি সরে, তবে বেশি নয়। 0.05x read-এ 5 minute cache-এর জন্য 0.95N = 1.2, তাই N = 1.26। 0.025x read-এ এটি হয় 0.975N = 1.225, অর্থাৎ N = 1.26। 1 hour cache-এর ক্ষেত্রে মান দুটি কমে যথাক্রমে N = 2.05 এবং N = 2.03 হয়। ব্যবহারিক সিদ্ধান্ত প্রতিটি model-এই একই: 5 minute cache দ্বিতীয় request থেকে সাশ্রয়ী, আর 1 hour cache তৃতীয় request থেকে সাশ্রয়ী।
নিচের chart-এ Claude Opus 5-এর 20,000 token prefix-এর হিসাব দেখানো হয়েছে। October 2026 অনুযায়ী এর base input rate প্রতি million token-এ $5, এবং August থেকে তা অপরিবর্তিত। Opus 5 এখন একটি legacy model, যদিও এটি এখনও available। এর successor Claude Opus 5.5 প্রতি million token-এ $4 এবং 0.05x read rate দেয়। সেখানে একই prefix লিখতে খরচ হয় $0.10 এবং পড়তে $0.004। Standard 0.1x read-এ প্রতি million token-এ $3 দামের model-এর জন্য প্রতিটি মান 0.6 দিয়ে গুণ করুন। Curve-এর আকৃতি পরিবর্তন হবে না।
এই চার্টের পেছনের ডেটা
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]একটি request একাই পাঠালে uncached অবস্থায় খরচ হয় $0.10, আর cached অবস্থায় খরচ হয় $0.125। তাই একবারই ব্যবহার করা prompt cache করা সম্পূর্ণ লোকসানের কাজ। দ্বিতীয় request-এ 5 minute cache-এর খরচ হয় $0.135, যেখানে uncached খরচ $0.20। সেই সময়ে 1 hour cache এখনও পিছিয়ে থাকে: এর খরচ $0.21, যেখানে একই uncached খরচ $0.20। তৃতীয় request-এ গিয়ে এটি uncached খরচের রেখা অতিক্রম করে: $0.22, যেখানে uncached খরচ $0.30। 20টি request-এ পার্থক্য হলো $2.00 বনাম $0.315।
Cache hit হলে entry-টির lifetime-ও refresh হয়। এ কারণেই প্রকাশিত price table-এ ওই column-এর নাম cache hits and refreshes। তাই ব্যস্ত endpoint read price-এ 5 minute entry অনির্দিষ্টকাল সক্রিয় রাখতে পারে। 1 hour lifetime-এর 2x write তখনই সার্থক হয়, যখন আপনার traffic-এ বাস্তব বিরতি থাকে।
কম hit rate-এর খরচ
বাস্তব traffic-এ cache miss হয়। কোনো request cache miss করলেও যদি breakpoint বহন করে, সেটিকে write হিসেবে charge করা হয়। তাই hit rate-এর ফাংশন হিসেবে cost গণনা করাই সঠিক পদ্ধতি। নিচের chart-এ 1,000টি request-এর জন্য এই হিসাব দেখানো হয়েছে। প্রতিটি request-এ একই 20,000 token prefix রয়েছে।
এই চার্টের পেছনের ডেটা
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]0 percent hit rate-এ আপনি $125.00 পরিশোধ করেন, যেখানে cache ছাড়া খরচ হতো $100.00। 1 hour cache ব্যবহার করলে bill দ্বিগুণ হয়ে $200.00 হয়। 1.25 minus 1.15h = 1 সমাধান করলে দেখা যায়, 5 minute cache প্রায় 22 percent hit rate থেকে সাশ্রয় শুরু করে। তাই 25 percent hit rate-এই খরচ $96.25 দেখা যায়। 2x write-এর একই হিসাব 1 hour cache-এর জন্য প্রায় 53 percent threshold দেখায়। তাই 50 percent hit rate-এও খরচ $105.00, যা uncached line-এর চেয়ে বেশি। 90 percent hit rate-এ দুটি খরচ যথাক্রমে $21.50 এবং $29.00 হয়। 99 percent hit rate-এ short cache-এর খরচ $11.15-এ নেমে আসে, যা uncached price-এর এক-দশমাংশ floor-এর কাছাকাছি।
0.05x read-যুক্ত model-এ threshold 5 minute cache-এর জন্য প্রায় 21 percent এবং 1 hour cache-এর জন্য 51 percent-এ নেমে আসে। 0.025x read-এ এগুলো প্রায় 20 এবং 51 percent হয়। read price কমলে floor-ও কমে, অর্থাৎ uncached cost-এর এক-বিশমাংশ বা এক-চল্লিশমাংশে নামে।
Prefix size নির্দিষ্ট হওয়ার পরে hit rate-ই instrument করার প্রধান সংখ্যা, কারণ এটিই একমাত্র input যা আপনি নিয়ন্ত্রণ করতে পারেন।
কোন prefix-এ breakpoint রাখা মূল্যবান
একটি request-এ সর্বোচ্চ চারটি cache breakpoint থাকতে পারে। তাই প্রশ্ন হলো, কোন block-গুলোর জন্য breakpoint রাখা উচিত। প্রার্থী হবে এমন block, যেগুলো প্রতিটি call-এ byte-identical থাকে এবং যথেষ্ট বড় হওয়ায় খরচে প্রভাব ফেলে। নিচের chart-এ 5 minute cache-এ 90 percent hit rate ধরে 1,000টি request-এর জন্য চারটি প্রচলিত গঠন দেখানো হয়েছে।
এই চার্টের পেছনের ডেটা
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]শুধু 2,000 token-এর system prompt ব্যবহার করলে 1,000টি request-এ cache ছাড়া $10.00 খরচের তুলনায় $7.85 সাশ্রয় হয়। বেশি volume-এ এটি বাস্তব অর্থের পরিমাণ, কিন্তু caching আকর্ষণীয় হওয়ার মূল কারণ এটি নয়। Tool definition যোগ করলে আকার দাঁড়ায় 8,000 token এবং সাশ্রয় হয় $31.40। প্রতিটি request-এ প্রশ্ন করা হয় এমন 25,000 token-এর policy document সাশ্রয় করে $98.12। শেষের row-টি architecture পরিবর্তন করতে পারে: codebase বা transcript context-এর 120,000 token cache ছাড়া $600.00 এবং cache ব্যবহার করলে $129.00 খরচ হয়, অর্থাৎ সাশ্রয় $471.00।
সাশ্রয় prefix-এর আকার এবং hit rate-এর সঙ্গে বাড়ে; অন্য কোনো কিছুর সঙ্গে নয়। তাই prompt-এ আদৌ কী রাখা মূল্যবান, সেই সিদ্ধান্তও বদলে যায়: এক মিলিয়ন Claude token-এর প্রকৃত খরচ একবারের বেশি পাঠানো যেকোনো কিছুর ক্ষেত্রে sticker price-এর এক-দশমাংশে, অথবা যেসব model-এ read cost কম সেগুলোতে তারও কমে নেমে আসে।
মাসিক বিলের ক্ষেত্রে এটি কেমন দেখায়
নিচের চার্টে উপরের 8,000 token prefix, একটি system prompt এবং tool definition নেওয়া হয়েছে। 90 percent hit rate ধরে এটিকে মাসিক request volume অনুযায়ী হিসাব করা হয়েছে।
এই চার্টের পেছনের ডেটা
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]মাসে 10,000টি request হলে সাশ্রয় $314.00। এটি $400.00 এবং $86.00-এর পার্থক্য। 100,000টি request হলে সাশ্রয় $3,140.00। 1 million request হলে uncached input bill $40,000.00, এবং caching এর মধ্যে $31,400.00 সরিয়ে দেয়। এগুলো শুধু input token-এর হিসাব। Output-এর মূল্য আলাদাভাবে নির্ধারিত হয়, এবং caching-এর উপর এর কোনো প্রভাব নেই। তাই কাউকে 90 percent bill reduction দেওয়ার প্রতিশ্রুতি দেওয়ার আগে বিষয়টি মনে রাখুন। VPS-এ AI agent-এর বিল নিয়ন্ত্রণে রাখা-র বৃহত্তর পদ্ধতিগুলোর পাশাপাশি caching ব্যবহার করা হয়।
ক্যাশ কাজ করছে কীভাবে প্রমাণ করবেন
শুধু নকশার ওপর নির্ভর করবেন না। response-এর usage block পড়ুন। প্রতিটি Messages API (application programming interface) reply-তে API যে cached token লিখেছে, যে cached token পড়েছে এবং যে নতুন token process করতে হয়েছে—সবগুলোর হিসাব থাকে।
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)একই document এবং ভিন্ন question দিয়ে এটি দুবার চালান। প্রথম call-এ non-zero cache_creation_input_tokens এবং zero cache_read_input_tokens দেখাবে। দ্বিতীয় call-এ এর উল্টো হবে, কারণ prefix খুঁজে পাওয়া গেছে। input_tokens শুধু শেষ breakpoint-এর পরের token গোনে। তাই সুস্থ দ্বিতীয় call-এ এর মান ছোট থাকে, সাধারণত শুধু নতুন user message-এর সমান। উভয় call-এর জন্য billing হবে, কারণ Claude API-তে কোনো free tier নেই। তবে উপরে নির্ধারিত 20,000 token prefix-এর জন্য এই জোড়া call-এর মোট খরচ প্রায় fourteen cents।
আপনার request.json-এ সংরক্ষিত request body ব্যবহার করে shell থেকেও একই পরীক্ষা চালাতে পারেন:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'সুস্থ দ্বিতীয় call-এ এমন কিছু output দেখা যাবে:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}একটি line-ই প্রকৃত অবস্থা জানায়। যদি call-গুলোর মধ্যে cache_read_input_tokens 0-তেই থাকে, তাহলে প্রতিবার 1.25x write-এর জন্য billing হচ্ছে, কিন্তু তার বিনিময়ে কোনো cached token ফেরত পাওয়া যাচ্ছে না।
1 hour lifetime-এর জন্য breakpoint-এ time to live (TTL) নির্ধারণ করতে হয়:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Automatic caching-ও আছে। Request-এর top level-এ একটি cache_control field যোগ করলে API conversation বাড়ার সঙ্গে breakpoint নিজেই পরিচালনা করে। এটি আপনার চারটি breakpoint slot-এর একটি ব্যবহার করে। প্রথমে এটি ব্যবহার করুন। ঠিক কোন স্থানে boundary থাকবে তা নির্ধারণ করতে হলে explicit breakpoint ব্যবহার করুন।
হিট রেট নষ্ট করে এমন ক্রমবিন্যাসের নিয়ম
ক্যাশ অনুরোধের শুরু থেকে byte-for-byte একটি prefix মিলিয়ে দেখে। অনুরোধটি একটি নির্দিষ্ট ক্রমে তৈরি হয়: প্রথমে tools, তারপর system, এরপর messages। যেকোনো স্তরে পরিবর্তন হলে সেই স্তর এবং তার পরের সবকিছু invalid হয়ে যায়। একটি tool description সম্পাদনা করলে system prompt এবং সম্পূর্ণ message history-ও invalid হয়ে যায়, যদিও সেগুলোতে কোনো পরিবর্তন করা হয়নি।
এতে কোনো ব্যতিক্রম ছাড়াই একটি নিয়ম প্রযোজ্য হয়। কলগুলোর মধ্যে যা পরিবর্তিত হয়, তা অবশ্যই অপরিবর্তিত সবকিছুর পরে থাকতে হবে।
সাধারণত সমস্যা তৈরি করে timestamp। system prompt-এর শুরুতে Current time: 2026-08-03T14:07:11Z-যুক্ত একটি line থাকলে hit rate 0 percent হওয়া নিশ্চিত, কারণ প্রতিটি কলেই prefix hash বদলে যায় এবং আগের কোনো entry কখনো তার সঙ্গে মিলতে পারে না। এটিকে user message-এর শেষে সরিয়ে দিন। session identifier বা per-request nonce একইভাবে সমস্যা তৈরি করে এবং সমাধানও একই। প্রতিটি request-এ পরিবর্তিত retrieved document-ও cached block-এর পরে রাখতে হবে। নইলে পরিবর্তনশীল একটি boundary-এর পরে থাকা সব stable token ক্যাশের বাইরে চলে যায়।
দ্বিতীয় সমস্যা হলো পরিবর্তনশীল block-এ breakpoint বসানো। breakpoint-এ cache write হয়। তাই block-টি প্রতিবার আলাদা হলে কোনো stable content সংরক্ষিত হয় না, এবং lookback কেবল সেই entry-গুলোই খুঁজে পায় যেগুলো আগের request-গুলো তাদের নিজস্ব পরিবর্তনশীল breakpoint-এ লিখেছিল। cache_control এমন শেষ block-এ বসান, যার content সব request-এ একই থাকে।
তৃতীয় সমস্যা হলো এমন parameter পরিবর্তন, যেটিকে আপনি prompt content হিসেবে বিবেচনা করেননি। ভিন্ন model-এর জন্য ভিন্ন cache থাকে। tool_choice পরিবর্তন করলে message history invalid হয়ে যায়, যদিও tools এবং system prompt cached থাকে। কোনো tool যোগ বা অপসারণ করলে সবকিছু invalid হয়ে যায়।
ন্যূনতম prefix এবং নীরব no-op
model-এর ন্যূনতম সীমার চেয়ে ছোট prefix cache করা হয় না, এবং এ বিষয়ে আপনাকে কিছুই জানানো হয় না। কোনো error নেই, warning নেই। request সফল হয় এবং উভয় counter-এর মান 0 থাকে। October 2026 অনুযায়ী প্রকাশিত ন্যূনতম সীমাগুলো হলো:
- Claude Opus 5 এবং Claude Fable 5, পাশাপাশি নতুন Opus 5.5, Sonnet 5.5, Fable 5.1 এবং Haiku 5.5-এ 512 tokens
- Claude Sonnet 5 এবং Claude Opus 4.8-এ 1,024 tokens
- Claude Haiku 4.5-এ 4,096 tokens
কোনো request cached হবে বলে মনে হলেও উভয় counter-এর মান 0 হলে অন্য কিছু পরীক্ষা করার আগে prefix-এর দৈর্ঘ্য যাচাই করুন। এই কারণেই caching workload-এর জন্য সবচেয়ে সস্তা model-ই স্বয়ংক্রিয়ভাবে সবচেয়ে সাশ্রয়ী হয় না। Caching কার্যকর হওয়ার জন্য Haiku 4.5-এর prefix, Opus 5-এর তুলনায় আট গুণ দীর্ঘ হতে হয়। তাই 2,000 token-এর system prompt একটি model-এ cache হয়, কিন্তু অন্যটিতে নীরবে উপেক্ষিত হয়।
Claude Code আপনার জন্য কোথায় cache করে এবং কোথায় তা করতে পারে না
Claude Code তার নিজস্ব prefix cache করে। System prompt এবং tool definition প্রতিটি request-এর শুরুতে থাকে এবং পরিবর্তিত হয় না। তাই সেগুলো একবার লেখা হয় এবং session-এর বাকি সময়ে cache থেকে পড়া হয়। এই কারণে দীর্ঘ session-এ প্রতি turn-এর খরচ context size দেখে যতটা মনে হয়, তার চেয়ে অনেক কম হয়। এটি Claude Code কীভাবে token usage জানায়-এ বর্ণিত counter-গুলোতেও দেখা যায়।
Context-এর শুরুর কাছাকাছি কোনো পরিবর্তন হলে cache আপনাকে সাহায্য করতে পারে না। Conversation history শুধু শেষে নতুন content যোগ করে। তাই সাধারণ নতুন turn ইতিমধ্যে cached থাকা prefix-কে আরও বাড়ায়। Session-এর শুরুতে পড়া কোনো file সম্পাদনা করলেও cache নষ্ট হয় না। কারণ Claude Code আগের read পুনরায় লিখে না; file পরিবর্তিত হয়েছে জানিয়ে একটি note যোগ করে। তবে model পরিবর্তন করলে cache নষ্ট হয়, কারণ প্রতিটি model-এর নিজস্ব cache থাকে। এমন কোনো MCP server সংযুক্ত করলেও cache নষ্ট হয় যার tools prefix-এ load হয়। Conversation compact করলেও একই ঘটনা ঘটে। এসব ক্ষেত্রে পরবর্তী turn-এ prefix আবার লিখতে হয়। দীর্ঘ সময় কোনো কার্যকলাপ না থাকলেও একই ফল হয়। কারণ cache entry-এর মেয়াদ শেষ হয়ে যায় এবং পরবর্তী turn-এ সম্পূর্ণ prefix আবার লিখতে হয়। এগুলোর কোনোটিই bug নয়। Prefix rule অনুযায়ী সিস্টেম ঠিক এভাবেই কাজ করে।
এর বদলে আপনি যদি নিজের client লিখছেন, পরে পরিবর্তন না করে প্রথম request থেকেই layout প্রয়োগ করুন। একটি VPS-এ প্রথম Claude API app-এর মতো call তৈরি করুন। Stable block-গুলো আগে এবং পরিবর্তনশীল block-গুলো শেষে রাখুন।
ব্যর্থতার ধরন এবং আপনি যা দেখতে পাবেন
প্রতিটি call-ই write। প্রতিটি request-এ cache_creation_input_tokens শূন্যের চেয়ে বড়, আর cache_read_input_tokens 0 থাকে। breakpoint-এর আগে বা সেখানে কোনো কিছু প্রতিটি call-এর মধ্যে পরিবর্তিত হচ্ছে। পরপর দুটি request-এ তৈরি করা prefix-এর প্রথম 200টি character print করুন এবং চোখে দেখে তুলনা করুন।
উভয় counter-ই 0। prefix-টি model-এর minimum-এর নিচে, অথবা cache_control field কখনো API-তে পৌঁছায়নি। প্রথমে prefix token গণনা করুন। এরপর আপনি বাস্তবে যে request body পাঠিয়েছেন, সেটি log করুন।
Read কাজ করে, তারপর বন্ধ হয়ে যায়। প্রথমে ধারাবাহিকভাবে hit হয়, তারপর একটি write হয়, এরপর আবার hit হয়। দুটি request-এর মধ্যবর্তী সময় lifetime-এর চেয়ে বেশি ছিল। write গ্রহণ করুন। অথবা hit rate 53 percent ছাড়ছে কি না যাচাই করার পর 1 hour TTL ব্যবহার করুন। 0.05x বা 0.025x read-যুক্ত model-এ এই সীমা প্রায় 51 percent।
Deploy-এর পরে hit rate কমে যায়। কোনো tool description সম্পাদনা করা হয়েছে, অথবা model পরিবর্তন করা হয়েছে। উভয় ঘটনাই পুরো prefix invalidate করে। prompt-এ প্রভাব ফেলে এমন প্রতিটি deploy-এর পরে একবার ব্যয়বহুল write পর্যায়ের প্রত্যাশা করুন।
Caching চালু করার পরে bill বেড়ে গেছে। আপনার hit rate break-even সীমার নিচে। 5 minute cache-এ প্রায় 22 percent-এর নিচে হলে prefix uncached অবস্থায় পাঠানো সস্তা। 1 hour cache-এ প্রায় 53 percent-এর নিচে হলেও একই কথা প্রযোজ্য। কম খরচের read-যুক্ত model-এ এই সীমাগুলো প্রায় 20 থেকে 21 percent এবং 51 percent।
FAQ
একটি prompt কতবার পুনরায় ব্যবহার করলে caching-এর খরচ উঠে আসে?
5 minute cache-এ একবারই। অধিকাংশ model-এ write-এর খরচ base input-এর 1.25x এবং read-এর খরচ 0.1x। তাই cache ছাড়া Nটি request-এর খরচ N, আর cache ব্যবহার করলে খরচ হয় 1.25 plus 0.1 times N minus 1। দুটি খরচ N = 1.28-এ সমান হয়। তাই দ্বিতীয় request থেকেই সাশ্রয় শুরু হয়। 0.05x বা 0.025x read-যুক্ত model-এ সমতা N = 1.26-এ আসে। ফল একই। 1 hour cache-এ write-এর খরচ 2x এবং সমতা N = 2.11-এ আসে, অথবা কম খরচের read-এ প্রায় 2.05-এ। তাই এতে দুটি read প্রয়োজন।
cache_read_input_tokens সবসময় zero কেন?
প্রথমে prefix-এর দৈর্ঘ্য পরীক্ষা করুন। model-এর minimum-এর চেয়ে কম হলে, অর্থাৎ October 2026 অনুযায়ী Claude Opus 5-এ 512 tokens এবং Claude Haiku 4.5-এ 4,096 tokens-এর কম হলে, caching নীরবে এড়িয়ে যাওয়া হয় এবং উভয় counter-এর মান 0 থাকে। Prefix যথেষ্ট দীর্ঘ হলে এমন content খুঁজুন, যা call-এর মধ্যে পরিবর্তিত হয় এবং breakpoint-এ বা তার আগে অবস্থান করে। উদাহরণ হিসেবে system prompt-এর timestamp বা session identifier দেখুন। Counter আগে কাজ করে পরে বন্ধ হয়ে গেলে, request দুটির মধ্যবর্তী সময় cache lifetime-এর চেয়ে বেশি ছিল।
prompt caching কি Claude-এর উত্তর পরিবর্তন করে?
না। Cache ইতিমধ্যে পাঠানো tokens-এর processed form সংরক্ষণ করে। উভয় ক্ষেত্রেই model একই prompt দেখে। এটি billing ও latency feature, behaviour পরিবর্তনের feature নয়। তাই কার্যকর prompt-এ এটি enable করলে evaluations আবার চালানোর প্রয়োজন নেই।
1 hour cache-এর জন্য কি অর্থ খরচ করা উচিত?
শুধু তখনই, যখন আপনার traffic-এর বিরতি 5 minutes-এর চেয়ে বেশি এবং hit rate প্রায় 53 percent-এর ওপরে থাকবে। কম খরচের read-যুক্ত model-এ এই সীমা প্রায় 51 percent। Cache miss হলে 2x write-এর খরচ 1.25x write-এর চার গুণ। 1 hour write miss হলে prefix-এর সম্পূর্ণ base input price নষ্ট হয়, যেখানে 5 minute write miss হলে এর মাত্র এক-চতুর্থাংশ নষ্ট হয়। প্রতিটি hit-এ 5 minute entry refresh হয়। তাই নিয়মিত traffic read price-এ entry চালু রাখে এবং দীর্ঘ lifetime-এর জন্য অতিরিক্ত খরচ হয় না।