SSD Nodes Learn
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-07-24

איך להאיץ ולחסוך בעלויות ב-Claude Code

סשן ארוך הופך לאיטי ויקר כי כל פנייה שולחת מחדש את כל ה-context. למדו להשתמש ב-/context ובפקודות המתאימות כדי לנקות את הזיכרון ולשמור על ה-prompt cache.

כיצד למנוע מהסשן של Claude Code להפוך לאיטי ויקר

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

הסיבה לכך שהמונה פועל מוסברת ב-מונה ה-token שמאחורי סשן agent.

קרא את /context לפני כל שינוי

אל תנחש מה ממלא את החלון. Claude Code יציין זאת.

/context [all] מציג את ניצול ההקשר (context) הנוכחי כרשת צבעונית, עם הצעות אופטימיזציה עבור כלים עם הקשר עמוק וצריכת זיכרון גבוהה; all מרחיב את הפירוט לכל פריט במצב מסך מלא. קרא את התוצאה כשלוש קטגוריות.

  • The system prompt. הוראות המערכת של Claude Code. קבוע לאורך כל הסשן.
  • Tool definitions. הסכימה של כל כלי שהסוכן יכול לקרוא, כולל כל שרת MCP (Model Context Protocol) מחובר.
  • Memory files. CLAUDE.md וזיכרון אוטומטי, נטענים בתחילת הסשן.
  • Files and tool results. כל קובץ שנקרא, וכל פלט שהפקודות שלך החזירו.
  • Message history. התורות שלך והתשובות שלו.

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

שתי מחרוזות מעידות שהחלון מלא:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

הראשונה היא מגבלה קשיחה, והבקשה נדחית; שגיאת ה-API המתאימה היא Prompt is too long. השנייה היא חלון דחיסה (compaction window), שיכול להיות נמוך מהחלון ההקשר האמיתי של המודל במודל של 1 million token. בקשות עדיין מצליחות מעבר אליו, לכן זוהי אזהרה ולא דחייה.

בתוכנית בתשלום, /usage מוסיפה את החצי השני, ומסמנת התנהגויות כמו הקשר ארוך או פסילת מטמון (cache misses) ומייחסת שימוש אחרון לכל אחד מה-skills, subagents ושרתי MCP.

CLAUDE.md הוא מס שקבוע, לכן שמור עליו רזה

ה-CLAUDE.md שלך נטען לתוך ה-context בתחילת הסשן ונשאר שם. אם הוא מכיל פרוצדורת פריסה מפורטת, ה-tokens הללו קיימים גם בזמן תיקון שגיאת כתיב בקובץ בדיקה. ההנחיה של Anthropic היא לכלול רק דברים חיוניים ולשמור על הקובץ מתחת ל-200 שורות.

העבר פרוצדורות ל-skills. skill נטען רק כאשר הוא נקרא, לכן workflow שאתה מריץ פעמיים בשבוע לא עולה דבר בימים אחרים. ל-skills יש תקציב משלהם לאחר compaction: ה-bodies מוזרקים מחדש, מוגבלים ל-5,000 tokens לכל skill ו-25,000 בסך הכל, כאשר הקרן ביותר נמחקת ראשונה. ה-truncation שומר על תחילת הקובץ, לכן מקם את ההוראות החשובות ביותר בראש ה-SKILL.md.

מה ששורד compaction קובע היכן להציב הוראה.

  • ה-system prompt וסגנון הפלט אינם משתנים, כיוון שהם אינם חלק מה-message history.
  • ה-CLAUDE.md ב-project-root, חוקים ללא scope, ו-auto memory נטענים מחדש מהדיסק.
  • חוק עם frontmatter מסוג paths: יאבד עד שקובץ תואם ייקרא שוב.
  • CLAUDE.md מקוטן בתוך תת-תיקייה יאבד עד שקובץ בתוך תת-תיקייה זו ייקרא שוב.
  • hooks אינם מושפעים, כיוון ש-hook רץ כקוד ולעולם לא נכנס ל-context.

לכן, חוק שעליו אתה מסתמך צריך להיות ב-CLAUDE.md ב-project-root: Claude Code מנקה קודם את ה-tool outputs הישנים ואז מבצע סיכום, לכן הוראות מתחילת השיחה עלולות לאבד. ערוך את ה-memory באמצעות /memory. Claude Code מחזיק את העותק שנטען בתחילת הסשן, לכן קיצוץ באמצע הסשן שומר על ה-prompt cache ולא יתApply עד ל-/clear, /compact, או restart.

/clear בין משימות, /compact בתוך משימה אחת

שתי הפקודות הללו נראות דומות אך עלותן שונה מאוד.

