📘 תיעוד 7

איך Claude Code משתמש במטמון פרומפטים

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

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

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

#איך המטמון מאורגן

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

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

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

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

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

שתי הגדרות לא מופיעות בטבלת השכבות אבל עדיין משפיעות על מה שנשאר במטמון:

• מודל: לכל מודל יש מטמון משלו. החלפת מודלים מחשבת מחדש את כל הבקשה גם כשהתוכן זהה. ראה החלפת מודלים למטה.
• רמת מאמץ: ברוב המודלים, לכל רמת מאמץ יש מטמון משלה, ולכן שינוי המאמץ באמצע סשן מחשב מחדש את כל הבקשה. ב-Opus 5.5, ב-Sonnet 5.5, ב-Haiku 5.5 וב-Fable 5.1 עם מפתח API או מנוי Claude, המטמון נשאר שלם כברירת מחדל. ראה שינוי רמת המאמץ למטה.

[!TIP]

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

#איפה המטמון נמצא

השמירה במטמון מתרחשת בצד השרת, בתשתית שמשרתת את המודל. המיקום תלוי באופן האימות:

• מפתח API, מנוי Claude, או Claude Platform on AWS: המטמון נמצא בתשתית של Anthropic, וניגשים אליו דרך Claude API
• Amazon Bedrock או Agent Platform של Google Cloud: המטמון נמצא בתשתית ההגשה של ספק הענן
• Microsoft Foundry: תלוי באפשרות האירוח של הפריסה. פריסות Hosted on Azure מוגשות על תשתית Azure. פריסות Hosted on Anthropic מוגשות על תשתית של Anthropic
• ANTHROPIC_BASE_URL מותאם או LLM gateway: המטמון נמצא במקום שאליו הבקשות מועברות, והאם המטמון עובד תלוי בשער

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

בנקודת הקצה של הספק עצמו, Amazon Bedrock ונקודת הקצה Mantle שלו, Agent Platform של Google Cloud ו-Microsoft Foundry שומרים את הבלוק במטמון באותו אופן כמו Claude API.

כשהבקשות עוברות דרך LLM gateway, ANTHROPIC_BASE_URL מותאם, או דריסת כתובת בסיס של ספק ענן כמו ANTHROPIC_BEDROCK_BASE_URL, מה שנשאר במטמון תלוי באופן שבו השער מטפל בסמני cache_control ש-Claude Code שולח:

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

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

#פעולות שמבטלות את המטמון

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

• החלפת מודלים
• שינוי רמת המאמץ
• הפעלת מצב מהיר
• חיבור או הסרה של שרת MCP
• הפעלה או השבתה של תוסף
• דחיית כלי שלם
• דחיסת השיחה
• הצטברות של תמונות רבות
• שדרוג Claude Code

#החלפת מודלים

לכל מודל יש מטמון משלו. החלפה באמצעות /model פירושה שהבקשה הבאה קוראת את כל היסטוריית השיחה בלי פגיעות במטמון, למרות שהתוכן זהה.

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

לפני v2.1.238, Claude Code לא בדק את ה TTL של המטמון ושאל גם אחרי שהמטמון פג.

אפשר גם לחייב את האישור הזה או לדלג עליו באמצעות hook מסוג PreModelSwitch.

הגדרת המודל opusplan מתפרשת ל Opus במצב תכנון ול Sonnet בזמן ביצוע, ולכן כל החלפת מצב תכנון היא החלפת מודל ומתחילה מטמון חדש.

נפילה אוטומטית למודל במודלי Fable, ב Opus 5.5, ב Sonnet 5.5 וב Opus 5 היא גם החלפת מודל. כשמסווג בטיחות מסמן בקשה בקטגוריה שיש לה מודל חלופי ו Claude Code מריץ מחדש את הבקשה על המודל הזה, השיחה ממשיכה שם.

