סוכן שמייצר תוכן עם Claude - למה בלי Prompt Caching זה יקר פי 5

עסק שמפעיל סוכן AI שמייצר 50 פוסטים לרשתות חברתיות בשבוע, ומגלה שהחשבון החודשי גבוה משמעותית ממה שציפה, לרוב לא נתקל בבעיה של "המודל יקר" - הוא נתקל בבעיה של לשלוח את אותו מדריך קול מותג בן 2,000 מילים בכל קריאה בודדת, במחיר קלט מלא, גם כשהטקסט הזה לא השתנה בין קריאה לקריאה.

הבעיה: הקשר קבוע שמשלמים עליו שוב ושוב

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

הפתרון: cache_control על ההקשר הקבוע

const response = await client.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 2048,
  system: [
    {
      type: "text",
      text: brandStyleGuide, // אלפי מילים - קבוע בין קריאות
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [{ role: "user", content: `כתוב פוסט על: ${topic}` }],
});

לפי Anthropic, כתיבה למטמון (cache write) עולה 1.25x ממחיר הקלט הרגיל בזיכרון ל-5 דקות, אבל קריאה חוזרת מהמטמון (cache read) עולה רק 0.1x מהמחיר הרגיל - כלומר אם אותו הקשר משמש שוב תוך 5 דקות, החיסכון על אותו חלק קבוע מתקרב ל-90%. עבור סוכן שמייצר תוכן ברצף (50 פוסטים באותה הרצה), כמעט כל קריאה אחרי הראשונה נהנית מהמחיר הזול.

איפה שמים את ה-breakpoint

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

איפה זה נשבר: עקביות לא מובטחת אוטומטית

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

מקרה קצה: תוכן בכמה שפות במקביל

סוכן שמייצר תוכן גם בעברית וגם באנגלית מאותו מדריך מותג לא יכול לחלוק את אותו breakpoint למטמון בפשטות - אם ההנחיות הספציפיות לשפה (טון, מוסכמות כתיב) שונות בין השתיים, שווה לבנות שני system prompts נפרדים עם cache_control משלהם, במקום לנסות לדחוס את שתי השפות למסמך אחד עם תנאי "אם עברית אז X, אם אנגלית אז Y" - זה לא רק מבלבל את המודל, זה גם מכפיל את גודל ההקשר הקבוע שצריך caching מלכתחילה.

דוגמה מספרית: 50 פוסטים בשבוע

נניח מדריך סגנון של 5,000 טוקן, ו-50 פוסטים בשבוע שכל אחד מוסיף כ-500 טוקן פלט. בלי caching: 50 קריאות כפול 5,000 טוקן קלט במחיר מלא של Sonnet 5 (2 דולר למיליון) - כ-0.50 דולר בשבוע רק על ההקשר החוזר, לפני הפלט. עם caching: קריאה ראשונה יוצרת מטמון במחיר 1.25x (כ-0.0125 דולר), וכל 49 הקריאות הנותרות (בהנחה שהן רצות בתוך חלון הרענון) קוראות מהמטמון במחיר 0.1x - כ-0.049 דולר בסך הכל על ההקשר החוזר. ההבדל נראה קטן במספרים אבסולוטיים בסקאלה הזו, אבל הוא גדל ליניארית עם נפח - סוכן שמייצר אלפי פריטי תוכן בחודש מרגיש את ההבדל בבירור בחשבון.

מתי caching לא עוזר

חשוב לזהות מתי caching פשוט לא רלוונטי: אם הסוכן מייצר תוכן פעם ביום או פחות, החלון של 5 דקות של המטמון הבסיסי כבר פג בין קריאה לקריאה, וכל קריאה נכנסת כחדשה. עבור קצב נמוך כזה, יש אופציה של מטמון עם TTL ארוך יותר - שעה במקום 5 דקות - אבל היא עולה יותר לכתיבה (2x במקום 1.25x), ומשתלמת רק אם יש לפחות שתי קריאות בתוך אותה שעה. אם הקצב נמוך מזה, caching פשוט לא פותר בעיה שקיימת, וההוצאה העיקרית היא ממילא הפלט עצמו, לא ההקשר הקבוע.

מה לנסות עכשיו

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