מתי Claude prompt caching מתחיל לחסוך?

מה עולה שמירת מטמון של prompt לפני שהיא חוסכת

שמירת prompt במטמון מאפשרת ל־Claude להשתמש מחדש בתחילת ה־prompt, במקום לקרוא אותה שוב בכל קריאה. כל ההחלטה תלויה בשני מכפילים של מחיר קלט הבסיס של המודל. נכון ל־August 2026, כתיבה למטמון עולה 1.25x ממחיר קלט הבסיס למשך lifetime של 5 דקות, או 2x למשך lifetime של 1 שעה. קריאה מהמטמון עולה 0.1x. המכפילים האלה זהים בכל רשימת המודלים, ולכן נקודת האיזון שלהלן אינה משתנה כאשר המחיר לכל טוקן משתנה.

העסקה היא תוספת תשלום עכשיו תמורת הנחה בהמשך. משלמים פעם אחת יותר כדי לשמור prefix. כל בקשה מאוחרת יותר שמתחילה בדיוק באותם bytes משלמת עבור החלק הזה עשירית ממחיר הקלט הרגיל. prefix שלא נעשה בו שימוש חוזר במהלך ה־lifetime שלו יעלה לכם 25 אחוזים נוספים ללא תמורה.

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

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

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

התרשים שלהלן מציג את העלות עבור קידומת בת 20,000 טוקנים ב־Claude Opus 5, שמחיר קלט הבסיס שלו הוא $5 למיליון טוקנים נכון לאוגוסט 2026. יש להכפיל כל נתון ב־0.6 עבור מודל שמחירו $3 למיליון. צורת העקומה אינה משתנה.

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

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

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

בקשות אמיתיות אינן תמיד נמצאות במטמון. בקשה שאינה נמצאת במטמון אך עדיין כוללת breakpoint מחויבת ככתיבה, ולכן הדרך המדויקת למדל זאת היא להציג את העלות כפונקציה של שיעור הפגיעות. התרשים שלהלן עושה זאת עבור 1,000 בקשות, שכל אחת מהן כוללת prefix זהה באורך 20,000 tokens.

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

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

אילו קידומות מצדיקות נקודת cache

בקשה יכולה לכלול עד ארבע נקודות cache, ולכן השאלה היא אילו בלוקים מצדיקים נקודה כזו. המועמדים הם בלוקים שזהים ברמת הבתים בין קריאות, וגדולים מספיק כדי להשפיע. התרשים שלהלן מציג את העלות של ארבע תבניות נפוצות לאורך 1,000 בקשות, בשיעור פגיעה של 90 אחוז ב־cache של 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 tokens חוסך $7.85 לכל 1,000 בקשות, לעומת $10.00 ללא cache. בסדר גודל גדול מדובר בחיסכון ממשי, אך זה עדיין לא הגורם שהופך caching למעניין. הוספת הגדרות הכלים מביאה אתכם ל־8,000 tokens ולחיסכון של $31.40. מסמך מדיניות באורך 25,000 tokens, שכל בקשה מפנה אליו בשאלות, חוסך $98.12. השורה האחרונה היא זו שמשנה את הארכיטקטורה: הקשר באורך 120,000 tokens, שמכיל codebase או תמלול, עולה $600.00 ללא cache ו־$129.00 עם cache — חיסכון של $471.00.

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

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

התרשים שלהלן לוקח את קידומת האסימונים באורך 8,000 מהסעיף הקודם, יחד עם system prompt והגדרות כלים, בשיעור פגיעה של 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. במיליון בקשות, עלות קלט ללא caching היא $40,000.00, ו־caching חוסך $31,400.00 מסכום זה. מדובר באסימוני קלט בלבד. הפלט מחויב בנפרד, ו־caching אינו משפיע עליו. חשוב לזכור זאת לפני שמבטיחים למישהו קיצוץ של 90 אחוז בחשבון. Caching הוא חלק ממכלול השיטות הרחב יותר של שליטה בעלויות של סוכן AI ב־VPS.

כיצד להוכיח שהמטמון פועל

אל תסתמכו על התכנון. קראו את בלוק נתוני השימוש בתגובה. כל תשובה של 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. בקריאה השנייה התוצאה תתהפך, משום שהקידומת נמצאה במטמון. input_tokens סופר רק את האסימונים שאחרי נקודת הביקורת האחרונה, ולכן בקריאה השנייה, כאשר הכול פועל כראוי, ערכו קטן ובדרך כלל כולל רק את הודעת המשתמש החדשה.

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

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

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

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