כש frontmatter של skill או פקודה מציין model שונה מהמודל הנוכחי של השיחה, גם התור הזה הוא החלפת מודל: הבקשה הבאה קוראת את כל היסטוריית השיחה בלי פגיעות במטמון. מודל השיחה חוזר בפרומפט הבא. skill עם context: fork מגדיר במקום זאת את המודל של תת הסוכן המפוצל.

#שינוי רמת המאמץ

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

ב Opus 5.5, ב Sonnet 5.5, ב Haiku 5.5 וב Fable 5.1 עם מפתח API או מנוי Claude, המטמון נשמר כשמשנים את רמת המאמץ. Claude Code מחיל את הרמה החדשה בלי לשאול. ב Amazon Bedrock, ב Agent Platform של Google Cloud, או בשער יישומי Claude, או כשמגדירים CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS או כשלארגון יש הגדרת HIPAA, זה עובד כמו ברוב המודלים.

לפני v2.1.260, שינוי מאמץ ב Fable 5.1 עם מפתח API או מנוי Claude גם ביטל את המטמון.

#הפעלת מצב מהיר

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

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

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

#חיבור או הסרה של שרת MCP

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

• כלים דחויים: Claude Code שומר את רשימת הכלים מהבקשה הראשונה של השיחה לכל אורך השיחה, ולכן שרת שמתחבר או מתנתק באמצע שיחה לא מפריע למה שכבר במטמון. שרת שמסיים להתחבר אחרי הבקשה הראשונה מספק את הכלים שלו כהגדרות דחויות ש Claude טוען לפי דרישה.
• כלים שנטענים מראש: הוספת הגדרה מבטלת את המטמון, וגם הסרה מכוונת. זה חל כשחיפוש כלים כבוי או לא זמין, למשל ב:
  • מודלים של Agent Platform של Google Cloud שמוקדמים מ Opus 4.5, מ Sonnet 4.5 ומ Haiku 4.5
  • פריסה שמתארחת ב Azure של Microsoft Foundry אחרי ש Claude Code מזהה שהפריסה דוחה חיפוש כלים

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

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

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

#הפעלה או השבתה של תוסף

כשמפעילים או משביתים תוסף, מה השינוי עולה תלוי בסוגי הרכיבים שהתוסף מספק. המקרים למטה מכסים כל סוג רכיב, מתי Claude Code מחיל את השינוי, ומה קורה כשמשביתים תוסף שוב באותה שיחה.

#רכיבי תוסף ששומרים את המטמון

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

#תוספים שמספקים שרתי MCP

כשמפעילים או משביתים תוסף שמספק שרתי MCP, Claude Code פועל לפי אותם כללים כמו בחיבור או הסרה של שרת MCP.

#תוספי בינת קוד

כשמפעילים תוסף בינת קוד, Claude מקבל את כלי ה LSP.

#מתי שינויי תוספים חלים

שינוי שעושים בתפריט /plugin עובר דרך /reload-plugins, ש Claude Code מריץ עבורך כשסוגרים את התפריט. משלמים את העלות, בין אם הודעות שנוספו או קריאה מלאה מחדש, בתור הראשון אחרי שהשינוי חל. Claude Code יכול גם להחיל שינוי בעצמו:

• לתוסף עם מקור command, Claude Code יכול לטעון מחדש את התוסף בעצמו.
• כשמתקינים תוסף מממשק /plugin, Claude Code יכול להפעיל אותו במהלך ההתקנה. סיכום ההתקנה אומר אם הוא עשה זאת.
• כשמעבירים את השיחה עם /cd ב v2.1.246 או מאוחר יותר, Claude Code מחיל את התוספים שהגדרות התיקייה החדשה מפעילות כחלק מהמעבר, בלי אזהרת הקריאה המלאה מחדש שעוצרת /reload-plugins.
• בשיחות אינטראקטיביות, כשמוסיפים או מסירים תוסף בתיקיית תוספים שהועברה עם --plugin-dir, השינוי חל מיד. אם החלתו תגרום לקריאה מלאה מחדש, Claude Code עוצר את השינוי במקום זאת ומציג הודעה להריץ /reload-plugins. נדרש Claude Code v2.1.265 או מאוחר יותר.