/clear [name] מתחילה שיחה חדשה עם context ריק. היא אינה שולחת בקשה, ולכן אינה עולה דבר. ניתן להעביר שם כדי לתייג את השיחה הקודמת בתוך ה-picker של /resume; הפקודות /reset ו-/new הן שמות נרדפים. השתמש בפקודה ברגע שעוברים למשימה לא קשורה, אחרת המשימה הישנה תישלח מחדש ותחויב מחדש בכל הודעה חדשה.

/compact [instructions] משחררת context תוך המשך אותה שיחה: היא מסכמת את ההיסטוריה עד כה ומחליטה אותה. השתמש בפקודה זו בתוך משימה ארוכה שבה עדיין נדרש רצף (continuity).

תמיד יש לתת הוראה ל-/compact. פקודת /compact ללא הוראה תסכם לפי prompt ברירת מחדל שאינו יודע איזה חלק מהעבודה עדיין נדרש. פקודה עם הוראה תשמור על הרצף:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

אם אתם מבצעים compaction מאותה סיבה בכל פעם, הגדירו הוראה קבועה בתוך ה-CLAUDE.md של הפרויקט תחת כותרת # Compact instructions. בסשן חדש, /compact תדפיס את Not enough messages to compact., שמשמעותו היא שאין היסטוריה עדיין.

יש בלבול בין שתי העלויות כאן. בקשת הסיכום משתמשת ב-prefix שלכם, ולכן היא קוראת מה-cache הקיים במקום לעבד מחדש את ההיסטוריה; רוב הזמן שלה מוקדש ליצירת הסיכום. ביצוע compaction ל-context גדול עדיין נחשב לבקשה גדולה, כיוון שהשיחה המסוכמת היא הקלט. התור שאחרי ה-compaction אינו החלק האיטי: הוא בונה מחדש את ה-cache עבור prompt קצר בהרבה.

קיימות שתי פקודות זולות יותר. /rewind [description] מחזירה את הקוד והשיחה לנקודת checkpoint; עבור נתיב שרוצים לנטוש לחלוטין, היא עדיפה על compaction, כיוון שהיא מקצצת חזרה ל-prefix שכבר נמצא ב-cache. /recap מוסיפה סיכום כפלט של הפקודה במקום להחליף את ההיסטוריה, כך שה-prefix המאוחסן נשאר ללא שינוי.

compaction אוטומטי שרץ שוב ושוב ידפיס את זה:

Autocompact is thrashing: the context refilled to the limit...

ה-compaction הצליח, אך קובץ או פלט של כלי מילאו מחדש את החלון מספר פעמים ברציפות, ולכן Claude Code הפסיק לנסות שוב. ניתן לשחזר זאת על ידי קריאת הקובץ הגדול בטווח שורות (line ranges), הרצת /compact עם focus שמסיר את הפלט הגדול, העברת העבודה לסוכן משנה (subagent), או שימוש ב-/clear אם השיחה הקודמת הסתיימה.

שרתים של MCP הם הוצאה קבועה

כל שרת MCP שאתה מחבר מוסיף עומס לכל בקשה לאורך כל הסשן. העלות חלה גם אם לא קראת לכלי.

Claude Code מפחית עומס זה. הגדרות כלי MCP נדחות (deferred) כברירת מחדל, כך שרק שמות הכלים נכנסים להקשר (context) עד ש-Claude משתמש בכלי ספציפי. הרץ את /context כדי לראות מה העלות האמיתית של השרתים שלך, והרץ את /mcp disable <name> כדי להסיר שרת שלא תשתמש בו היום. אם אתה מריץ שרתי MCP משלך ב-VPS, אותה מתמטיקה מגבילה את מספר הכלים ששרת אחד צריך לחשוף.

בצע פעולה זו בתחילת סשן. בזמן שההגדרות נשארות בסטטוס deferred, חיבור או ניתוק של שרת מוסיפים فقط לשיחה, והמטמון (cache) נשמר. במקומות שבהם ההגדרות נטענות לתוך ה-prefix, מכיוון שחיפוש הכלים כבוי או שהשרת פטור מסטטוס deferred, אותו שינוי יגרום לבקשה הבאה לקרוא הכל מחדש.

סינון פלט מפורט של כלי לפני הכנסתו להקשר (context)

תוצאת כלי נחשבת לקלט, והקלט נשלח מחדש בכל שלב (turn) מאוחר יותר. הרצה של בדיקה המפיקה 20,000 tokens אינה עלות חד-פעמית: עליך לשלם עליה שוב בכל שלב עד שהיא יוצאת מהחלון.

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

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

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

הגדר את היקף הקריאה של ה-agent והעבר עבודות רועשות

prompt המציין שם קובץ ויזμα יקרא את אותו קובץ. בקשה כללית לסידור הפרויקט תגרום ל-agent לקרוא כל מה שהוא מחליט שרלוונטי, וכל קריאה כזו תישאר בתוך ה-window.

