מפתחים גילו ש-prompt-caching של Claude יכול להיכשל בשקט, תוך חיוב בתעריפי פרימיום למרות החזרת אפס טוקנים מהמטמון (cached tokens). הרצת לוג שנמשכה שבוע על WhatsApp handler הראתה שכלל לא בוצעו קריאות מהמטמון, ובכל זאת ה-API חייב על תכונת ה-caching — מה שהוריד את העלויות מ-$1,890 ל-$406 לחודש.

למה הבעיה הזו חשובה

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

איך הבאג בא לידי ביטוי

ה-API מקבל דגל cache-control ו-prefix, ולאחר מכן מדווח כמה טוקנים נקראו מהמטמון. במקרה שנצפה, כל בקשה החזירה ספירת קריאות מהמטמון של אפס. הקריאה הצליחה, לא נזרקה שגיאה (exception), והחיוב שיקף את עלות הפרימיום של המטמון. הכישלון אינו נראה לעין אלא אם כן מתעדים (log) במפורש את ספירת הקריאות.

דרכים נפוצות שבהן המטמון נשבר

  • ה-Prefix קצר מדי – כל מודל Claude מגדיר אורך טוקנים מינימלי עבור prefix הניתן לאחסון במטמון. Haiku 4.5 דורש לפחות 4,096 טוקנים; Sonnet 4.6 דורש רק 1,024. שליחת prefix קצר יותר תענה על פורמט הבקשה, אך השירות יתעלם מהוראת ה-cache.
  • בייט משתנה (volatile byte) זז – אחסון במטמון דורש התאמה מדויקת בייט-אחרי-בייט. הוספת אלמנט דינמי כמו timestamp, new Date(), או אימייל של משתמש לתחילת ה-system prompt משנה את רצף הבייטים, וגורמת לכך שכל בקשה תטופל ככתיבה חדשה ללא מטמון.
  • שינוי בסדר רשימת הכלים (tool list) – הכלים (tools) מתווספים לתחילת הפרומפט. אם מערך הכלים (tool array) נבנה מתוך מפתחות של אובייקטים (object keys), סדר האיטרציה יכול להשתנות בין קריאות, מה שמשנה את מבנה הבייטים ושובר את המטמון.

תיקונים שניתן ליישם כבר היום

  • אימות אורך ה-prefix – לפני שליחת בקשה, הערך את מספר הטוקנים ב-prefix אל מול המינימום של המודל. דחה או השלם (pad) את ה-prefix אם הוא קצר מדי.
  • תעד (Log) קריאות מטמון בכל קריאה – רשום את השדה "cache read tokens". רצף של אפסים הוא סימן ברור לכך שהמטמון אינו מנוצל.
  • הקפאת הבייטים המובילים של הפרומפט – שמור על נתונים דינמיים מחוץ לחלק המאוחסן במטמון. אם עליך לכלול מידע ספציפי למשתמש, מקם אותו אחרי ה-prefix המאוחסן.
  • סנכרון מזהי מודלים (model identifiers) – ודא שמזהה המודל (model ID) המשמש בניתוב (routing) תואם למזהה השמור בטבלת המטמון שלך; מזהים שאינם תואמים מונעים ביצוע חיפוש במטמון.

היבט העלויות

עבור אפליקציה שמבצעת אלפי קריאות מדי יום, מעבר משימוש ללא מטמון לשימוש עם מטמון יכול להוריד את ההוצאות החודשיות באופן דרמטי — מ-$1,890 בערך ל-$406 במקרה שדווח. גם תעבורה מתונה תראה חיסכון ניכר, והשיפור בביצועים הנובע משימוש חוזר בפרומפט סטטי גדול יכול להפחית את ה-latency.

נקודת מבט נגדית

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

מה כדאי לעקוב אחריו בהמשך

  • לוחות בקרה של מדדים (metric dashboards) – הוסף מדד (gauge) לטוקנים שנקראו מהמטמון לצד נפח הבקשות.
  • יציבות סדר הכלים (tool-ordering stability) – אם אתם מסתמכים על רשימות כלים שנוצרות באופן דינמי, שקלו למיין אותן באופן דטרמיניסטי לפני הטמעתן בפרומפט.

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