כש /reload-plugins רץ והטעינה מחדש תגרום לקריאה מלאה מחדש, Claude Code מציג אזהרה ולא מחיל את הטעינה מחדש. מריצים /reload-plugins --force כדי להחיל אותה בכל זאת.

/reload-plugins רץ גם בשיחות בלי טרמינל אינטראקטיבי, כמו יישום שולחן העבודה, ה Agent SDK, ומצב לא אינטראקטיבי עם -p, כשמקלידים אותו ישירות בשיחה. נדרש Claude Code v2.1.260 או מאוחר יותר.

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

#תוספים שמפעילים ואז משביתים בשיחה אחת

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

#דחיית כלי שלם

אם מוסיפים שם כלי חשוף כמו Bash או WebFetch ככלל דחייה, Claude לא יכול לקרוא לכלי הזה מהבקשה הבאה ואילך, בין אם מוסיפים את הכלל דרך /permissions או על ידי עריכת קובץ הגדרות ישירות. זה כולל כלל שמוסיפים דרך /permissions באמצע תור.

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

רק כלל דחייה שתואם במיקום שם הכלי חוסם כלי בצורה הזו: שם כלי חשוף, הצורה המקבילה Bash(*), או glob של שם כלי כמו "*". glob שתואם רק לכלי MCP, כמו "mcp__*", חוסם את הכלים האלה באותה צורה. כללי דחייה מצומצמים כמו Bash(rm *), וכל כללי allow ו ask, לא משנים אילו כלים Claude רואה. Claude Code בודק אותם כש Claude מנסה קריאה, והקידומת נשארת שלמה.

#דחיסת השיחה

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

• הנחיית מערכת: הבקשה הבאה קוראת את השכבה הזו מהמטמון, אלא אם שיחה שהמשיכו שמרה הנחיית מערכת שעכשיו לא מעודכנת. בפעם הראשונה שהשיחה הזו נדחסת, Claude Code מחליף אותה להנחיה הנוכחית, והבקשה הבאה בונה מחדש את מטמון השכבה הזו פעם אחת.
• הקשר פרויקט: Claude Code טוען מחדש את השכבה הזו מהדיסק. הבקשה הבאה קוראת אותה מהמטמון רק אם CLAUDE.md והזיכרון לא השתנו מאז שהשיחה התחילה.

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

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

[!TIP]

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

אם משאירים שיחה ארוכה בחוסר פעילות בזמן שהיא על TTL של שעה, Claude Code יכול לדחוס אותה. כדי לכבות דחיסה בחוסר פעילות, מגדירים את idleCompaction ל false, וזה דורש Claude Code v2.1.290 או מאוחר יותר.

#הצטברות של תמונות רבות

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

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

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

#שדרוג Claude Code

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

[!NOTE]

למה שעולה להמשיך שיחה שהתחילה לפני השדרוג, ראו המשך שיחה.

#פעולות ששומרות על המטמון

הפעולות האלה מוסיפות לסוף השיחה, או לא נוגעות בבקשה בכלל. חלק מהן, כמו עריכת CLAUDE.md, שומרות על המטמון מאותה סיבה: השינוי לא מגיע לסשן הרץ עד /clear, /compact, או הפעלה מחדש.

• עריכת קבצים במאגר
• עריכת CLAUDE.md באמצע הסשן
• שינוי מצב הרשאות
• שינוי סגנון פלט
• הפעלת מיומנויות ופקודות
• הרצת /recap
• חזרה אחורה בשיחה
• הפעלת סוכן משנה

#עריכת קבצים במאגר

