Prompt Caching -
90% פחות עלות.

סימון, שמירה, אחזור.

• סימון. אתם מסמנים בפנייה איזה חלק יציב (system prompt, מסמכים) עם cache_control.
• שמירה. בפנייה הראשונה אנתרופיק שומרת את התוכן המסומן במטמון לזמן מוגדר.
• אחזור. בפניות הבאות שמשתמשות באותו תוכן, המטמון נטען - והעלות יורדת ב-90%.

מחיר הקלט המקורי לעומת מטמון.

כתיבת המטמון בפעם הראשונה עולה קצת יותר (1.25 דולר / מיליון) - אבל מהפנייה השנייה זה כבר חיסכון נטו.

שורת קוד אחת.

סוג ephemeral שומר את המטמון ל-5 דקות. אם הפנייה הבאה תגיע בתוך 5 דקות, מנצלים.

ארבעה מקומות שמתאימים.

• system prompt - הוראות יציבות שמשמשות כל פנייה
• tool definitions - תיאורי כלים שלא משתנים
• מסמכי הקשר - PDF, מדריך, טבלת נתונים שמצורפת לכל פנייה
• היסטוריית שיחה - בשיחה ארוכה, החלקים הראשונים יציבים. שווה לסמן.

1,024 או 2,048 - תלוי במודל.

caching עובד רק על תכנים בגודל מינימלי - 1,024 טוקנים ב-Haiku, 2,048 ב-Sonnet ו-Opus. תוכן קצר יותר לא נשמר במטמון - העלות לא מצדיקה.

דוגמה מספרית.

אפליקציה עם system prompt של 3,000 טוקנים, 1,000 פניות ביום, Sonnet:

• בלי caching: 3,000 × 1,000 × 3 דולר ÷ 1,000,000 = 9 דולר ביום
• עם caching (כתיבה ראשונית): 3,000 × 1.25 ÷ 1,000,000 = 0.004 דולר
• עם caching (999 פניות אחרות): 3,000 × 999 × 0.30 ÷ 1,000,000 = 0.90 דולר ביום

חיסכון של 8 דולר ביום, או 240 דולר בחודש - על שינוי שלוקח 30 שניות לפתח.

שלוש סיטואציות שבהן caching לא יעזור.

• תוכן שמשתנה כל פנייה. אם ה-system prompt מותאם אישית למשתמש, אין מטמון לחזור אליו.
• תוכן קצר מהמינימום. 500 טוקנים? לא יישמר. אין משמעות לסמן.
• פניות נדירות. אם בין פנייה לפנייה עוברת שעה, המטמון פג והעלות עולה.

טעויות יקרות בעבודה עם caching.

• לסמן תוכן שמשתנה. כל פעם שמשתנה תו אחד, המטמון נופל. כסף לחינם.
• לסמן את כל הפנייה. מסמנים רק את החלק היציב, לא הקלט החדש.
• להסתמך בלי לוודא. המטמון לא תמיד נטען. בכל פנייה - בדקו ב-response את cache_read_input_tokens.

caching זאת התחלה.
יש עוד דרכים להוזיל עלויות.

ClaudeLearn · סוף מודול 30 · חזרה לקטלוג