חישוב נקודת האיזון ב-Claude Prompt Caching

עלויות ה-Prompt Caching לפני החיסכון

ה-Prompt Caching מאפשר ל-Claude לעשות שימוש חוזר בחלקו הראשון של ה-prompt במקום לקרוא אותו מחדש בכל קריאה, וההחלטה כולה מסתכמת בשני מכפילים על מחיר הקלט הבסיסי של המודל. נכון לאוקטובר 2026, כתיבה למטמון עולה פי 1.25 ממחיר הקלט הבסיסי עבור זמן חיים של 5 דקות, או פי 2 עבור זמן חיים של שעה אחת, בכל המודלים. קריאה מהמטמון עולה פי 0.1 ברוב המודלים, אך מכפיל הקריאה אינו אחיד עוד בכל המקומות. הוא עומד על פי 0.025 ב-Claude Fable 5.1 וב-Claude Mythos 5.1, שהושקו בתעריף זה ב-1 בספטמבר 2026. הוא עומד על פי 0.05 ב-Claude Opus 5.5 וב-Claude Sonnet 5.5, כאשר התעריף של Sonnet 5.5 הופחת מ-0.1 לערך זה ב-7 באוקטובר 2026. הנתונים המחושבים להלן משתמשים בתעריף הקריאה הסטנדרטי של 0.1. קריאות זולות יותר מטיבות מעט עם נקודת האיזון, והסעיף הבא מציג בכמה.

העסקה היא תוספת תשלום כעת כנגד הנחה מאוחרת יותר. אתם משלמים תוספת פעם אחת כדי לאחסן תחילית (prefix). כל בקשה מאוחרת שמתחילה בדיוק באותם בתים משלמת לאחר מכן עשירית ממחיר הקלט הרגיל עבור אותו חלק, או פחות במודלים שצוינו לעיל. תחילית שלעולם אינה בשימוש חוזר בתוך זמן החיים שלה עלתה לכם 25 אחוזים נוספים ללא תמורה.

נקודת האיזון, בשורת אלגברה אחת

נסמן ב-B את עלות הקלט הבסיסית של ה-prefix ללא שימוש ב-cache. ללא cache, עלות של N בקשות היא N כפול B. עם cache של 5 דקות, הבקשה הראשונה כותבת את ה-prefix בעלות של 1.25B, ושאר N פחות 1 הבקשות קוראות אותו בעלות של 0.1B. נשווה בין השתיים ונקבל 0.9N = 1.15, כלומר N = 1.28. הבקשה השנייה כבר זולה יותר מאשר ללא cache כלל.

נחזור על החישוב עם עלות כתיבה כפולה (2x) של ה-cache ל-שעה אחת ונקבל 0.9N = 1.9, כלומר N = 2.11. ה-cache הארוך דורש שתי קריאות לפני שהוא מגיע לנקודת האיזון, וזו הסיבה שהוא אינו ברירת המחדל.

בעלויות קריאה נמוכות יותר הקו זז, אך לא באופן משמעותי. בעלות קריאה של 0.05x, ה-cache ל-5 דקות נותן 0.95N = 1.2, כלומר N = 1.26, ובעלות של 0.025x הוא נותן 0.975N = 1.225, שגם הוא N = 1.26. ה-cache ל-שעה אחת יורד ל-N = 2.05 ו-N = 2.03. התשובה המעשית זהה בכל המודלים: ה-cache ל-5 דקות משתלם החל מהבקשה השנייה, וה-cache ל-שעה אחת החל מהשלישית.

התרשים להלן מתמחר זאת עבור prefix של 20,000 טוקנים ב-Claude Opus 5. תעריף הקלט הבסיסי שלו הוא $5 למיליון טוקנים נכון לאוקטובר 2026, ללא שינוי מאז אוגוסט. Opus 5 הוא כעת מודל legacy, אם כי הוא עדיין זמין. יורשו, Claude Opus 5.5, מתומחר ב-$4 למיליון עם קריאה של 0.05x, כך שאותו prefix שם עולה $0.10 לכתיבה ו-$0.004 לקריאה. יש להכפיל כל נתון ב-0.6 עבור מודל של $3 למיליון עם קריאה סטנדרטית של 0.1x. צורת העקומה אינה משתנה.

