توسط محاسبه نقطه سربهسر کش کردن پرامپت در Claude
هزینه نوشتن در کش Claude برابر 1.25 برابر و خواندن 0.1 برابر قیمت پایه است. با این فرمول ریاضی متوجه میشوید که استفاده مجدد از پیشوند در دومین درخواست، هزینه را کاهش میدهد.
هزینههای کش کردن پرامپت پیش از صرفهجویی
کش کردن پرامپت (Prompt caching) به Claude اجازه میدهد بهجای خواندن مجدد بخش ابتدایی پرامپت در هر فراخوانی، آن را بازاستفاده کند. کل این تصمیم به دو ضریب در قیمت پایه ورودی مدل شما بستگی دارد. تا اوت 2026، هزینه نوشتن در کش برای طول عمر 5 دقیقه برابر با 1.25 برابر قیمت پایه ورودی، و برای طول عمر 1 ساعت برابر با 2 برابر آن است. هزینه خواندن از کش نیز 0.1 برابر قیمت پایه است. این ضرایب در تمامی مدلها ثابت هستند، بنابراین نقطه سربهسر (break-even) با تغییر قیمت هر توکن تغییر نمیکند.
این معامله در واقع پرداخت هزینه اضافی در لحظه، در برابر دریافت تخفیف در آینده است. شما یک بار مبلغ بیشتری برای ذخیره یک پیشوند (prefix) میپردازید. هر درخواست بعدی که دقیقاً با همان بایتها شروع شود، برای آن بخش، یکدهم قیمت عادی ورودی را پرداخت میکند. پیشوندی که در طول عمر خود هرگز بازاستفاده نشود، باعث میشود 25 درصد هزینه اضافی را بیهوده پرداخت کرده باشید.
نقطه سربهسر، در یک خط جبر
فرض کنید B هزینه پایه ورودی برای پیشوند (prefix) در حالت بدون کش باشد. بدون کش، N درخواست هزینهای معادل N ضربدر B دارند. با کش 5 دقیقهای، درخواست اول پیشوند را با هزینه 1.25B مینویسد و N منهای 1 درخواست دیگر آن را با هزینه 0.1B میخوانند. با برابر قرار دادن این دو، به معادله 0.9N = 1.15 میرسیم که نتیجه آن N = 1.28 است. یعنی از همان درخواست دوم، استفاده از کش ارزانتر از حالت بدون کش است.
همین محاسبه را برای کش 1 ساعته با هزینه نوشتن 2 برابر تکرار کنید؛ به معادله 0.9N = 1.9 میرسیم که نتیجه آن N = 2.11 است. کش طولانیمدت برای رسیدن به نقطه سربهسر به دو بار خواندن نیاز دارد و به همین دلیل گزینه پیشفرض نیست.
نمودار زیر این هزینهها را برای یک پیشوند 20,000 توکنی در Claude Opus 5 محاسبه کرده است که نرخ پایه ورودی آن تا اوت 2026 برابر با 5 دلار به ازای هر میلیون توکن است. برای مدلی با نرخ 3 دلار به ازای هر میلیون توکن، تمام ارقام را در 0.6 ضرب کنید. شکل منحنی تغییر نمیکند.
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"
}
]یک درخواست بهتنهایی در حالت بدون کش $0.10 و با کش $0.125 هزینه دارد، بنابراین کش کردن یک پرامپت تکمرحلهای (one-shot) صرفاً باعث ضرر میشود. در درخواست دوم، هزینه کش 5 دقیقهای $0.135 در مقابل $0.20 است. در این مرحله، کش 1 ساعته همچنان گرانتر است و با هزینه $0.21 در مقابل همان $0.20 قرار میگیرد و تنها در درخواست سوم از خط بدون کش عبور میکند: $0.22 در مقابل $0.30. با رسیدن به 20 درخواست، اختلاف هزینه $2.00 در مقابل $0.315 خواهد بود.
هر Cache hit ورودی را تازه میکند؛ به همین دلیل است که در جدول قیمتهای منتشرشده، آن ستون با عنوان cache hits and refreshes نامگذاری شده است. بنابراین، یک endpoint پرکار، ورودی 5 دقیقهای را با قیمتهای خواندن بهطور نامحدود زنده نگه میدارد و عمر 1 ساعته تنها زمانی هزینه نوشتن 2 برابری خود را جبران میکند که ترافیک شما دارای وقفههای واقعی باشد.
هزینه نرخ اصابت پایین
ترافیک واقعی با Miss مواجه میشود. درخواستی که در کش پیدا نمیشود (Miss) اما همچنان دارای breakpoint است، به عنوان یک Write محاسبه میشود؛ بنابراین روش صحیح مدلسازی این است که هزینه را تابعی از نرخ اصابت (hit rate) در نظر بگیریم. نمودار زیر این موضوع را برای 1,000 درخواست نشان میدهد که هر کدام دارای پیشوند یکسان 20,000 توکنی هستند.
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 درصد، شما به جای $100.00 باید $125.00 بپردازید و کش 1 ساعته، صورتحساب را به $200.00 افزایش میدهد. معادله 1.25 منهای 1.15h مساوی 1 را حل کنید؛ کش 5 دقیقهای در نرخ اصابت حدود 22 درصد شروع به صرفهجویی در هزینهها میکند، به همین دلیل است که در 25 درصد، مقدار $96.25 نمایش داده میشود. محاسبات مشابه برای Write دوبرابر، نرخ حدود 53 درصد را برای کش 1 ساعته نشان میدهد؛ بنابراین نرخ اصابت 50 درصد همچنان هزینهای معادل $105.00 دارد که بالاتر از خط بدون کش است. در 90 درصد، این دو به مقادیر $21.50 و $29.00 میرسند. در 99 درصد، کش کوتاهمدت به $11.15 میرسد که نزدیک به کف قیمت، یعنی یکدهم قیمت بدون کش است.
نرخ اصابت عددی است که باید آن را اندازهگیری (instrument) کنید، زیرا تنها ورودی است که پس از تعیین اندازه پیشوند، تحت کنترل شما قرار دارد.
کدام پیشوندها ارزش تعیین نقطه شکست (breakpoint) را دارند
یک درخواست میتواند تا چهار نقطه شکست کش (cache breakpoint) داشته باشد، بنابراین پرسش این است که کدام بلوکها شایسته داشتن یکی از آنها هستند. کاندیداها بلوکهایی هستند که در فراخوانیهای مختلف از نظر بایت یکسان بوده و بهاندازه کافی بزرگ باشند که اهمیت پیدا کنند. نمودار زیر قیمت چهار شکل رایج را برای 1,000 درخواست با نرخ موفقیت 90 درصد در کش 5 دقیقهای محاسبه کرده است.
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 توکن، مبلغ $7.85 را در هر 1,000 درخواست نسبت به حالت بدون کش با هزینه $10.00 صرفهجویی میکند. این مبلغ در حجم بالا قابلتوجه است، اما دلیل اصلی جذابیت کشینگ نیست. با افزودن تعریف ابزارها، به 8,000 توکن و $31.40 صرفهجویی میرسید. یک سند خطمشی با 25,000 توکن که هر درخواست درباره آن پرسش میکند، $98.12 صرفهجویی به همراه دارد. ردیف آخر همان موردی است که معماری را تغییر میدهد: 120,000 توکن از کدبیس یا متن زمینه، در حالت بدون کش $600.00 و در حالت کششده $129.00 هزینه دارد که منجر به صرفهجویی $471.00 میشود.
میزان صرفهجویی با اندازه پیشوند و نرخ موفقیت (hit rate) مقیاس میشود و به هیچ عامل دیگری بستگی ندارد. این موضوع باعث میشود که در مورد آنچه در پرامپت قرار میدهید تجدیدنظر کنید: هزینه واقعی یک میلیون توکن Claude برای هر چیزی که بیش از یک بار ارسال میکنید، به یکدهم قیمت درجشده کاهش مییابد.
نمای آن در صورتحساب ماهانه
نمودار زیر از پیشوند توکن 8,000 که در بالا ذکر شد، به همراه یک system prompt و تعاریف ابزارها، با نرخ موفقیت (hit rate) 90 درصد استفاده کرده و آن را به حجم درخواستهای ماهانه تعمیم میدهد.
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 درخواست در ماه، صرفهجویی برابر با $314.00 است که تفاوت بین $400.00 و $86.00 محسوب میشود. در 100,000 درخواست، این مقدار $3,140.00 است. در یک میلیون درخواست، صورتحساب ورودی بدون کش برابر با $40,000.00 است و استفاده از کش، $31,400.00 از آن را کاهش میدهد. این ارقام فقط مربوط به توکنهای ورودی هستند. خروجی بهصورت جداگانه قیمتگذاری میشود و کشینگ تأثیری بر آن ندارد؛ نکتهای که پیش از وعده دادن کاهش 90 درصدی صورتحساب به دیگران، باید به خاطر داشت. کشینگ در کنار سایر روشهای کلی در کنترل هزینههای یک ایجنت هوش مصنوعی روی VPS قرار میگیرد.
نحوه اطمینان از عملکرد کش
به طراحی سیستم اعتماد نکنید. بلوک usage در پاسخ دریافتی را بررسی کنید. هر پاسخ Messages API تعداد توکنهای نوشتهشده در کش، توکنهای خواندهشده از کش و توکنهای جدیدی که پردازش شدهاند را گزارش میدهد.
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)درخواست را دو بار با یک سند واحد و پرسشهای متفاوت اجرا کنید. فراخوانی اول مقدار غیرصفر برای cache_creation_input_tokens و مقدار صفر برای cache_read_input_tokens گزارش میدهد. در فراخوانی دوم این وضعیت معکوس میشود، زیرا پیشوند (prefix) پیدا شده است. مقدار input_tokens فقط توکنهای بعد از آخرین breakpoint را میشمارد؛ بنابراین در یک فراخوانی دومِ سالم، این مقدار کوچک است و معمولاً فقط شامل پیام جدید کاربر میشود.
همین بررسی را میتوانید از طریق shell و با استفاده از بدنه درخواستی که در request.json ذخیره کردهاید انجام دهید:
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'یک فراخوانی دومِ سالم، خروجی مشابه زیر را نمایش میدهد:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}یک خط در این خروجی حقیقت را به شما میگوید. اگر مقدار cache_read_input_tokens در فراخوانیهای متوالی روی 0 باقی بماند، یعنی شما هر بار هزینه 1.25 برابری نوشتن را پرداخت میکنید و هیچ بهرهای از کش نمیبرید.
برای طول عمر 1 ساعته، breakpoint دارای یک زمان ماندگاری (TTL) است:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}قابلیت کش خودکار نیز وجود دارد: یک فیلد واحد cache_control در سطح بالای درخواست که پس از آن، API با رشد مکالمه، مدیریت breakpointها را بر عهده میگیرد. این قابلیت یکی از چهار جایگاه breakpoint شما را مصرف میکند. از همینجا شروع کنید. زمانی که نیاز دارید دقیقاً تعیین کنید مرز کش کجا باشد، به سراغ breakpointهای صریح (explicit) بروید.
قانون ترتیببندی که نرخ موفقیت کش را از بین میبرد
کش، پیشوند درخواست را بایت به بایت از ابتدای آن تطبیق میدهد و درخواست با ترتیبی ثابت سرهمبندی میشود: ابزارها، سپس سیستم، و در نهایت پیامها. تغییر در هر سطح، آن سطح و تمام سطوح بعدی را نامعتبر میکند. اگر توضیحات یک ابزار را ویرایش کنید، پرامپت سیستم و کل تاریخچه پیامها نیز همراه با آن نامعتبر میشوند، حتی اگر به آنها دست نزده باشید.
این موضوع یک قانون بدون استثنا ایجاد میکند: هر چیزی که بین فراخوانیها تغییر میکند، باید پس از تمام مواردی قرار بگیرد که تغییر نمیکنند.
مقصر معمول، یک برچسب زمانی (timestamp) است. وجود خطی مانند Current time: 2026-08-03T14:07:11Z در ابتدای یک پرامپت سیستم، نرخ موفقیت 0 درصد را تضمین میکند؛ زیرا هش پیشوند در هر فراخوانی متفاوت است و هیچ ورودی قبلی نمیتواند با آن مطابقت داشته باشد. آن را به انتهای پیام کاربر منتقل کنید. یک شناسه نشست (session identifier) یا یک nonce برای هر درخواست نیز به همین شکل باعث اختلال میشود و راه حل مشابهی دارد. اسناد بازیابیشدهای که در هر درخواست متفاوت هستند نیز باید پس از بلوک کششده قرار بگیرند، در غیر این صورت، تمام توکنهای ثابت را به پشت مرزی میرانند که مدام در حال جابهجایی است.
دومین مقصر، قرار دادن نقطه شکست (breakpoint) روی بلوکی است که تغییر میکند. عملیات نوشتن در کش در نقطه شکست انجام میشود؛ بنابراین اگر آن بلوک هر بار متفاوت باشد، هیچ داده پایداری ذخیره نمیشود و جستجوی بازگشتی (lookback) فقط ورودیهایی را مییابد که درخواستهای قبلی در نقاط شکست متغیر خود نوشتهاند. مقدار cache_control را روی آخرین بلوکی قرار دهید که محتوای آن در تمام درخواستها یکسان است.
سومین مورد، تغییر پارامتری است که آن را به عنوان محتوای پرامپت در نظر نگرفتهاید. مدل متفاوت، کش متفاوتی دارد. تغییر در انتخاب ابزار، کش را از سطح سیستم به بعد نامعتبر میکند. افزودن یا حذف یک ابزار نیز همه چیز را نامعتبر میسازد.
حداقل پیشوند و عملیات بیاثر (no-op) خاموش
اگر طول پیشوند از حداقل تعیینشده توسط مدل کمتر باشد، در حافظه پنهان (cache) ذخیره نمیشود و هیچ هشداری نیز دریافت نخواهید کرد. نه خطایی رخ میدهد و نه هشداری صادر میشود. درخواست با موفقیت انجام شده و هر دو شمارنده عدد 0 را نشان میدهند. تا اوت 2026، حداقلهای اعلامشده به شرح زیر است:
- 512 توکن برای Claude Opus 5 و Claude Fable 5
- 1,024 توکن برای Claude Sonnet 5 و Claude Opus 4.8
- 4,096 توکن برای Claude Haiku 4.5
اگر در درخواستی که تصور میکنید باید در حافظه پنهان باشد، هر دو شمارنده عدد 0 را نشان میدهند، پیش از هر اقدام دیگری طول پیشوند را بررسی کنید. به همین دلیل است که ارزانترین مدل، لزوماً برای بارهای کاری مبتنی بر caching ارزانترین گزینه نیست. مدل Haiku 4.5 برای فعالسازی caching به پیشوندی هشت برابر طولانیتر از Opus 5 نیاز دارد؛ بنابراین یک system prompt با 2,000 توکن در یکی از این مدلها ذخیره میشود و در دیگری بدون هیچ پیامی نادیده گرفته میشود.
محل کش شدن دادهها توسط Claude Code و محدودیتهای آن
Claude Code پیشوند (prefix) خود را کش میکند. پرامپت سیستم و تعاریف ابزارها در ابتدای هر درخواست قرار میگیرند و تغییر نمیکنند؛ بنابراین یک بار نوشته شده و در ادامهٔ نشست (session) بازخوانی میشوند. به همین دلیل است که هزینهٔ هر نوبت (turn) در یک نشست طولانی، بسیار کمتر از آن چیزی است که اندازهٔ کانتکست نشان میدهد، و این موضوع در شمارندههایی که در نحوه گزارشدهی مصرف توکن توسط Claude Code توضیح داده شده، قابل مشاهده است.
جایی که این قابلیت نمیتواند به شما کمک کند، ویرایش در نزدیکی ابتدای کانتکست است. تاریخچهٔ گفتگو فقط به صورت append-only است، بنابراین نوبتهای جدیدِ معمولی، پیشوندی را که از قبل کش شده است گسترش میدهند. ویرایش فایلی که در اوایل نشست خوانده شده، محتوای میانی آن پیشوند را تغییر میدهد و هر توکنی که پس از آن تغییر قرار دارد، باید دوباره نوشته شود. یک وقفهٔ طولانی در فعالیت نیز همین نتیجه را دارد، زیرا ورودی منقضی میشود و نوبت بعدی هزینهٔ کامل نوشتن را پرداخت میکند. هیچکدام از این موارد باگ نیستند. هر دو مورد، اجرای دقیق قانون پیشوند هستند.
اگر در حال نوشتن کلاینت اختصاصی خود هستید، به جای اصلاح ساختار در میانهٔ کار، از همان ابتدا چیدمان اولین درخواست را اعمال کنید: فراخوانی را به شکلی که در اولین اپلیکیشن Claude API روی یک VPS آمده است بسازید؛ یعنی بلوکهای ثابت را در ابتدا و بلوکهای متغیر را در انتها قرار دهید.
حالتهای شکست و آنچه مشاهده خواهید کرد
هر فراخوانی یک عملیات نوشتن است. مقدار cache_creation_input_tokens در هر درخواست غیرصفر است، در حالی که cache_read_input_tokens صفر باقی میماند. چیزی در نقطه شکست یا پیش از آن، بین فراخوانیها تغییر میکند. 200 کاراکتر اول پیشوند اسمبلشده خود را در دو درخواست متوالی چاپ کرده و آنها را با چشم مقایسه کنید.
هر دو شمارنده صفر هستند. پیشوند کمتر از حداقل مدل است یا فیلد cache_control هرگز به API نرسیده است. ابتدا توکنهای پیشوند را بشمارید، سپس بدنه درخواستی که واقعاً ارسال کردهاید را لاگ کنید.
خواندنها کار میکنند، سپس متوقف میشوند. یک سری موفقیت (hit)، سپس یک عملیات نوشتن، و دوباره موفقیت. فاصله بین درخواستها طولانیتر از زمان حیات (lifetime) بوده است. عملیات نوشتن را بپذیرید، یا پس از اینکه مطمئن شدید نرخ موفقیت شما از 53 درصد فراتر میرود، به TTL یک ساعته منتقل شوید.
نرخ موفقیت پس از یک استقرار (deploy) کاهش مییابد. توضیحات یک ابزار ویرایش شده یا مدل تغییر کرده است. هر دو مورد باعث ابطال کل پیشوند میشوند. پس از هر استقراری که prompt را تغییر میدهد، انتظار یک دور پرهزینه از عملیات نوشتن را داشته باشید.
هزینه پس از فعالسازی کش افزایش یافته است. نرخ موفقیت شما کمتر از نقطه سربهسر است. در کش 5 دقیقهای، اگر نرخ موفقیت زیر حدود 22 درصد باشد، ارسال پیشوند بدون کش ارزانتر است؛ در کش یک ساعته نیز همین قاعده برای نرخهای زیر حدود 53 درصد صادق است.
FAQ
چند بار استفاده مجدد از یک prompt لازم است تا کش کردن صرفه اقتصادی داشته باشد؟
یک بار، در کش 5 دقیقهای. هزینه نوشتن 1.25 برابر ورودی پایه و هزینه خواندن 0.1 برابر آن است، بنابراین N درخواست بدون کش هزینه N را دارند، در حالی که N درخواست کششده هزینه 1.25 به اضافه 0.1 ضربدر N منهای 1 را دارند. این دو مقدار در N = 1.28 با هم تلاقی میکنند، بنابراین از درخواست دوم به بعد صرفه اقتصادی حاصل شده است. کش 1 ساعته با هزینه 2 برابر مینویسد و در N = 2.11 تلاقی میکند، بنابراین به دو بار خواندن نیاز دارد.
چرا مقدار cache_read_input_tokens همیشه صفر است؟
ابتدا طول پیشوند (prefix) را بررسی کنید: زیر حداقل تعیینشده توسط مدل، یعنی 512 توکن در Claude Opus 5 و 4096 توکن در Claude Haiku 4.5 تا اوت 2026، کش کردن بهصورت بیصدا نادیده گرفته میشود و هر دو شمارنده 0 را نشان میدهند. اگر طول پیشوند کافی است، به دنبال محتوایی بگردید که بین فراخوانیها تغییر میکند و در نقطه شکست (breakpoint) یا قبل از آن قرار دارد، مانند یک برچسب زمانی یا شناسه نشست در system prompt. اگر شمارندهها کار میکردند و متوقف شدند، فاصله بین درخواستها طولانیتر از طول عمر کش بوده است.
آیا prompt caching پاسخهای Claude را تغییر میدهد؟
خیر. کش شکل پردازششده توکنهایی را که قبلاً ارسال کردهاید ذخیره میکند و مدل در هر دو حالت prompt یکسانی را میبیند. این یک قابلیت برای مدیریت هزینهها و تأخیر است، نه تغییری در رفتار مدل. این بدان معناست که میتوانید آن را روی یک prompt فعال بدون نیاز به اجرای مجدد ارزیابیهای خود، فعال کنید.
آیا باید هزینه کش 1 ساعته را بپردازم؟
فقط زمانی که ترافیک شما فواصل طولانیتر از 5 دقیقه دارد و نرخ موفقیت (hit rate) شما همچنان حدود 53 درصد باقی میماند. هزینه نوشتن 2 برابری، دو برابرِ هزینه نوشتن 1.25 برابری در صورت عدم موفقیت (miss) است. یک ورودی 5 دقیقهای با هر بار موفقیت (hit) تازه میشود، بنابراین ترافیک مداوم آن را با قیمتهای خواندن زنده نگه میدارد بدون اینکه نیازی به پرداخت هزینه برای طول عمر بیشتر باشد.