תוכן קבצים נכנס להקשר רק כשקלוד קורא אותם, וקריאות מתווספות לשיחה. עריכת קובץ שקלוד כבר קרא לא משנה בדיעבד את הקריאה הקודמת בהיסטוריה. במקום זה, Claude Code מוסיף <system-reminder> שמציין שהקובץ השתנה, וקלוד קורא אותו שוב אם צריך.

#עריכת CLAUDE.md באמצע הסשן

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

קבצי CLAUDE.md מקוננים בתת ספריות וכללים עם frontmatter של paths: נטענים מאוחר יותר, לפי דרישה. עריכה בעצמך לפני שהם נטענים כן נכנסת לתוקף. אחרי שהם נטענים, התוכן הוא חלק מהיסטוריית השיחה, ולכן עריכה באמצע הסשן לא משנה אותו בדיעבד.

#שינוי מצב הרשאות

מעבר בין מצבי הרשאות, למשל מ-Manual ל-accept edits, לא משנה את ה-system prompt או את הגדרות הכלים, ולכן שינויי מצב בטוחים למטמון. היוצא מן הכלל הוא מצב plan עם הגדרת המודל opusplan, שמחליפה את המודל בין Opus ל-Sonnet כשנכנסים למצב plan או יוצאים ממנו. זה הופך את החלפת המצב להחלפת מודל.

#שינוי סגנון פלט

כשמחליפים סגנונות פלט באמצע הסשן עם /output-style, /config, או ההגדרה outputStyle, קלוד משתמש בסגנון החדש החל מההודעה הבאה. Claude Code מעביר את הוראות הסגנון החדש כהודעה בשיחה, ולכן הבקשה הזו עדיין קוראת את ה-system prompt ואת השיחה הקודמת מהמטמון.

לפני v2.1.251, החלפת סגנון באמצע הסשן שמרה על המטמון אבל לא נכנסה לתוקף עד שהרצתם /clear או התחלתם סשן חדש.

#הפעלת מיומנויות ופקודות

מיומנויות ופקודות מזריקות את ההוראות שלהן כהודעות משתמש בנקודת ההפעלה. שום דבר מוקדם יותר בשיחה לא משתנה. מיומנות או פקודה שה-frontmatter שלה מציין model יכולה להיות החלפת מודל לאותו תור.

#הרצת /recap

/recap מייצר סיכום להצגה בטרמינל. בניגוד ל-/compact, הוא מוסיף את הסיכום כפלט של פקודה במקום להחליף את היסטוריית ההודעות, ולכן הקידומת שבמטמון נשארת שלמה.

#חזרה אחורה בשיחה

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

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

#חידוש סשן

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

ה-system prompt משתנה אחרי שדרוג של Claude Code או עם טקסט שונה של --append-system-prompt בחידוש. כברירת מחדל, השיחה המחודשת שומרת על ה-system prompt שאיתו התחילה, ולכן ההיסטוריה שלה עדיין יושבת מאחורי אותו prompt, והשינוי נכנס לתוקף אחרי שהשיחה עוברת compaction או בשיחה חדשה. דגלי system prompt בשיחות מחודשות מכסים את המקרים שבהם Claude Code בונה מחדש את ה-prompt בכל בקשה.

#זמן חיים של המטמון

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

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

#איזה TTL כל בקשה מקבלת

Claude Code מחליט על ה-TTL לכל בקשה, וכל בקשה נופלת לאחד משני סלים קבועים:

• השיחה הראשית: התורות האינטראקטיביים, הרצות -p לא אינטראקטיביות, ותורות של Agent SDK, וגם העוזרים ש-Claude Code מריץ בתוך השורה איתם
• כל השאר: הבקשות ש-Claude Code עושה מחוץ לשיחה הזו, כמו סוכני משנה, workflows, חברי צוות בתוך התהליך, forks, compaction, וכותרות סשן

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

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

#בחירת ה-TTL בעצמכם

אפשר להגדיר TTL לכל אחד מהסלים. כל בקרה מקבלת 5m או 1h, ו-Claude Code מתעלם מכל ערך אחר.

