מאת חישוב נקודת האיזון ב-Claude Prompt Caching
עלויות הכתיבה ב-Prompt Caching הן פי 1.25 והקריאה פי 0.1 ממחיר הקלט הבסיסי. גלו כיצד לחשב את נקודת האיזון המדויקת שבה השימוש במטמון הופך למשתלם כלכלית עבור ה-API שלכם.
עלויות ה-Prompt Caching לפני החיסכון
ה-Prompt Caching מאפשר ל-Claude לעשות שימוש חוזר בחלקו הקדמי של ה-prompt במקום לקרוא אותו מחדש בכל קריאה, וההחלטה כולה מסתכמת בשני מכפילים על מחיר הקלט הבסיסי של המודל. נכון לאוגוסט 2026, כתיבה למטמון עולה פי 1.25 ממחיר הקלט הבסיסי עבור זמן חיים של 5 דקות, או פי 2 עבור זמן חיים של שעה אחת. קריאה מהמטמון עולה פי 0.1. מכפילים אלו תקפים לכל רשימת המודלים, כך שנקודת האיזון המפורטת להלן אינה משתנה כאשר מחיר ל-token משתנה.
העסקה היא תוספת תשלום כעת כנגד הנחה מאוחרת יותר. אתם משלמים תוספת פעם אחת כדי לאחסן תחילית (prefix). כל בקשה עוקבת שמתחילה בדיוק באותם בתים משלמת לאחר מכן עשירית ממחיר הקלט הרגיל עבור אותו חלק. תחילית שלעולם לא נעשה בה שימוש חוזר בתוך זמן החיים שלה עלתה לכם 25 אחוזים נוספים ללא תמורה.
נקודת האיזון, באלגברה בשורה אחת
נסמן ב-B את עלות הקלט הבסיסית של ה-prefix אילו נשלח ללא caching. ללא caching, עלות של N בקשות היא N כפול B. עם cache של 5 דקות, הבקשה הראשונה כותבת את ה-prefix בעלות של 1.25B, ושאר N פחות 1 הבקשות קוראות אותו בעלות של 0.1B. נשווה בין השתיים ונקבל 0.9N = 1.15, כלומר N = 1.28. כבר בבקשה השנייה העלות נמוכה יותר מאשר ללא caching כלל.
נחזור על החישוב עם עלות כתיבה כפולה (2x) של ה-cache ל-שעה אחת, ונקבל 0.9N = 1.9, כלומר N = 2.11. ה-cache הארוך דורש שתי קריאות לפני שהוא מגיע לנקודת האיזון, וזו הסיבה שהוא אינו ברירת המחדל.
התרשים להלן מתמחר זאת עבור prefix של 20,000 טוקנים ב-Claude Opus 5, שעלות הקלט הבסיסית שלו היא $5 למיליון טוקנים נכון לאוגוסט 2026. יש להכפיל כל נתון ב-0.6 עבור מודל של $3 למיליון. צורת העקומה אינה משתנה.
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 ללא caching ו-$0.125 עם caching, לכן שימוש ב-caching עבור 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) רק כאשר יש בתעבורה שלכם הפסקות של ממש.
העלות של שיעור פגיעה נמוך
תעבורה אמיתית מייצרת החטאות (misses). בקשה שמחטיאה את ה-cache אך עדיין נושאת breakpoint מחויבת ככתיבה, לכן הדרך הנכונה למדל זאת היא כעלות כפונקציה של שיעור הפגיעה (hit rate). התרשים להלן מציג זאת עבור 1,000 בקשות, כאשר כל אחת נושאת prefix זהה של 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 אחוזים אתם משלמים $125.00 במקום $100.00, ו-cache של שעה אחת מכפיל את החשבון ל-$200.00. פתרון המשוואה 1.25 פחות 1.15h שווה 1 מראה ש-cache של 5 דקות מתחיל לחסוך כסף בשיעור פגיעה של כ-22 אחוזים, וזו הסיבה ש-25 אחוזים כבר מציגים $96.25. אותו חישוב עבור כתיבה כפולה (2x) מניב כ-53 אחוזים עבור cache של שעה, כך ששיעור פגיעה של 50 אחוזים עדיין עולה $105.00, מעל לקו של ללא-cache. ב-90 אחוזים השניים מגיעים ל-$21.50 ו-$29.00. ב-99 אחוזים ה-cache הקצר מגיע ל-$11.15, קרוב לרצפת מחיר של עשירית מהמחיר ללא-cache.
שיעור הפגיעה הוא המדד שיש לנטר, כיוון שהוא הקלט היחיד שאתם שולטים בו לאחר שגודל ה-prefix נקבע.
אילו תחיליות (prefixes) מצדיקות נקודת עצירה (breakpoint)
בקשה עשויה לשאת עד ארבע נקודות עצירה של מטמון (cache breakpoints), לכן השאלה היא אילו בלוקים ראויים לכך. המועמדים הם בלוקים שזהים בבתים (byte-identical) בין קריאות ושגודלם משמעותי מספיק. הטבלה להלן מתמחרת ארבע צורות נפוצות לאורך 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"
}
]מערכת הנחיה (system prompt) בסיסית של 2,000 טוקנים חוסכת $7.85 לכל 1,000 בקשות לעומת $10.00 ללא מטמון. מדובר בכסף אמיתי בנפחים גדולים, אך לא זה מה שהופך את השימוש במטמון למעניין. הוסיפו את הגדרות הכלים (tool definitions) ותגיעו ל-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 אחוז, ומבצע אקסטרפולציה לנפחי בקשות חודשיים.
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. נתונים אלו מתייחסים ל-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
ה-cache מבצע התאמה של ה-prefix בייט אחר בייט מתחילת הבקשה, והבקשה מורכבת בסדר קבוע: כלים (tools), לאחר מכן מערכת (system), ולבסוף הודעות (messages). שינוי בכל רמה מבטל את הרמה הזו ואת כל מה שבא אחריה. עריכה של תיאור כלי אחד מבטלת את ה-system prompt ואת כל היסטוריית ההודעות, גם אם לא נגעת בהם.
מכאן נובע כלל אחד ללא יוצא מן הכלל: כל דבר שמשתנה בין קריאות חייב להופיע אחרי כל מה שאינו משתנה.
הגורם השכיח ביותר הוא חותמת זמן. שורה המכילה Current time: 2026-08-03T14:07:11Z בראש ה-system prompt מבטיחה שיעור hit rate של 0 אחוזים, כיוון שה-hash של ה-prefix שונה בכל קריאה, ושום רשומה קודמת לא תוכל להתאים לו. העבירו אותה להודעת המשתמש, לסופה. מזהה סשן או nonce לכל בקשה גורמים לאותה בעיה ודורשים את אותו פתרון. מסמכים שנשלפו ומשתנים בין בקשות צריכים גם הם להופיע אחרי הבלוק המוצפן (cached block), אחרת הם דוחפים כל token יציב אל מעבר לגבול שמשתנה ללא הרף.
הגורם השני הוא הצבת ה-breakpoint על הבלוק שמשתנה. כתיבה ל-cache מתבצעת ב-breakpoint, לכן אם הבלוק הזה שונה בכל פעם, שום דבר יציב לא נשמר, והחיפוש לאחור מוצא רק רשומות שבקשות קודמות כתבו ב-breakpoints המשתנים שלהן. הציבו את cache_control על הבלוק האחרון שהתוכן שלו זהה בכל הבקשות.
הגורם השלישי הוא שינוי פרמטר שלא נתפס כתוכן של ה-prompt. מודל שונה משתמש ב-cache שונה. שינוי בבחירת הכלים מבטל את ה-cache מרמת ה-system והלאה. הוספה או הסרה של כלי מבטלת את הכל.
התחילית המינימלית, והפעולה השקטה שלא מתבצעת
תחילית הקצרה מהמינימום הנדרש על ידי המודל אינה נשמרת ב־cache, ואין כל חיווי על כך. לא מתקבלת שגיאה, ואין אזהרה. הבקשה מצליחה ושני המונים מציגים 0. נכון לאוגוסט 2026, ערכי המינימום המפורסמים הם:
- 512 אסימונים (tokens) ב-Claude Opus 5 וב-Claude Fable 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 על ניצול טוקנים.
היכן הוא אינו יכול לסייע לכם הוא בעריכה המתרחשת קרוב לתחילת ה-context. היסטוריית השיחה היא מסוג append-only, לכן תורות חדשים רגילים מאריכים קידומת שכבר נמצאת במטמון. עריכת קובץ שנקרא בתחילת הסשן משנה תוכן באמצע אותה קידומת, וכל טוקן שאחרי השינוי חייב להיכתב מחדש. פער זמן ממושך ללא פעילות גורם לאותה תוצאה, כיוון שהרשומה פגה והתור הבא מחייב כתיבה מלאה. אף אחד מאלו אינו באג. שניהם הם כלל הקידומת המבצע בדיוק את מה שהוא אמור לבצע.
אם אתם כותבים לקוח משלכם, החילו את המבנה מהבקשה הראשונה במקום לבצע התאמות בדיעבד: בנו את הקריאה כפי שמתואר ב-אפליקציית Claude API ראשונה על גבי VPS, כאשר הבלוקים היציבים מופיעים ראשונים והבלוקים המשתנים אחרונים.
אופני כשל, ומה תראו
כל קריאה היא כתיבה. cache_creation_input_tokens אינו אפס בכל בקשה, בעוד cache_read_input_tokens נשאר 0. משהו בנקודת העצירה או לפניה משתנה בין קריאות. הדפיסו את 200 התווים הראשונים של הקידומת המורכבת שלכם בשתי בקשות עוקבות והשוו ביניהם בעין.
שני המונים הם 0. הקידומת קטנה מהמינימום של המודל, או שהשדה cache_control מעולם לא הגיע ל-API. ספרו תחילה את אסימוני הקידומת, ולאחר מכן תעדו בלוג את גוף הבקשה ששלחתם בפועל.
קריאות עובדות, ואז נעצרות. רצף של פגיעות (hits), לאחר מכן כתיבה, ושוב פגיעות. המרווח בין הבקשות היה ארוך יותר מזמן החיים (lifetime). קבלו את הכתיבה, או עברו ל-TTL של שעה אחת לאחר שווידאתם ששיעור הפגיעות שלכם עובר את ה-53 אחוזים.
שיעור הפגיעות יורד לאחר פריסה (deploy). תיאור כלי נערך או שמודל הוחלף. שניהם מבטלים את כל הקידומת. צפו לסבב כתיבות יקר אחד לאחר כל פריסה שנוגעת ב-prompt.
החשבון עלה לאחר שהפעלתם את ה-caching. שיעור הפגיעות שלכם נמוך מנקודת האיזון. מתחת ל-22 אחוזים בערך ב-cache של 5 דקות, שליחת הקידומת ללא cache זולה יותר, ומתחת ל-53 אחוזים בערך, כך גם לגבי ה-cache של שעה אחת.
FAQ
כמה פעמים יש לעשות שימוש חוזר ב-prompt כדי שה-caching יהיה כדאי?
פעם אחת, עבור ה-cache של 5 דקות. כתיבה עולה פי 1.25 מקלט בסיסי וקריאה עולה פי 0.1, לכן N בקשות ללא cache עולות N, בעוד ש-N בקשות עם cache עולות 1.25 ועוד 0.1 כפול N פחות 1. נקודת המפגש היא ב-N = 1.28, כך שהבקשה השנייה כבר חסכונית יותר. ה-cache של שעה כותב בפי 2 ונקודת המפגש היא ב-N = 2.11, לכן הוא דורש שתי קריאות.
מדוע הערך של 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 rate שלכם עדיין יגיע לכ-53 אחוזים. הכתיבה בפי 2 היא חיסרון כפול לעומת כתיבה בפי 1.25 במקרה של miss. כניסה של 5 דקות מתרעננת בכל hit, כך שתעבורה יציבה שומרת עליו פעיל במחירי קריאה מבלי לשלם אי פעם על אורך חיים ארוך יותר.