দ্বারা Claude prompt caching: break-even কত ব্যবহারে?
Cache write-এর খরচ 1.25x, read 0.1x, তাই 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 জুড়ে একই থাকে। তাই প্রতি-token price পরিবর্তিত হলেও নিচের break-even পরিবর্তিত হয় না।
এখানে এখন অতিরিক্ত খরচের বিনিময়ে পরে ছাড় পাওয়া যায়। একটি prefix সংরক্ষণ করতে একবার অতিরিক্ত মূল্য দিতে হয়। এরপর তার lifetime-এর মধ্যে যে request ঠিক একই bytes দিয়ে শুরু হয়, সেই অংশের জন্য normal 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 দামে write করে, আর বাকি N minus 1টি request 0.1B দামে এটি read করে। দুই খরচ সমান করলে 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 নয়।
নিচের 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 হলে ব্যবধানটি $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-এর খরচ
বাস্তব network traffic-এ cache miss হয়। কোনো request cache miss করলেও যদি breakpoint বহন করে, সেটিকে write হিসেবে বিল করা হয়। তাই 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 নির্দিষ্ট হওয়ার পরে আপনি যে একমাত্র input নিয়ন্ত্রণ করতে পারেন, তা হলো hit rate। তাই এটিই instrument করা উচিত।
কোন prefix-এ breakpoint রাখা যুক্তিযুক্ত
একটি request-এ সর্বোচ্চ চারটি cache breakpoint থাকতে পারে। তাই প্রশ্ন হলো, কোন block-এ breakpoint রাখা উচিত। প্রার্থী হবে এমন block, যা প্রতিটি call-এ byte-identical থাকে এবং যথেষ্ট বড় হওয়ায় খরচে প্রভাব ফেলে। নিচের chart-এ 5 minute cache-এ 90 percent hit rate ধরে 1,000টি request-এর জন্য চারটি সাধারণ shape-এর খরচ দেখানো হয়েছে।
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 ব্যবহার করলে 1,000টি request-এ uncached $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 uncached অবস্থায় $600.00 এবং cached অবস্থায় $129.00 খরচ করে; অর্থাৎ সাশ্রয় হয় $471.00।
সাশ্রয় prefix-এর আকার এবং hit rate-এর সঙ্গে বাড়ে; অন্য কোনো কিছুর সঙ্গে নয়। ফলে prompt-এ আদৌ কী রাখা মূল্যবান, সেই সিদ্ধান্তও বদলে যায়: এক মিলিয়ন Claude token-এর প্রকৃত খরচ একবারের বেশি পাঠানো যেকোনো কিছুর ক্ষেত্রে তালিকাভুক্ত মূল্যের এক-দশমাংশে নেমে আসে।
মাসিক বিলের ক্ষেত্রে এটি কেমন দেখায়
নিচের চার্টে উপরের 8,000 token prefix, একটি system prompt এবং tool definition নেওয়া হয়েছে। 90 percent hit rate ধরে এটিকে মাসিক 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 হলে 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 ধরে 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 বা per-request nonce একইভাবে সমস্যা তৈরি করে এবং একই সমাধান প্রযোজ্য। প্রতি request-এ পরিবর্তিত retrieved document-ও cached block-এর পরে রাখতে হবে। তা না হলে প্রতিটি স্থিতিশীল token এমন একটি boundary-এর পরে চলে যায়, যা পরিবর্তিত হয়।
দ্বিতীয় সমস্যা হলো যে block পরিবর্তিত হয়, তার ওপর breakpoint বসানো। breakpoint-এ cache write হয়। তাই block-টি প্রতিবার আলাদা হলে কোনো স্থিতিশীল বিষয় সংরক্ষিত হয় না। lookback তখন কেবল আগের request-গুলো নিজেদের পরিবর্তনশীল breakpoint-এ লিখে যাওয়া entry খুঁজে পায়। cache_control এমন সর্বশেষ block-এর ওপর বসান, যার content সব request-এ অভিন্ন।
তৃতীয় সমস্যা হলো এমন parameter পরিবর্তন, যাকে আপনি prompt content হিসেবে বিবেচনা করেননি। ভিন্ন model-এর জন্য ভিন্ন cache থাকে। tool choice পরিবর্তন করলে system level থেকে পরের সবকিছু invalid হয়ে যায়। কোনো tool যোগ বা অপসারণ করলে সবকিছু invalid হয়ে যায়।
ন্যূনতম prefix এবং নীরব no-op
model-এর ন্যূনতম সীমার চেয়ে ছোট 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-টি স্বয়ংক্রিয়ভাবে সবচেয়ে সাশ্রয়ী হয় না। 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-এর বাকি সময় read back করা হয়। এ কারণেই দীর্ঘ session-এ প্রতি turn-এর খরচ context size দেখে যতটা মনে হয়, তার চেয়ে অনেক কম হয়। Claude Code কীভাবে token usage জানায়-এ বর্ণিত counter-গুলোতেও এর প্রতিফলন দেখা যায়।
যেখানে এটি সহায়তা করতে পারে না, তা হলো context-এর শুরুর কাছাকাছি কোনো edit হলে। Conversation history append-only, তাই সাধারণ নতুন turn ইতিমধ্যে cache করা prefix-এ আরও content যোগ করে। Session-এর শুরুর দিকে read করা কোনো file edit করলে সেই prefix-এর মাঝের content বদলে যায়। ফলে পরিবর্তিত অংশের পরের প্রতিটি token আবার লিখতে হয়। দীর্ঘ সময় কোনো কার্যক্রম না থাকলেও একই ঘটনা ঘটে, কারণ entry-এর মেয়াদ শেষ হয় এবং পরের turn-এ সম্পূর্ণ write-এর খরচ দিতে হয়। এগুলোর কোনোটিই bug নয়। উভয় ক্ষেত্রেই prefix rule নির্ধারিত নিয়ম অনুযায়ী কাজ করে।
আপনি যদি নিজস্ব client লিখছেন, তাহলে পরে layout পরিবর্তন না করে প্রথম request থেকেই এটি প্রয়োগ করুন। VPS-এ প্রথম Claude API app-এর মতো call তৈরি করুন। Stable block-গুলো শুরুতে এবং volatile block-গুলো শেষে রাখুন।
ব্যর্থতার ধরন এবং আপনি যা দেখবেন
প্রতিটি কল write। প্রতিটি request-এ cache_creation_input_tokens non-zero থাকে, আর cache_read_input_tokens 0 থাকে। Breakpoint-এ বা তার আগের কোনো কিছু call-গুলোর মধ্যে পরিবর্তিত হচ্ছে। পরপর দুটি request-এ assembled 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 ব্যবহার করুন।
Deploy-এর পরে hit rate কমে যায়। কোনো tool description সম্পাদনা করা হয়েছে, অথবা model পরিবর্তন করা হয়েছে। উভয় ক্ষেত্রেই পুরো prefix invalid হয়ে যায়। Prompt-এ প্রভাব ফেলে এমন প্রতিটি deploy-এর পরে একটি ব্যয়বহুল write-এর ধাপ হবে বলে ধরে নিন।
Caching enable করার পরে bill বেড়েছে। আপনার hit rate break-even-এর নিচে। 5 minute cache-এ প্রায় 22 percent-এর নিচে hit rate হলে prefix uncached পাঠানো সস্তা। 1 hour cache-এর ক্ষেত্রে প্রায় 53 percent-এর নিচে একই বিষয় প্রযোজ্য।
FAQ
একটি prompt কতবার পুনরায় ব্যবহার করলে caching-এর খরচ উঠে আসে?
5 minute cache-এ একবারই। একটি write-এর খরচ base input-এর 1.25x এবং একটি read-এর খরচ 0.1x। তাই Nটি uncached request-এর খরচ N, আর Nটি cached 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 সবসময় শূন্য কেন?
প্রথমে prefix-এর দৈর্ঘ্য পরীক্ষা করুন। Model minimum-এর নিচে হলে caching নীরবে এড়িয়ে যায় এবং উভয় counter-এর মান 0 থাকে। August 2026 অনুযায়ী Claude Opus 5-এর জন্য minimum 512 tokens এবং Claude Haiku 4.5-এর জন্য 4,096 tokens।
Prefix যথেষ্ট দীর্ঘ হলে breakpoint-এ বা তার আগে এমন content আছে কি না দেখুন, যা প্রতিটি call-এর মধ্যে পরিবর্তিত হয়। উদাহরণ হিসেবে system prompt-এ থাকা timestamp বা session identifier পরীক্ষা করুন। Counter আগে কাজ করে থাকলে এবং পরে বন্ধ হয়ে গেলে, request দুটির ব্যবধান cache lifetime-এর চেয়ে বেশি ছিল।
Prompt caching কি Claude-এর উত্তর পরিবর্তন করে?
না। Cache আপনার পাঠানো token-এর processed form সংরক্ষণ করে। উভয় ক্ষেত্রেই model একই prompt দেখে। এটি billing এবং latency-এর feature, behaviour পরিবর্তনের feature নয়। তাই কাজ করা prompt-এ এটি enable করলেও evaluation আবার চালানোর প্রয়োজন নেই।
আমার কি 1 hour cache-এর জন্য অর্থ দেওয়া উচিত?
শুধু তখনই, যখন আপনার traffic-এর ব্যবধান 5 minutes-এর বেশি এবং hit rate মোটামুটি 53 percent-এর বেশি থাকবে। Cache miss হলে 2x write-এর ক্ষতি 1.25x write-এর দ্বিগুণ। 5 minute entry প্রতিটি hit-এ refresh হয়। তাই নিয়মিত traffic read price-এ entry সক্রিয় রাখে এবং দীর্ঘ lifetime-এর জন্য অতিরিক্ত অর্থ দিতে হয় না।