• השיחה הראשית: ההגדרה promptCacheTtl, או משתנה הסביבה CLAUDE_CODE_PROMPT_CACHE_TTL
• כל השאר: ההגדרה subagentPromptCacheTtl, או משתנה הסביבה CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL

שתי ההגדרות ושני משתני הסביבה דורשים Claude Code v2.1.242 או חדש יותר. אם נכנסים עם מפתח API או משתמשים בספק ענן, מגדירים את promptCacheTtl ל-1h כדי לתת לשיחה הראשית מטמון של שעה. בקשות מחוץ לה נשארות בברירת המחדל של חמש דקות עד שבוחרים TTL גם לסל הזה.

כשיותר מבקרה אחת חלה, Claude Code לוקח את ההתאמה הראשונה בסדר הזה:

1. FORCE_PROMPT_CACHING_5M=1, שכופה חמש דקות לשני הסלים
2. משתנה הסביבה של הסל
3. ההגדרה של הסל
4. לבקשות של סוכן משנה, הערך cacheTtl בשדה ה-frontmatter experimental של סוכן המשנה, שדורש Claude Code v2.1.248 או חדש יותר. Claude Code מתעלם מ-1h שם בזמן שמנוי Claude משתמש בקרדיטי שימוש
5. ENABLE_PROMPT_CACHING_1H=1, שמבקש שעה אחת לשני הסלים
6. ברירת המחדל לסל של הבקשה

מגדירים FORCE_PROMPT_CACHING_5M=1 כשמנפים באגים בהתנהגות המטמון, משווים בין שני ה-TTL, או דורסים TTL ארוך יותר שהוגדר בהגדרות מנוהלות.

כדי לאשר באיזה TTL השתמשו כתיבות המטמון של השיחה הראשית, מריצים claude -p "hello" --output-format json וקוראים את usage.cache_creation בתוצאה. Claude Code מדווח על כתיבות מטמון של שעה תחת ephemeral_1h_input_tokens ועל כתיבות מטמון של חמש דקות תחת ephemeral_5m_input_tokens.

כדי לקבל שעה אחת דרך שער או ב-Amazon Bedrock:

• שער LLM שהגדרתם עם ANTHROPIC_BASE_URL: חלק מבקשת השעה עובר בכותרת anthropic-beta, אז מגדירים את השער להעביר את הכותרת הזו בלי שינוי
• שער אפליקציות Claude: מבקשים ממנהל המערכת לבקש את ה-TTL של שעה במדיניות שער
• Amazon Bedrock: תמיכה במטמון prompts, אורך קידומת מינימלי שאפשר לשמור במטמון, וזמינות TTL של שעה, כולם משתנים לפי מודל. אם ספירות טוקני המטמון נשארות באפס, בודקים מודלים, אזורים ומגבלות נתמכים בתיעוד של Amazon Bedrock.

#היקף המטמון

ב-Claude Code, המטמון מוגבל בפועל למכונה אחת ולספרייה אחת. ה-system prompt מטמיע את נתיבי ה-auto memory, והשיחה נפתחת בהכרזה על ספריית העבודה, הפלטפורמה, ה-shell, וגרסת מערכת ההפעלה. שני סשנים בספריות שונות בונים לכן קידומות שונות ומפספסים את המטמון זה של זה.

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

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

למי שקורא ל-Agent SDK ומריץ ציי של תהליכים אוטומטיים, ראו שיפור מטמון prompts בין משתמשים ומכונות כדי להוציא את מיקום ה-auto memory מה-system prompt.

#בדיקת ביצועי המטמון

ביצועי המטמון מופיעים כשתי ספירות טוקנים שה-API מדווח עליהן בכל תשובה. הדרך הישירה ביותר לעקוב אחריהן בזמן אמת היא סקריפט statusline שקורא את האובייקט current_usage:

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

