محاسبه نقطه سربه‌سر در Claude Prompt Caching

هزینه‌های کش کردن پرامپت پیش از صرفه‌جویی

قابلیت Prompt caching به Claude اجازه می‌دهد به‌جای خواندن مجدد بخش ابتدایی پرامپت در هر فراخوانی، آن را بازاستفاده کند. کل تصمیم‌گیری در این زمینه به دو ضریب نسبت به قیمت پایه ورودی مدل بستگی دارد. تا اوت 2026، هزینه نوشتن در کش برای طول عمر 5 دقیقه معادل 1.25 برابر ورودی پایه، و برای طول عمر 1 ساعت معادل 2 برابر آن است. هزینه خواندن از کش نیز 0.1 برابر است. این ضرایب در تمام لیست مدل‌ها ثابت هستند، بنابراین نقطه سربه‌سر (break-even) ذکر شده در ادامه، با تغییر قیمت هر توکن تغییر نمی‌کند.

این معامله در واقع پرداخت هزینه اضافی در لحظه، در برابر دریافت تخفیف در آینده است. شما یک بار هزینه بیشتری برای ذخیره یک پیشوند (prefix) می‌پردازید. هر درخواست بعدی که دقیقاً با همان بایت‌ها شروع شود، برای آن بخش، یک‌دهم قیمت ورودی عادی را پرداخت می‌کند. پیشوندی که در طول عمر خود هرگز بازاستفاده نشود، باعث می‌شود 25 درصد هزینه اضافی را بیهوده پرداخت کرده باشید.

نقطه سر‌به‌سر، در یک خط جبر

فرض کنید B هزینه پایه ورودی پیشوند در صورت ارسال بدون کش باشد. بدون کش، N درخواست هزینه‌ای معادل N ضرب‌در B دارند. با کش 5 دقیقه‌ای، اولین درخواست پیشوند را با هزینه 1.25B می‌نویسد و N منهای 1 درخواست دیگر آن را با هزینه 0.1B می‌خوانند. با برابر قرار دادن این دو، به 0.9N = 1.15 می‌رسیم، یعنی N = 1.28. درخواست دوم از قبل ارزان‌تر از حالت بدون کش است.

این محاسبه را با هزینه نوشتن 2 برابری در کش 1 ساعته تکرار کنید که نتیجه آن 0.9N = 1.9 و در نتیجه N = 2.11 می‌شود. کش طولانی‌مدت برای رسیدن به نقطه سر‌به‌سر به دو بار خواندن نیاز دارد، به همین دلیل است که انتخاب پیش‌فرض نیست.

نمودار زیر این هزینه‌ها را برای یک پیشوند 20,000 توکنی در مدل Claude Opus 5 محاسبه کرده است که نرخ پایه ورودی آن تا آگوست 2026 برابر با 5 دلار به ازای هر میلیون توکن است. برای مدلی با نرخ 3 دلار به ازای هر میلیون توکن، تمام ارقام را در 0.6 ضرب کنید. شکل نمودار تغییر نمی‌کند.