[
  {
    "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 ללא cache ו-$0.125 עם cache, כך ששימוש ב-cache עבור prompt חד-פעמי הוא הפסד נקי. בבקשה השנייה, ה-cache ל-5 דקות עומד על $0.135 לעומת $0.20. ה-cache ל-שעה אחת עדיין נמצא מאחור בנקודה זו, עם $0.21 לעומת אותו $0.20, והוא עובר את קו ה-uncached רק בבקשה השלישית: $0.22 לעומת $0.30. ב-20 בקשות, הפער הוא $2.00 לעומת $0.315.

פגיעת cache (cache hit) גם מרעננת את הרשומה, וזו הסיבה שטבלת המחירים המפורסמת מכנה את העמודה הזו cache hits and refreshes. לכן, endpoint עמוס שומר על רשומה של 5 דקות פעילה ללא הגבלת זמן במחירי קריאה, וזמן החיים של שעה אחת מצדיק את עלות הכתיבה הכפולה (2x) שלו רק כאשר בתעבורה שלכם יש הפסקות של ממש.

העלות של שיעור פגיעה נמוך

בקשות אמיתיות מפספסות את ה־cache. בקשה שמפספסת את ה־cache אך עדיין נושאת breakpoint מחויבת כפעולת כתיבה, לכן הדרך המדויקת למדל זאת היא כעלות כפונקציה של שיעור הפגיעה (hit rate). התרשים להלן מציג זאת עבור 1,000 בקשות, כאשר כל אחת נושאת prefix זהה של 20,000 token.

[
  {
    "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 אחוזים אתם משלמים $125.00 במקום $100.00, ו־cache של שעה אחת מכפיל את החשבון ל־$200.00. פתרון המשוואה 1.25 פחות 1.15h שווה 1 מראה ש־cache של 5 דקות מתחיל לחסוך כסף בשיעור פגיעה של כ-22 אחוזים, וזו הסיבה שב-25 אחוזים כבר רואים $96.25. אותו חישוב עבור כתיבה כפולה מניב כ-53 אחוזים עבור cache של שעה אחת, כך ששיעור פגיעה של 50 אחוזים עדיין עולה $105.00, מעל לקו של בקשות ללא cache. ב-90 אחוזים השניים מגיעים ל-$21.50 ו-$29.00. ב-99 אחוזים ה־cache הקצר מגיע ל-$11.15, קרוב לרצפת מחיר של עשירית מהעלות ללא cache.

במודל עם עלות קריאה של 0.05x, ספי הכדאיות יורדים לכ-21 אחוזים עבור cache של 5 דקות ול-51 אחוזים עבור cache של שעה אחת. בעלות קריאה של 0.025x הם יורדים לכ-20 ו-51 אחוזים בהתאמה. רצפת המחיר יורדת בהתאם לעלות הקריאה, לעשרים או לארבעים מהעלות ללא cache.

שיעור הפגיעה הוא המדד שיש לנטר, כיוון שהוא הקלט היחיד שאתם שולטים בו לאחר שגודל ה־prefix נקבע.

אילו תחיליות מצדיקות נקודת עצירה (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"
  }
]

הנחיית מערכת (system prompt) בסיסית של 2,000 טוקנים חוסכת $7.85 לכל 1,000 בקשות, לעומת $10.00 ללא מטמון. מדובר בכסף אמיתי בנפחים גבוהים, אך זה לא מה שהופך את השימוש במטמון למעניין. הוספת הגדרות הכלים מביאה אתכם ל-8,000 טוקנים וחיסכון של $31.40. מסמך מדיניות של 25,000 טוקנים, שכל בקשה שואלת לגביו שאלות, חוסך $98.12. השורה האחרונה היא זו שמשנה את הארכיטקטורה: 120,000 טוקנים של בסיס קוד או הקשר תמלול עולים $600.00 ללא מטמון ו-$129.00 עם מטמון, חיסכון של $471.00.

החיסכון גדל בהתאם לגודל התחילית ולשיעור הפגיעה, ולא בהתאם לשום דבר אחר. עובדה זו משנה את מה שכדאי בכלל להכניס להנחיה (prompt): כמה באמת עולים מיליון טוקנים של Claude יורד לעשירית מהמחיר הנקוב, או פחות בדגמים עם עלויות קריאה זולות יותר, עבור כל דבר שאתם שולחים יותר מפעם אחת.

איך זה נראה בחשבונית החודשית

התרשים להלן משתמש בקידומת ה-token מסוג 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. נתונים אלו מתייחסים ל-tokens של קלט בלבד. הפלט מתומחר בנפרד והמטמון אינו משפיע עליו; כדאי לזכור זאת לפני שמבטיחים למישהו הפחתה של 90 אחוז בחשבונית. השימוש במטמון הוא חלק מהרגלים רחבים יותר של שמירה על עלויות סוכן AI בשרת VPS.

כיצד לוודא שהמטמון (cache) פועל

אל תסתמכו על התכנון בלבד. קראו את בלוק השימוש בתגובה. כל תשובה של ה-Messages API מדווחת על האסימונים (tokens) שנכתבו למטמון, האסימונים שנקראו ממנו, והאסימונים החדשים שהיה עליהם לעבד.

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. הקריאה השנייה תהפוך את המצב, כיוון שהתחילית נמצאה. ה-input_tokens סופר רק את האסימונים שאחרי נקודת העצירה (breakpoint) האחרונה, לכן בקריאה שנייה תקינה הוא יהיה קטן, בדרך כלל רק הודעת המשתמש החדשה. שתי הקריאות מחויבות בתשלום, כיוון ש-ל-Claude API אין מסלול חינמי, אם כי עבור תחילית של 20,000 אסימונים, המחיר עבור הצמד מסתכם בכ-14 סנט.

אותה בדיקה מה-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.25x בכל פעם מחדש ולא מקבלים דבר בתמורה.

עבור זמן חיים של שעה אחת, נקודת העצירה נושאת זמן תפוגה (TTL):

{
  "type": "text",
  "text": "your stable prefix",
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

קיימת גם אפשרות למטמון אוטומטי: שדה cache_control יחיד ברמה העליונה של הבקשה, שלאחריו ה-API מנהל את נקודות העצירה ככל שהשיחה גדלה. הוא צורך אחד מארבעת חריצי נקודות העצירה שלכם. התחילו משם. עברו לנקודות עצירה מפורשות כאשר עליכם להחליט בדיוק היכן הגבול ממוקם.

כלל הסדר שפוגע בשיעורי ה־hit rate

המטמון מבצע התאמה של קידומת בתים (byte for byte) מתחילת הבקשה, והבקשה מורכבת בסדר קבוע: כלים, לאחר מכן מערכת, ולבסוף הודעות. שינוי בכל רמה מבטל את הרמה הזו ואת כל מה שבא אחריה. עריכה של תיאור כלי אחד מבטלת את ה־system prompt ואת כל היסטוריית ההודעות יחד איתו, גם אם לא נגעת בהם.

מכאן נובע כלל אחד ללא יוצא מן הכלל: כל נתון שמשתנה בין קריאות חייב להופיע אחרי כל מה שאינו משתנה.

הגורם השכיח ביותר הוא חותמת זמן. שורה המכילה Current time: 2026-08-03T14:07:11Z בראש ה־system prompt מבטיחה שיעור hit rate של 0 אחוזים, כיוון שה־hash של הקידומת שונה בכל קריאה, ושום רשומה קודמת לא תוכל להתאים לה. העבירו אותה להודעת המשתמש, בסופה. מזהה סשן או nonce לכל בקשה גורמים לאותה בעיה ודורשים את אותו פתרון. מסמכים שנשלפו ומשתנים בין בקשות צריכים גם הם להופיע אחרי הבלוק שנשמר במטמון, אחרת הם דוחפים כל token יציב אל מעבר לגבול שמשתנה ללא הרף.

הגורם השני הוא הצבת ה־breakpoint על הבלוק שמשתנה. כתיבה למטמון מתבצעת בנקודת ה־breakpoint; אם הבלוק הזה שונה בכל פעם, שום דבר יציב לא נשמר, והחיפוש לאחור מוצא רק רשומות שבקשות קודמות כתבו בנקודות ה־breakpoint המשתנות שלהן. הציבו את cache_control על הבלוק האחרון שהתוכן שלו זהה בכל הבקשות.

הגורם השלישי הוא שינוי פרמטר שלא נלקח בחשבון כתוכן של ה־prompt. מודל שונה משתמש במטמון שונה. שינוי של tool_choice מבטל את היסטוריית ההודעות, גם אם הכלים וה־system prompt נשארים במטמון. הוספה או הסרה של כלי מבטלת את הכל.

התחילית המינימלית ופעולת ה-no-op השקטה

תחילית הקצרה מהמינימום הנדרש על ידי המודל אינה נשמרת ב-cache, ואין כל חיווי על כך. לא מתקבלת שגיאה ולא אזהרה. הבקשה מצליחה ושני המונים מציגים 0. נכון לאוקטובר 2026, ערכי המינימום המפורסמים הם:

• 512 טוקנים ב-Claude Opus 5 וב-Claude Fable 5, וכן בגרסאות החדשות יותר Opus 5.5, Sonnet 5.5, Fable 5.1 ו-Haiku 5.5
• 1,024 טוקנים ב-Claude Sonnet 5 וב-Claude Opus 4.8
• 4,096 טוקנים ב-Claude Haiku 4.5

אם שני המונים מציגים 0 בבקשה שאתם סבורים כי היא אמורה להיות ב-cache, בדקו את אורך התחילית לפני כל דבר אחר. זו גם הסיבה שהמודל הזול ביותר אינו בהכרח הזול ביותר עבור עומס עבודה המבוסס על caching. המודל Haiku 4.5 דורש תחילית ארוכה פי שמונה מזו של Opus 5 כדי שה-caching יופעל בכלל; לכן, prompt מערכת באורך 2,000 טוקנים יישמר ב-cache במודל אחד ויתעלמו ממנו בשקט במודל השני.

היכן Claude Code מבצע מטמון עבורכם, והיכן הוא אינו יכול

Claude Code מבצע מטמון לקידומת (prefix) שלו. ה-system prompt והגדרות הכלים נמצאים בתחילת כל בקשה ואינם משתנים, לכן הם נכתבים פעם אחת ונקראים שוב ושוב לאורך כל הסשן. זו הסיבה שהעלות לכל תור (turn) בסשן ארוך נמוכה בהרבה ממה שגודל ההקשר (context) מרמז, והדבר בא לידי ביטוי במונים המתוארים ב-כיצד Claude Code מדווח על שימוש ב-tokens.

היכן הוא אינו יכול לסייע לכם הוא בשינוי שמתבצע קרוב לתחילת ההקשר. היסטוריית השיחה היא מסוג "הוספה בלבד" (append-only), ולכן תורות חדשים רגילים מרחיבים קידומת שכבר נמצאת במטמון. עריכת קובץ שנקרא מוקדם יותר בסשן אינה פוגעת בכך, כיוון ש-Claude Code מוסיף הערה על כך שהקובץ השתנה במקום לשכתב את הקריאה המוקדמת. מה שכן פוגע בכך הוא החלפת מודלים, כיוון שלכל מודל יש מטמון משלו. חיבור שרת MCP שהכלים שלו נטענים לתוך הקידומת פוגע בכך גם הוא, וכך גם דחיסת השיחה. כל אחד מאלה גורם לתור הבא לכתוב את הקידומת מחדש. פער זמן ממושך ללא פעילות גורם לאותה תוצאה, כיוון שהרשומה פגה והתור הבא מחייב כתיבה מלאה. אף אחד מאלה אינו באג. אלו הם כללי הקידומת המבצעים בדיוק את מה שהם אמורים לבצע.

אם אתם כותבים לקוח משלכם, החילו את המבנה מהבקשה הראשונה במקום לבצע התאמות בדיעבד: בנו את הקריאה כפי שמתואר ב-אפליקציית Claude API ראשונה על גבי VPS, כאשר הבלוקים היציבים מופיעים ראשונים והבלוקים המשתנים מופיעים אחרונים.

מצבי כשל, ומה תראה

כל קריאה היא פעולת כתיבה. cache_creation_input_tokens אינו אפס בכל בקשה, בעוד cache_read_input_tokens נשאר 0. משהו בנקודת העצירה או לפניה משתנה בין קריאות. הדפס את 200 התווים הראשונים של הקידומת המורכבת שלך בשתי בקשות עוקבות והשווה ביניהם בעין.

שני המונים הם 0. הקידומת קטנה מהמינימום של המודל, או שהשדה cache_control מעולם לא הגיע ל-API. ספור תחילה את הטוקנים של הקידומת, ולאחר מכן רשום בלוג את גוף הבקשה ששלחת בפועל.

קריאות עובדות, ואז נעצרות. רצף של פגיעות (hits), לאחר מכן כתיבה, ושוב פגיעות. המרווח בין הבקשות היה ארוך יותר מזמן החיים (lifetime). קבל את הכתיבה, או עבור ל-TTL של שעה אחת לאחר שווידאת ששיעור הפגיעות שלך עולה על 53 אחוז, או כ-51 אחוז במודל עם קריאה של 0.05x או 0.025x.

שיעור הפגיעות יורד לאחר פריסה (deploy). תיאור כלי נערך או שמודל הוחלף. שניהם מבטלים את כל הקידומת. צפה לסבב כתיבות יקר אחד לאחר כל פריסה שנוגעת ב-prompt.

החשבון עלה לאחר שהפעלת שמירה במטמון (caching). שיעור הפגיעות שלך נמוך מנקודת האיזון. מתחת ל-22 אחוז בערך במטמון של 5 דקות, שליחת הקידומת ללא מטמון זולה יותר, ומתחת ל-53 אחוז בערך, כך גם במטמון של שעה אחת. במודלים עם קריאה זולה יותר, קווים אלו נמצאים בערך ב-20 עד 21 אחוז וב-51 אחוז.

FAQ

כמה פעמים יש לעשות שימוש חוזר ב-prompt כדי שה-caching יהיה כדאי?

פעם אחת, ב-cache של 5 דקות. כתיבה עולה פי 1.25 מקלט בסיסי וקריאה עולה פי 0.1 ברוב המודלים, לכן N בקשות ללא cache עולות N, בעוד N בקשות עם cache עולות 1.25 ועוד 0.1 כפול N פחות 1. נקודת המפגש היא ב-N = 1.28, כך שהבקשה השנייה כבר משתלמת. במודלים עם עלות קריאה של 0.05x או 0.025x, נקודת המפגש היא N = 1.26, מה שמוביל לאותה מסקנה. ה-cache של שעה כותב בעלות של 2x וחוצה את נקודת הכדאיות ב-N = 2.11, או בערך 2.05 בקריאות זולות יותר, לכן הוא דורש שתי קריאות.

מדוע הערך של cache_read_input_tokens הוא תמיד אפס?

בדקו תחילה את אורך ה-prefix: מתחת למינימום של המודל, 512 טוקנים ב-Claude Opus 5 ו-4,096 ב-Claude Haiku 4.5 נכון לאוקטובר 2026, ה-caching מדלג בשקט ושני המונים מציגים 0. אם ה-prefix ארוך מספיק, חפשו תוכן שמשתנה בין קריאות שנמצא בנקודת השבירה או לפניה, כגון חותמת זמן או מזהה סשן ב-system prompt. אם המונים עבדו והפסיקו, המרווח בין הבקשות היה ארוך יותר מאורך החיים של ה-cache.

האם prompt caching משנה את התשובות של Claude?

לא. ה-cache מאחסן את הצורה המעובדת של טוקנים שכבר שלחת, והמודל רואה את אותו ה-prompt בכל מקרה. מדובר בתכונה של חיוב וזמן תגובה (latency), לא בשינוי התנהגות. המשמעות היא שניתן להפעיל זאת על prompt תקין מבלי להריץ מחדש את ה-evaluations שלכם.

האם כדאי לשלם על ה-cache של שעה?

רק כאשר בתעבורה שלכם יש מרווחים ארוכים מ-5 דקות ושיעור ה-hit שלכם עדיין יעבור בערך 53 אחוזים, או כ-51 אחוזים במודל עם קריאה זולה יותר. במקרה של miss, הכתיבה של 2x עולה פי ארבעה מאשר הכתיבה של 1.25x. כתיבה שנכשלה ב-cache של שעה מבזבזת את מלוא מחיר הקלט הבסיסי של ה-prefix, בעוד כתיבה שנכשלה ב-cache של 5 דקות מבזבזת רק רבע ממנו. כניסה ל-cache של 5 דקות מתרעננת בכל hit, כך שתעבורה קבועה שומרת עליו פעיל במחירי קריאה מבלי לשלם על אורך חיים ארוך יותר.