לסיכום לכל סשן, מריצים /usage. אחרי התשובה הראשונה של השיחה הראשית, Claude Code מוסיף שורת Prompt cache (main) לבלוק Session, שמציגה את יחס הפגיעות של הסשן, את מספר ההחטאות, והאם המטמון חם כרגע. סקריפט שורת סטטוס יכול לקרוא את אותם מספרים מהאובייקט prompt_cache. שניהם דורשים Claude Code v2.1.251 או חדש יותר.

השורה Prompt cache (main) גם מציינת את הסיבה הסבירה להחטאה האחרונה כש-Claude Code יכול לזהות אחת, למשל likely cause: tool definitions changed. טקסט הסיבה הסבירה דורש Claude Code v2.1.260 או חדש יותר.

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

#סוכני משנה והמטמון

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

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

fork, לעומת זאת, יורש בדיוק את ה-system prompt, הכלים, והיסטוריית השיחה של ההורה, ולכן הבקשה הראשונה שלו קוראת את המטמון של ההורה.

בקשות אחרות יכולות גם לקרוא קידומת שבקשה מוקדמת יותר שמרה במטמון:

• העתקי סשן: סשן שמעתיקים עם /fork מקבל את הוראת הבידוד שלו כהודעה בסוף השיחה שהועתקה, ולכן המטמון שהשיחה המקורית בנתה נשאר שלם.
• Compaction: קריאת הסיכום שמתוארת בדחיסת השיחה משתמשת באותה גישה של שיתוף קידומת.
• סוכני משנה מחודשים: כשקלוד מחדש סוכן משנה, הבקשה הראשונה של ההרצה המחודשת יכולה לקרוא את המטמון שההרצה המקורית חיממה.
• פיצולי workflow: בפיצול workflow של סוכנים עם אותה קידומת, Claude Code מחזיק את כולם חוץ מהראשון עד 5 שניות כברירת מחדל, כדי שהבקשות הראשונות שלהם יוכלו לקרוא את הקידומת שהסוכן הראשון שמר במטמון.

#כיבוי מטמון prompts

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

DISABLE_PROMPT_CACHING_HAIKU חל על מודל Haiku ברירת המחדל, המודל שאליו הכינוי haiku מתפרש. הוא מכבה מטמון בכל מקום שהמודל הזה רץ, כולל השיחה הראשית כשהוא המודל הראשי. כיסוי השיחה הראשית דורש Claude Code v2.1.283 או חדש יותר.

המשתנה מכסה גם מודל רקע שהוגדר עם המשתנה הישן ANTHROPIC_SMALL_FAST_MODEL, כשהמודל הזה שונה מהמודל הראשי.

גרסת Haiku אחרת שנועצת כמודל הראשי שומרת על מטמון. מגדירים DISABLE_PROMPT_CACHING כדי לכבות מטמון עבורה.

DISABLE_PROMPT_CACHING_SONNET ו-DISABLE_PROMPT_CACHING_OPUS חלים כל אחד על המודל שאליו הכינוי sonnet או opus מתפרש. אם מגדירים מזהה מודל Sonnet או Opus אחר כמודל הראשי, המודל הזה שומר על מטמון. לדוגמה, סשן על claude-sonnet-5 שומר על מטמון בזמן ש-sonnet מתפרש ל-claude-sonnet-5-5. כדי לכבות מטמון למודל הזה, מגדירים DISABLE_PROMPT_CACHING.

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

#משאבים קשורים

• לקחים מבניית Claude Code: אחסון פרומפטים במטמון הוא הכל: הרציונל העיצובי של plan mode, deferred tool loading ו-compaction
• חקירת חלון ההקשר: מה נטען להקשר ומתי
• הקטנת שימוש בטוקנים: אסטרטגיות מעבר למטמון לניהול גודל ההקשר
• מעקב והפחתת עלויות: מעקב אחרי טוקני מטמון והגדרת TTL עבור קוראים של Agent SDK
• אחסון פרומפטים במטמון: מנגנון ה-API הבסיסי, breakpoints ותמחור