העבר עבודות מפורטות ל-subagent. הרצת בדיקות ועיבוד לוגים צורכים context; subagent שומר את הפלט בחלון משלו ומחזיר רק סיכום. המחיר: subagent בונה cache משלו ללא hits בקריאה הראשונה, ומשתמש ב-cache lifetime של חמש דקות גם במנוי (subscription). העברת משימות (Delegation) מגנה באופן אמין על ה-context הראשי שלך. היא לא תמיד מפחיתה את סך ה-tokens.

שעון ה-cache: עבודה במנות

Prompt caching הוא מה שהופך את השליחה מחדש למשתלמת: 0.1x מהקצב הבסיסי של קריאת ה-prefix, לעומת 1.25x לכתיבתו, או 2x לכתיבתו עם תוקף של שעה אחת. כל שימוש מרענן את הרשומה ללא עלות נוספת, לכן השעון מתחיל ממועד השימוש האחרון.

משך התוקף שתקבל תלוי בשיטת האימות שלך, וזו הסיבה שהקביעה הכללית "ה-cache שלך פוקע לאחר חמש דקות" אינה מדויקת.

  • במנוי Claude, ה-Claude Code מבקש אוטומטית תוקף של שעה אחת.
  • ברגע שחרגת מהמכסה של התוכנית שלך ועובר לשימוש בקרדיטים (usage credits), אתה מחויב על השימוש הזה, ולכן התוקף יורד חזרה לחמש דקות.
  • בשימוש ב-API key או בספק ענן, התוקף נשאר על חמש דקות. ENABLE_PROMPT_CACHING_1H=1 מאפשר לבחור בתוקף של שעה אחת, ו-FORCE_PROMPT_CACHING_5M=1 מחזיר אותו חזרה לחמש דקות.

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

פעולות מסוימות מוחקות את ה-cache בזמן שאתם עדיין עובדים: החלפת מודלים, שינוי רמת המאמץ (effort level), הפעלת fast mode, חיבור או ניתוק של MCP server, הפעלה או ביטול של plugin, חסימת כלי (tool) שלם, פעולת compaction, ושדרוג של Claude Code. /model הוא ההפתעה הנפוצה, מכיוון שלכל מודל יש cache משלו, ולכן הבקשה הבאה תקרא את כל ההיסטוריה ללא hits ב-cache למרות שהתוכן זהה.

עריכת קבצים, עריכת CLAUDE.md, הפעלת skills ופקודות, הרצת /recap, חזרה אחורה (rewinding), ויצירת subagent, כולם שומרים על ה-cache. ה-cache מוגדר למכונה אחת ולספרייה אחת, לכן שתי סשנים בספריות שונות לא ישתמשו ב-cache אחד של השני.

כדי לבדוק אם ה-caching עובד, קראו את current_usage. cache_creation_input_tokens נכתב בקצב הכתיבה של ה-cache; cache_read_input_tokens נשלח בערך עשירית מקצב הקלט הסטנדרטי. יחס גבוה בין קריאה ליצירה (read-to-creation ratio) מעיד על מצב תקין. אם קצב היצירה נשאר גבוה לאורך זמן, סימן שמשהו ב-prefix שלך משתנה باستمرار.

האם חלון הקשר (context window) גדול יותר פותר זאת?

באופן חלקי. מספר מודלים נוכחיים תומכים בחלון הקשר של 1 million token, ושיטת ה-compaction פועלת באותו אופן גם במגבלה הגבוהה יותר. הכלכלה של השימוש אינה משתנה, מכיוון שה-prompt המלא נשלח מחדש ונגבה עבורו תשלום בכל סבב. חלון גדול יותר קובע מתי תאלץ לפעול; ה-hygiene קובע את העלות. אם הבעיה היא החיוב ולא המגבלה המקסימלית, איזה תוכנית Claude מתאימה לסגנון העבודה שלך תקבע אם אתה משלם דולרים או משתמש במכסת התוכנית.

עריכת הקשר (Context editing) ודחיסה (Compaction) ב-API הן פעולות שונות

אם אתם בונים סוכן משלכם באמצעות ה-Messages API, לא קיימות פקודות slash וצריך לממש אותן בעצמכם. שתי תכונות בצד השרת מבצעות את המשימה, והן אינן אותה תכונה.