כלל הסדר שפוגע בשיעורי הפגיעה במטמון

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

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

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

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

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

הקידומת המינימלית, והפעולה השקטה שאינה עושה דבר

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

• 512 אסימונים ב־Claude Opus 5 וב־Claude Fable 5
• 1,024 אסימונים ב־Claude Sonnet 5 וב־Claude Opus 4.8
• 4,096 אסימונים ב־Claude Haiku 4.5

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

היכן Claude Code שומר מטמון עבורך, והיכן הוא אינו יכול לעזור

Claude Code שומר במטמון את הקידומת שלו. הנחיית המערכת והגדרות הכלים נמצאות בתחילת כל בקשה ואינן משתנות, ולכן הן נכתבות פעם אחת ונקראות מחדש לאורך שאר הסשן. משום כך, העלות בכל תור בסשן ארוך נמוכה בהרבה מכפי שגודל ההקשר עשוי לרמז, והיא מופיעה במונים המתוארים ב־האופן שבו Claude Code מדווח על שימוש באסימונים.

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

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

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

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

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

הקריאות עובדות ואז נפסקות. מתקבלת סדרה של התאמות, לאחריה כתיבה, ולאחר מכן שוב התאמות. המרווח בין הבקשות היה ארוך יותר ממשך החיים של המטמון. קבלו את הכתיבה, או עברו ל־TTL של 1 שעה לאחר שבדקתם ששיעור ההתאמות שלכם עובר 53 אחוזים.

שיעור ההתאמות יורד לאחר פריסה. תיאור של כלי נערך או שהמודל השתנה. שני השינויים האלה מבטלים את הקידומת כולה. צפו לסבב יקר אחד של כתיבות לאחר כל פריסה שמשנה את ה־prompt.

החיוב עלה לאחר שהפעלתם caching. שיעור ההתאמות שלכם נמוך מנקודת האיזון. בשיעור הנמוך מכ־22 אחוזים במטמון של 5 דקות, שליחת הקידומת ללא מטמון זולה יותר; ובשיעור הנמוך מכ־53 אחוזים, הדבר נכון גם במטמון של 1 שעה.

FAQ

כמה פעמים יש לעשות שימוש חוזר בפרומפט לפני שהמטמון מתחיל להשתלם?

פעם אחת, במטמון של 5 דקות. כתיבה עולה פי 1.25 ממחיר קלט בסיסי, וקריאה עולה פי 0.1. לכן N בקשות ללא מטמון עולות N, ואילו N בקשות עם מטמון עולות 1.25 ועוד 0.1 כפול N פחות 1. שתי העלויות משתוות ב־N = 1.28, ולכן כבר הבקשה השנייה משתלמת יותר. כתיבה למטמון של שעה עולה פי 2, ונקודת האיזון היא N = 2.11, ולכן נדרשות שתי קריאות.

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

בדקו תחילה את אורך הקידומת: מתחת לאורך המינימלי של המודל — 512 טוקנים ב־Claude Opus 5 ו־4,096 ב־Claude Haiku 4.5, נכון ל־August 2026 — הדחיפה למטמון מדולגת בשקט, ושני המונים מציגים 0. אם הקידומת ארוכה מספיק, חפשו תוכן שמשתנה בין הקריאות ומופיע בנקודת החיתוך או לפניה, כגון חותמת זמן או מזהה session בפרומפט המערכת. אם המונים פעלו ואז הפסיקו, הפער בין הבקשות היה ארוך מזמן החיים של המטמון.

האם caching של פרומפטים משנה את התשובות של Claude?

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

האם כדאי לשלם עבור המטמון של שעה?

רק כאשר יש בתעבורה שלכם פערים שאורכם עולה על 5 דקות, ושיעור הפגיעות במטמון עדיין צפוי לעבור בערך 53 אחוזים. הכתיבה בעלות פי 2 מכפילה את החיסרון לעומת כתיבה בעלות פי 1.25 כאשר אין פגיעה במטמון. רשומה במטמון של 5 דקות מתרעננת בכל פגיעה, ולכן תעבורה רציפה משאירה אותה פעילה במחיר של קריאות, בלי לשלם אי פעם עבור זמן החיים הארוך יותר.