[
  {
    "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 همچنین ورودی را بازنشانی (refresh) می‌کند، به همین دلیل است که جدول قیمت‌های منتشرشده، آن ستون را cache hits and refreshes نام‌گذاری کرده است. بنابراین یک endpoint پرکار، ورودی 5 دقیقه‌ای را با قیمت‌های خواندن به‌طور نامحدود زنده نگه می‌دارد و طول عمر 1 ساعته تنها زمانی هزینه نوشتن 2 برابری خود را جبران می‌کند که ترافیک شما وقفه‌های واقعی داشته باشد.

هزینه نرخ اصابت پایین

ترافیک واقعی با Miss مواجه می‌شود. درخواستی که در کش پیدا نمی‌شود اما همچنان دارای breakpoint است، به عنوان یک عملیات نوشتن (write) محاسبه می‌شود. بنابراین، روش صحیح مدل‌سازی این است که هزینه را تابعی از نرخ اصابت (hit rate) در نظر بگیریم. نمودار زیر این موضوع را برای 1,000 درخواست نشان می‌دهد که هر کدام دارای پیشوند یکسان 20,000 توکنی هستند.

[
  {
    "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 نمایش داده می‌شود. محاسبات مشابه برای عملیات نوشتن 2 برابری، نرخ حدود 53 درصد را برای کش 1 ساعته نشان می‌دهد؛ بنابراین نرخ اصابت 50 درصد همچنان هزینه‌ای معادل $105.00 دارد که بالاتر از خط بدون کش است. در نرخ 90 درصد، این دو مقدار به $21.50 و $29.00 می‌رسند. در نرخ 99 درصد، کش کوتاه‌مدت به $11.15 می‌رسد که نزدیک به کف قیمت، یعنی یک‌دهم قیمت بدون کش است.

نرخ اصابت عددی است که باید آن را اندازه‌گیری کنید، زیرا تنها ورودی است که پس از تعیین اندازه پیشوند، تحت کنترل شما قرار دارد.

کدام پیشوندها ارزش تعیین breakpoint را دارند

یک درخواست می‌تواند تا چهار breakpoint کش داشته باشد، بنابراین پرسش این است که کدام بلوک‌ها شایسته داشتن آن هستند. کاندیداها بلوک‌هایی هستند که در فراخوانی‌های مختلف از نظر بایت یکسان بوده و به‌اندازه کافی بزرگ باشند که اهمیت پیدا کنند. جدول زیر هزینه چهار شکل رایج را برای 1,000 درخواست با نرخ موفقیت 90 درصد در کش 5 دقیقه‌ای محاسبه کرده است.

[
  {
    "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 توکن، در هر 1,000 درخواست $7.85 صرفه‌جویی ایجاد می‌کند، در حالی که هزینه حالت بدون کش $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 درصد استفاده کرده و آن را به حجم درخواست‌های ماهانه تعمیم می‌دهد.

[
  {
    "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 در پاسخ دریافتی را بررسی کنید. هر پاسخ 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 را می‌شمارد، بنابراین در یک فراخوانی دومِ سالم، این مقدار کوچک است و معمولاً فقط شامل پیام جدید کاربر می‌شود. هر دو فراخوانی مشمول هزینه هستند، زیرا سرویس Claude API هیچ سطح رایگانی ندارد، اگرچه هزینه پیشوند 20,000 توکنی در این جفت فراخوانی حدود چهارده سنت می‌شود.

همین بررسی را از طریق 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ها را بر عهده می‌گیرد. این قابلیت یکی از چهار جایگاه (slot) breakpoint شما را اشغال می‌کند. از همین‌جا شروع کنید. زمانی که نیاز دارید دقیقاً تعیین کنید مرز کش کجا باشد، به سراغ breakpointهای صریح (explicit) بروید.

قانون ترتیب‌بندی که نرخ موفقیت کش را از بین می‌برد

کش، پیشوند درخواست را بایت به بایت از ابتدای آن مطابقت می‌دهد و درخواست با ترتیبی ثابت سرهم‌بندی می‌شود: ابزارها، سپس سیستم، و در نهایت پیام‌ها. تغییر در هر سطح، آن سطح و تمام سطوح پس از آن را نامعتبر می‌کند. ویرایش توضیحات یک ابزار باعث می‌شود که پرامپت سیستم و کل تاریخچه پیام‌ها نیز نامعتبر شوند، حتی اگر به آن‌ها دست نزده باشید.

این موضوع یک قانون بدون استثنا ایجاد می‌کند: هر چیزی که بین فراخوانی‌ها تغییر می‌کند، باید پس از تمام مواردی قرار بگیرد که تغییر نمی‌کنند.

متهم معمول، یک برچسب زمانی (timestamp) است. وجود خطی مانند Current time: 2026-08-03T14:07:11Z در ابتدای یک پرامپت سیستم، نرخ موفقیت صفر درصد را تضمین می‌کند، زیرا هش پیشوند در هر فراخوانی متفاوت است و هیچ ورودی پیشین نمی‌تواند با آن مطابقت داشته باشد. آن را به انتهای پیام کاربر منتقل کنید. شناسه نشست (session identifier) یا nonce مختص هر درخواست نیز به همین شکل باعث اختلال می‌شود و راهکار مشابهی دارد. اسناد بازیابی‌شده‌ای که در هر درخواست متفاوت هستند نیز باید پس از بلوک کش‌شده قرار بگیرند، در غیر این صورت هر توکن ثابتی را به پشت مرزی می‌رانند که مدام در حال تغییر است.

دومین متهم، قرار دادن نقطه شکست (breakpoint) روی بلوکی است که تغییر می‌کند. عملیات نوشتن در کش در نقطه شکست انجام می‌شود؛ بنابراین اگر آن بلوک هر بار متفاوت باشد، هیچ داده پایداری ذخیره نمی‌شود و جستجوی بازگشتی (lookback) تنها ورودی‌هایی را می‌یابد که درخواست‌های قبلی در نقاط شکست متغیر خود نوشته‌اند. مقدار cache_control را روی آخرین بلوکی قرار دهید که محتوای آن در تمام درخواست‌ها یکسان است.

سومین مورد، تغییر پارامتری است که آن را به عنوان محتوای پرامپت در نظر نگرفته‌اید. مدل متفاوت، کش متفاوتی دارد. تغییر در انتخاب ابزار، کش را از سطح سیستم به بعد نامعتبر می‌کند. افزودن یا حذف یک ابزار نیز همه چیز را نامعتبر می‌سازد.

حداقل پیشوند و عملکرد بی‌صدا (no-op)

پیشوندی که کوتاه‌تر از حداقلِ تعیین‌شده توسط مدل باشد، کش نمی‌شود و هیچ هشداری نیز دریافت نخواهید کرد. نه خطایی وجود دارد و نه هشداری. درخواست با موفقیت انجام می‌شود و هر دو شمارنده عدد 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 را نشان می‌دهند، پیش از هر اقدام دیگری طول پیشوند را بررسی کنید. به همین دلیل است که ارزان‌ترین مدل، لزوماً برای یک workload مبتنی بر کش، ارزان‌ترین گزینه نیست. مدل Haiku 4.5 به پیشوندی هشت برابر طولانی‌تر از Opus 5 نیاز دارد تا کش فعال شود؛ بنابراین یک system prompt با 2,000 توکن در یکی کش می‌شود و در دیگری بدون هیچ پیامی نادیده گرفته می‌شود.

محل کش شدن Claude Code و محدودیت‌های آن

Claude Code پیش‌وند (prefix) خود را کش می‌کند. پرامپت سیستم و تعاریف ابزارها در ابتدای هر درخواست قرار می‌گیرند و تغییر نمی‌کنند؛ بنابراین یک بار نوشته شده و در ادامهٔ نشست (session) دوباره خوانده می‌شوند. به همین دلیل است که هزینهٔ هر نوبت در یک نشست طولانی، بسیار کمتر از آن چیزی است که اندازهٔ کانتکست نشان می‌دهد، و این موضوع در شمارنده‌هایی که در نحوه گزارش‌دهی Claude Code از مصرف توکن توضیح داده شده، قابل مشاهده است.

جایی که این قابلیت نمی‌تواند به شما کمک کند، ویرایش در نزدیکی ابتدای کانتکست است. تاریخچهٔ گفتگو فقط به صورت append-only است، بنابراین نوبت‌های جدیدِ عادی، پیش‌وندی را که از قبل کش شده است گسترش می‌دهند. ویرایش فایلی که در اوایل نشست خوانده شده، محتوای میانی آن پیش‌وند را تغییر می‌دهد و هر توکنی که پس از آن تغییر قرار دارد، باید دوباره نوشته شود. یک وقفهٔ طولانی و بدون فعالیت نیز همین نتیجه را دارد، زیرا ورودی منقضی می‌شود و نوبت بعدی هزینهٔ کامل نوشتن را پرداخت می‌کند. هیچ‌کدام از این موارد باگ نیستند. هر دو مورد، قانون پیش‌وند هستند که دقیقاً طبق تعریف عمل می‌کنند.

اگر در حال نوشتن کلاینت اختصاصی خود هستید، چیدمان را از همان درخواست اول اعمال کنید و به فکر اصلاح آن در مراحل بعدی نباشید: فراخوانی را به شکلی بسازید که در اولین برنامه Claude API روی یک VPS انجام می‌شود؛ یعنی بلوک‌های ثابت در ابتدا و بلوک‌های متغیر در انتها قرار گیرند.

حالت‌های شکست و آنچه مشاهده خواهید کرد

هر فراخوانی یک عملیات نوشتن است. مقدار cache_creation_input_tokens در هر درخواست غیرصفر است، در حالی که cache_read_input_tokens صفر باقی می‌ماند. چیزی در نقطه شکست یا پیش از آن، بین فراخوانی‌ها تغییر می‌کند. 200 کاراکتر اول پیشوند اسمبل‌شده خود را در دو درخواست متوالی چاپ کرده و آن‌ها را با چشم مقایسه کنید.

هر دو شمارنده صفر هستند. پیشوند کمتر از حداقل مدل است، یا فیلد cache_control هرگز به API نرسیده است. ابتدا توکن‌های پیشوند را بشمارید، سپس بدنه درخواستی که واقعاً ارسال کرده‌اید را لاگ کنید.

عملیات خواندن کار می‌کند، سپس متوقف می‌شود. مجموعه‌ای از موفقیت‌ها (hits)، سپس یک نوشتن، و دوباره موفقیت‌ها. فاصله بین درخواست‌ها طولانی‌تر از طول عمر (lifetime) بوده است. عملیات نوشتن را بپذیرید، یا پس از اطمینان از اینکه نرخ موفقیت شما از 53 درصد فراتر می‌رود، به TTL یک ساعته تغییر وضعیت دهید.

نرخ موفقیت پس از استقرار (deploy) کاهش می‌یابد. توضیحات یک ابزار ویرایش شده یا مدل تغییر کرده است. هر دو مورد باعث ابطال کل پیشوند می‌شوند. پس از هر استقراری که prompt را تغییر می‌دهد، انتظار یک دور پرهزینه از عملیات نوشتن را داشته باشید.

هزینه پس از فعال‌سازی کش افزایش یافته است. نرخ موفقیت شما کمتر از نقطه سربه‌سر است. در کش 5 دقیقه‌ای، اگر نرخ موفقیت زیر حدود 22 درصد باشد، ارسال پیشوند بدون کش ارزان‌تر است؛ و در کش یک ساعته، همین موضوع برای نرخ‌های زیر حدود 53 درصد صادق است.

FAQ

چند بار استفاده مجدد از یک prompt لازم است تا استفاده از cache صرفه اقتصادی داشته باشد؟

یک بار، در مورد cache با مدت زمان 5 دقیقه. هزینه نوشتن 1.25 برابر ورودی پایه و هزینه خواندن 0.1 برابر آن است، بنابراین N درخواست بدون cache هزینه N را دارند، در حالی که N درخواست با cache هزینه 1.25 به اضافه 0.1 ضربدر N منهای 1 را خواهند داشت. این دو مقدار در N = 1.28 یکدیگر را قطع می‌کنند، بنابراین درخواست دوم از قبل سودآور است. cache با مدت زمان 1 ساعت هزینه نوشتن 2 برابری دارد و در N = 2.11 یکدیگر را قطع می‌کنند، بنابراین به دو بار خواندن نیاز دارد.

چرا مقدار cache_read_input_tokens همیشه صفر است؟

ابتدا طول پیشوند (prefix) را بررسی کنید: زیر حداقل مقدار مدل، یعنی 512 توکن در Claude Opus 5 و 4,096 توکن در Claude Haiku 4.5 تا اوت 2026، عملیات caching بدون اطلاع قبلی نادیده گرفته می‌شود و هر دو شمارنده 0 را نشان می‌دهند. اگر طول پیشوند کافی است، به دنبال محتوایی بگردید که بین فراخوانی‌ها تغییر می‌کند و در نقطه شکست (breakpoint) یا قبل از آن قرار دارد، مانند یک برچسب زمانی یا شناسه نشست (session identifier) در system prompt. اگر شمارنده‌ها کار می‌کردند و متوقف شده‌اند، فاصله بین درخواست‌ها طولانی‌تر از طول عمر cache بوده است.

آیا prompt caching پاسخ‌های Claude را تغییر می‌دهد؟

خیر. cache شکل پردازش‌شده توکن‌هایی را که قبلاً ارسال کرده‌اید ذخیره می‌کند و مدل در هر دو حالت همان prompt را می‌بیند. این یک قابلیت مربوط به صورت‌حساب و تأخیر (latency) است، نه تغییری در رفتار مدل. این بدان معناست که می‌توانید آن را روی یک prompt فعال بدون نیاز به اجرای مجدد ارزیابی‌های خود فعال کنید.

آیا باید برای cache با مدت زمان 1 ساعت هزینه کنم؟

فقط زمانی که ترافیک شما وقفه‌هایی طولانی‌تر از 5 دقیقه دارد و نرخ موفقیت (hit rate) شما همچنان حدود 53 درصد باقی می‌ماند. هزینه نوشتن 2 برابری، در صورت عدم موفقیت (miss)، دو برابرِ هزینه نوشتن 1.25 برابری است. یک ورودی 5 دقیقه‌ای با هر بار موفقیت (hit) تازه می‌شود، بنابراین ترافیک مداوم آن را با قیمت‌های خواندن زنده نگه می‌دارد بدون اینکه نیازی به پرداخت هزینه برای طول عمر بیشتر باشد.