עריכת הקשר (Context editing) מוחקת באופן סלקטיבי תוכן ספציפי מהיסטוריית השיחה ככל שהיא גדלה. היא מחליפה כל תוצאה שנמחקה בטקסט שמplaceholder, כדי ש-Claude יידע שמשהו הוסר. זוהי גרסת beta: יש לשלוח anthropic-beta: context-management-2025-06-27 ולהגדיר אסטרטגיות תחת context_management.edits. clear_tool_uses_20250919 מוחק תוצאות של כלים (tool results), ו-clear_thinking_20251015 מנהל בלוקים של חשיבה (thinking blocks). ה-trigger מוגדר כברירת מחדל ל-100,000 input tokens, ה-keep ל-3 השימושים האחרונים בכלים, וה-clear_tool_inputs ל-false, כך שהקלט (inputs) נשאר ורק התוצאות נמחקות.

דחיסה (Compaction) יוצרת סיכום ומחליפה את היסטוריית השיחה המלאה בו. גם זו גרסת beta: יש לשלוח anthropic-beta: compact-2026-01-12 ולהשתמש בסוג עריכה compact_20260112. הטריגר מוגדר כברירת מחדל כ-{"type": "input_tokens", "value": 150000}, והערך חייב להיות לפחות 50,000.

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

התיעוד של Anthropic מגדיר את הדחיסה בצד השרת כאסטרטגיה העיקרית לניהול הקשר בשיחות ארוכות, ואת עריכת ההקשר כאופציה לשליטה מדויקת יותר במה שנמחק. בדקו תחילה את תמיכת המודל. המודלים הנוכחיים Opus, Sonnet ו-Fable תומכים בדחיסה; claude-haiku-4-5 אינו תומך, ודף ה-compaction מכיל את הרשימה המעודכנת. אף אחת מהגרסאות ה-beta אינה מפעילה את ה-/compact של Claude Code, אותו התיעוד מתאר כבקשת סיכום חד-פעמית שהלקוח (client) שולח.

FAQ

מדוע סשן ה-Claude Code שלי הופך לאיטי ויקר יותר ככל שהוא נמשך זמן רב יותר?

מכיוון שכל השיחה נשלחת מחדש בכל שלב (turn). שאלה בת שורה אחת בסשן שפתוח לאורך כל היום כוללת בתוכה את כל תוכן היום. Prompt caching שומר על עלות נמוכה כל עוד ה-cache חם, בשיעור של 0.1x ממחיר הקלט הבסיסי לקריאה; ברגע ששלב מסוים אינו נמצא ב-cache, אותו prefix נכתב מחדש בשיעור של 1.25x. הרץ את /context כדי לראות מה ממלא את ה-window, וקרא את על מה Claude Code מחייב אותך כדי להבין את המנגנון.

מה ההבדל בין /clear לבין /compact ב-Claude Code?

/clear מתחיל שיחה חדשה עם context ריק. הוא אינו שולח בקשה, ולכן אינו עולה דבר; זו הבחירה הנכונה בין משימות לא קשורות. /compact שומר על אותה שיחה ומחליף את ההיסטוריה בסיכום, ולכן זו הבחירה הנכונה בתוך משימה אחת ארוכה. ספק לו מיקוד, כפי שמוצג ב-/compact keep only the plan and the diff, מכיוון שההוראה קובעת מה יישמר.

איך אני יכול לראות מה צורך את ה-context window של ה-Claude Code שלי?

הרץ את /context, או את /context all לקבלת פירוט מלא לכל פריט. הפקודה מציגה את ה-system prompt, הגדרות הכלים (tool definitions), שרתי MCP, קבצי זיכרון וההיסטוריה כרשת צבעונית, עם הצעות לכלים עתירי context ולניפוח זיכרון. בתוכנית בתשלום, /usage משייך גם שימוש אחרון לכל skill, subagent ושרת MCP.

האם כדאי לי להשתמש ב-context window של 1 million token במקום ב-compacting?

חלון context גדול יותר דוחה את הבעיה במקום לפתור אותה. מספר מודלים נוכחיים תומכים ב-context window של 1 million token, כולל Opus 4.8 ו-Sonnet 5, וה-compaction מתנהג באותו אופן גם שם. כל שלב עדיין שולח מחדש את ה-prompt המלא ועדיין מחייב עליו תשלום, לכן שיחה של 400,000 tokens היא יקרה בין אם היא נכנסת בחלון ובין אם לאו.

מה ההבדל בין עריכת context (context editing) לבין compaction ב-Claude API?

עריכת context מנקה באופן סלקטיבי תוכן ישן, בעיקר תוצאות של כלים (tool results), ומשאירה טקסט של placeholder במקום שבו כל תוצאה הייתה, כדי ש-Claude יידע שהיא הוסרה. compaction מייצר סיכום ומחליף את ההיסטוריה המלאה בו. התיעוד של Anthropic מגדיר את ה-compaction כאסטרטגיה העיקרית לשיחות ארוכות, ומציג את עריכת ה-context כאופציה מפורטת (fine-grained). שניהם בגרסת beta עם כותרות משלהם, ושניהם נפרדים מ-/compact של Claude Code.