দ্বারা Claude prompt caching: break-even কত ব্যবহারে?
Cache write-এর খরচ 1.25x এবং read-এর 0.1x। তাই Claude prefix দ্বিতীয় ব্যবহারে সাশ্রয় শুরু করে। নিজের break-even হিসাব API দিয়ে যাচাই করুন।
Prompt caching সাশ্রয় করার আগে কত খরচ হয়
Prompt caching আপনার prompt-এর শুরু অংশটি প্রতিটি call-এ আবার পড়ার বদলে Claude-কে সেটি পুনরায় ব্যবহার করতে দেয়। পুরো সিদ্ধান্তটি আপনার model-এর base input price-এর ওপর প্রযোজ্য দুটি multiplier-এর ওপর নির্ভর করে। August 2026 অনুযায়ী, 5 minute lifetime-এর জন্য cache write-এর খরচ base input-এর 1.25x, আর 1 hour lifetime-এর জন্য 2x। cache read-এর খরচ 0.1x। এই multiplier-গুলো model list জুড়েই একই থাকে। তাই per-token price পরিবর্তিত হলেও নিচের break-even পরিবর্তিত হয় না।
এখানে বর্তমানের অতিরিক্ত খরচের বিনিময়ে পরে discount পাওয়া যায়। একটি prefix সংরক্ষণ করতে একবার অতিরিক্ত অর্থ দিতে হয়। এরপর যে প্রতিটি request ঠিক একই bytes দিয়ে শুরু হয়, সেই request-এ ওই অংশের জন্য স্বাভাবিক input price-এর এক-দশমাংশ দিতে হয়। কোনো prefix তার lifetime-এর মধ্যে একবারও পুনরায় ব্যবহার না হলে, কোনো সুবিধা ছাড়াই তার জন্য 25 percent অতিরিক্ত খরচ হয়।
এক লাইনের বীজগণিতে break-even
আপনি prefix-টি cache না করে পাঠালে তার base input cost-কে B ধরুন। Caching ছাড়া Nটি request-এর খরচ N গুণ B। 5 minute cache ব্যবহার করলে প্রথম request-এ prefix লেখার খরচ 1.25B এবং বাকি N minus 1টি request-এ পড়ার খরচ প্রতি request-এ 0.1B। দুটি খরচ সমান ধরলে পাওয়া যায় 0.9N = 1.15, তাই N = 1.28। অর্থাৎ দ্বিতীয় request-ই caching না করার তুলনায় সস্তা।
1 hour cache-এর 2x write দিয়ে একই হিসাব করলে পাওয়া যায় 0.9N = 1.9, তাই N = 2.11। দীর্ঘ cache কার্যকর হতে দুটি read প্রয়োজন। এই কারণেই এটি default choice নয়।
নিচের chart-এ Claude Opus 5-এর 20,000 token prefix-এর খরচ দেখানো হয়েছে। August 2026 অনুযায়ী এর base input rate প্রতি million token-এ $5। প্রতি million token-এ $3 দামের model-এর জন্য প্রতিটি সংখ্যা 0.6 দিয়ে গুণ করুন। Curve-এর আকৃতি পরিবর্তন হবে না।
The data behind this chart
[
{
"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 হলে ব্যবধানটি হলো uncached-এ $2.00 এবং 5 minute cache-এ $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 cost তখনই সাশ্রয়ী হয়, যখন আপনার traffic-এর মধ্যে বাস্তব বিরতি থাকে।
কম hit rate-এর খরচ
বাস্তব network traffic-এ cache miss হয়। কোনো request cache miss করলেও যদি breakpoint বহন করে, সেটিকে write হিসেবে charge করা হয়। তাই hit rate-এর ফাংশন হিসেবে cost নির্ণয় করাই সঠিক পদ্ধতি। নিচের chart-এ 1,000টি request-এর জন্য এই হিসাব দেখানো হয়েছে। প্রতিটি request-এ একই 20,000 token prefix রয়েছে।
The data behind this chart
[
{
"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 সমাধান করলে দেখা যায়, প্রায় 22 percent hit rate-এ 5 minute cache থেকে সাশ্রয় শুরু হয়। তাই 25 percent hit rate-এও খরচ $96.25 দেখা যায়। 2x write-এর ক্ষেত্রেও একই হিসাব করলে 1 hour cache-এর জন্য প্রায় 53 percent পাওয়া যায়। তাই 50 percent hit rate-এ খরচ এখনও $105.00, যা cache না ব্যবহার করার খরচের চেয়ে বেশি। 90 percent hit rate-এ দুটি যথাক্রমে $21.50 এবং $29.00-এ পৌঁছায়। 99 percent hit rate-এ short cache-এর খরচ $11.15 হয়, যা cache না ব্যবহার করার মূল্যের এক-দশমাংশের floor-এর কাছাকাছি।
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-এ চারটি প্রচলিত গঠনের খরচ দেখানো হয়েছে।
The data behind this chart
[
{
"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 ব্যবহার করলে cache ছাড়া $10.00-এর তুলনায় প্রতি 1,000 request-এ $7.85 সাশ্রয় হয়। বেশি volume-এ এটি বাস্তব অর্থ সাশ্রয় করে, কিন্তু caching আকর্ষণীয় হওয়ার মূল কারণ এটি নয়। Tool definition যোগ করলে মোট আকার হয় 8,000 token, এবং সাশ্রয় হয় $31.40। প্রতিটি request-এ যে 25,000 token-এর policy document নিয়ে প্রশ্ন করা হয়, সেটি cache ব্যবহার করে $98.12 সাশ্রয় করে। শেষের row-টি architecture পরিবর্তন করতে পারে: 120,000 token-এর codebase বা transcript context cache ছাড়া $600.00, আর cache ব্যবহার করলে $129.00 খরচ হয়; অর্থাৎ সাশ্রয় $471.00।
সাশ্রয় prefix-এর আকার এবং hit rate-এর সঙ্গে বাড়ে; অন্য কোনো বিষয় এতে প্রভাব ফেলে না। ফলে prompt-এ আদৌ কী রাখা সার্থক, সেই সিদ্ধান্তও বদলে যায়: এক মিলিয়ন Claude token-এর প্রকৃত খরচ একবারের বেশি পাঠানো যেকোনো কিছুর ক্ষেত্রে তালিকাভুক্ত দামের এক-দশমাংশে নেমে আসে।
মাসিক বিলের ক্ষেত্রে এটি কেমন দেখায়
নিচের চার্টে উপরের 8,000 token-এর prefix, একটি system prompt এবং tool definition নেওয়া হয়েছে। এতে hit rate 90 percent ধরা হয়েছে এবং হিসাবটি মাসিক request volume অনুযায়ী প্রসারিত করা হয়েছে।
The data behind this chart
[
{
"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-এ caching ছাড়া input bill হয় $40,000.00, এবং caching এর মধ্যে $31,400.00 সাশ্রয় করে। এগুলো শুধু input token-এর হিসাব। Output-এর মূল্য আলাদাভাবে নির্ধারিত হয়, এবং caching output-এর খরচে কোনো প্রভাব ফেলে না। তাই কাউকে bill 90 percent কমানোর প্রতিশ্রুতি দেওয়ার আগে বিষয়টি মনে রাখুন। Caching, VPS-এ AI agent-এর bill নিয়ন্ত্রণে রাখার বিস্তৃত পদ্ধতিগুলোর পাশাপাশি কাজ করে।
ক্যাশ কাজ করছে কীভাবে প্রমাণ করবেন
শুধু নকশার ওপর নির্ভর করবেন না। response-এর usage block পড়ুন। প্রতিটি Messages API (application programming interface) response-এ লেখা cached token, পড়া cached token এবং প্রক্রিয়া করার জন্য নতুন করে নেওয়া token-এর সংখ্যা জানানো হয়।
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টি cache-এ পাওয়া গেছে। input_tokens শুধু শেষ breakpoint-এর পরের token গুনে। তাই দ্বিতীয় call সফল হলে এর মান ছোট থাকে; সাধারণত এতে শুধু নতুন user message থাকে।
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 cost দিচ্ছেন, কিন্তু এর বিনিময়ে কোনো 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 ব্যবহার করুন।
হিট রেট নষ্ট করে এমন বিন্যাসের নিয়ম
Cache অনুরোধের শুরু থেকে byte ধরে prefix মিলিয়ে দেখে। অনুরোধটি নির্দিষ্ট ক্রমে তৈরি হয়: tools, তারপর system, তারপর messages। যেকোনো স্তরে পরিবর্তন হলে সেই স্তর এবং তার পরের সবকিছু invalid হয়ে যায়। একটি tool description সম্পাদনা করলে system prompt এবং সম্পূর্ণ message history-ও invalid হয়, যদিও সেগুলো পরিবর্তন করা হয়নি।
এতে কোনো ব্যতিক্রম ছাড়া একটি নিয়ম প্রযোজ্য হয়। কলগুলোর মধ্যে যা পরিবর্তিত হয়, তা অবশ্যই অপরিবর্তিত সবকিছুর পরে থাকতে হবে।
সাধারণ সমস্যাটি হলো timestamp। system prompt-এর শুরুতে Current time: 2026-08-03T14:07:11Z-এর মতো একটি লাইন থাকলে hit rate 0 percent হওয়া নিশ্চিত, কারণ প্রতিটি কলেই prefix hash আলাদা হয় এবং আগের কোনো entry কখনো সেটির সঙ্গে মিলতে পারে না। এটিকে user message-এর শেষে সরিয়ে দিন। session identifier বা প্রতি-অনুরোধের nonce একইভাবে সমস্যা তৈরি করে এবং সমাধানও একই। প্রতি অনুরোধে পরিবর্তিত retrieved documents-ও cached block-এর পরে রাখতে হবে। নইলে সেগুলো একটি পরিবর্তনশীল boundary-এর পেছনে থাকা সব স্থিতিশীল token-কে ঠেলে দেয়।
দ্বিতীয় সমস্যা হলো পরিবর্তিত block-এ breakpoint বসানো। breakpoint-এ cache write হয়। তাই block-টি যদি প্রতিবার আলাদা হয়, কোনো স্থিতিশীল বিষয়ই সংরক্ষিত হয় না। lookback তখন শুধু সেই entry-গুলো খুঁজে পায়, যেগুলো আগের অনুরোধগুলো তাদের নিজ নিজ পরিবর্তনশীল breakpoint-এ লিখেছিল। অনুরোধগুলোর মধ্যে যার content অভিন্ন থাকে, সেই শেষ block-এ cache_control বসান।
তৃতীয় সমস্যা হলো এমন parameter পরিবর্তন, যেটিকে আপনি prompt content হিসেবে বিবেচনা করেননি। ভিন্ন model-এর জন্য ভিন্ন cache ব্যবহৃত হয়। tool choice পরিবর্তন করলে system level থেকে পরের সবকিছু invalid হয়। কোনো tool যোগ বা সরিয়ে ফেললে সবকিছু invalid হয়।
সর্বনিম্ন prefix এবং নীরব কোনো পরিবর্তন না হওয়া
মডেলের সর্বনিম্ন সীমার চেয়ে ছোট prefix cache করা হয় না, এবং এ বিষয়ে আপনাকে কিছু জানানো হয় না। কোনো error বা warning দেখানো হয় না। Request সফল হয়, কিন্তু উভয় counter-এর মান 0 থাকে। August 2026 অনুযায়ী প্রকাশিত সর্বনিম্ন সীমাগুলো হলো:
- Claude Opus 5 এবং Claude Fable 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-টি স্বয়ংক্রিয়ভাবে সবচেয়ে কম খরচের হয় না। Haiku 4.5-এ caching কার্যকর হওয়ার জন্য Opus 5-এর তুলনায় আট গুণ দীর্ঘ prefix প্রয়োজন। তাই 2,000 token-এর system prompt একটি model-এ cache হয়, কিন্তু অন্য model-এ নীরবে উপেক্ষিত হয়।
Claude Code আপনার জন্য কোথায় cache করে এবং কোথায় তা কাজে আসে না
Claude Code তার নিজস্ব prefix cache করে। system prompt এবং tool definition প্রতিটি request-এর শুরুতে থাকে এবং পরিবর্তিত হয় না। তাই সেগুলো একবার লেখা হয় এবং session-এর বাকি সময়ে আবার পড়া হয়। এ কারণেই context size যতটা খরচের ইঙ্গিত দেয়, দীর্ঘ session-এ প্রতি turn-এর খরচ তার তুলনায় অনেক কম হয়। এই বিষয়টি Claude Code কীভাবে token usage দেখায়-এ বর্ণিত counter-এও দেখা যায়।
যেখানে এটি কাজে আসে না, তা হলো context-এর শুরুর কাছাকাছি কোনো edit হলে। Conversation history শুধু শেষে যুক্ত হয়। তাই সাধারণ নতুন turn ইতিমধ্যে cache করা prefix-কে আরও দীর্ঘ করে। Session-এর শুরুতে পড়া কোনো file edit করলে সেই prefix-এর মাঝের content বদলে যায়। ফলে পরিবর্তিত অংশের পরের প্রতিটি token আবার লিখতে হয়। দীর্ঘ সময় কোনো কাজ না করলেও একই ঘটনা ঘটে। Entry expire হয়ে যায় এবং পরের turn-এ সম্পূর্ণ write-এর খরচ দিতে হয়। এগুলোর কোনোটিই bug নয়। Prefix rule অনুযায়ী উভয় ক্ষেত্রেই ঠিক এটাই হওয়ার কথা।
আপনি যদি নিজের client লিখে থাকেন, তাহলে পরে layout পরিবর্তন না করে প্রথম request থেকেই এটি সঠিকভাবে প্রয়োগ করুন। VPS-এ প্রথম Claude API app-এর মতো call তৈরি করুন। Stable block-গুলো আগে এবং পরিবর্তনশীল block-গুলো শেষে রাখুন।
ব্যর্থতার ধরন এবং আপনি যা দেখবেন
প্রতিটি কল একটি write। প্রতিটি request-এ cache_creation_input_tokens শূন্য নয়, কিন্তু cache_read_input_tokens 0 থাকে। Breakpoint-এর আগে বা সেখানে থাকা কোনো বিষয় request-গুলোর মধ্যে পরিবর্তিত হচ্ছে। পরপর দুটি request-এ তৈরি করা prefix-এর প্রথম 200 characters print করুন এবং চোখে দেখে তুলনা করুন।
উভয় counter-ই 0। Prefix model-এর ন্যূনতম দৈর্ঘ্যের চেয়ে ছোট, অথবা cache_control field কখনো API-তে পৌঁছায়নি। প্রথমে prefix token গুনুন। এরপর আপনি বাস্তবে যে request body পাঠিয়েছেন, সেটি log করুন।
প্রথমে read কাজ করে, পরে বন্ধ হয়ে যায়। একটানা কয়েকটি hit-এর পর একটি write, তারপর আবার hit দেখা যায়। Request-গুলোর মধ্যবর্তী বিরতি lifetime-এর চেয়ে দীর্ঘ ছিল। Write গ্রহণ করুন, অথবা hit rate 53 percent অতিক্রম করছে কি না যাচাই করার পর 1 hour TTL ব্যবহার করুন।
Deploy-এর পরে hit rate কমে যায়। কোনো tool description সম্পাদনা করা হয়েছে অথবা model পরিবর্তন করা হয়েছে। উভয় ক্ষেত্রেই সম্পূর্ণ prefix invalid হয়ে যায়। Prompt-এ প্রভাব ফেলে এমন প্রতিটি deploy-এর পরে write-এর একটি ব্যয়বহুল পর্যায় হবে বলে ধরে নিন।
Caching চালু করার পরে bill বেড়ে গেছে। আপনার hit rate break-even-এর নিচে। 5 minute cache-এ প্রায় 22 percent-এর নিচে হলে prefix uncached পাঠানো সস্তা। 1 hour cache-এ প্রায় 53 percent-এর নিচে হলেও একই কথা প্রযোজ্য।
FAQ
একটি prompt কতবার পুনর্ব্যবহার করলে caching-এর খরচ উঠে আসে?
5 minute cache-এ একবারই। write-এর খরচ base input-এর 1.25x এবং read-এর খরচ 0.1x। তাই caching ছাড়া Nটি request-এর খরচ N, আর caching সহ Nটি request-এর খরচ 1.25 plus 0.1 times N minus 1। দুটি খরচ N = 1.28-এ সমান হয়। তাই দ্বিতীয় request থেকেই caching লাভজনক।
1 hour cache-এ write-এর খরচ 2x। এটি N = 2.11-এ সমান হয়। তাই এতে দুইটি read প্রয়োজন।
cache_read_input_tokens সবসময় 0 কেন?
প্রথমে prefix-এর দৈর্ঘ্য পরীক্ষা করুন। model minimum-এর চেয়ে ছোট হলে caching নীরবে বাদ দেওয়া হয় এবং উভয় counter-এর মান 0 থাকে। August 2026 অনুযায়ী Claude Opus 5-এর minimum 512 tokens এবং Claude Haiku 4.5-এর minimum 4,096 tokens।
prefix যথেষ্ট দীর্ঘ হলে breakpoint-এ বা তার আগে এমন content আছে কি না দেখুন যা request-এর মধ্যে পরিবর্তিত হয়। 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 করলে evaluation আবার চালানোর প্রয়োজন হয় না।
আমার কি 1 hour cache-এর জন্য অর্থ দেওয়া উচিত?
শুধু তখনই, যখন আপনার traffic-এর gap 5 minutes-এর বেশি এবং hit rate আনুমানিক 53 percent-এর বেশি থাকবে। miss হলে 2x write-এর অতিরিক্ত খরচ 1.25x write-এর তুলনায় দ্বিগুণ। 5 minute entry প্রতিটি hit-এ refresh হয়। তাই নিয়মিত traffic read price-এ entry সক্রিয় রাখে এবং দীর্ঘ lifetime-এর জন্য অতিরিক্ত অর্থ দিতে হয় না।