קיר ה-Context — לנצח את ה-Compaction Buffer ולא לאבד היסטוריה

למה ריצה ארוכה נופלת מקיר שלא ראית

בפרק 2 הרצת את ה-harness על משימה קצרה — "קרא קובץ, סכם אותו, כתוב את הסיכום". הסוכן עשה שלושה-ארבעה סבבים, הלולאה נעצרה ב-final answer, וזה עבד. עכשיו דמיין/י משימה אמיתית: "עבור על ה-repo, מצא את כל ה-endpoints שלא מכוסים בטסטים, כתוב טסט לכל אחד, הרץ את הסוויטה, תקן מה שנשבר". זו ריצה של 40, 60, אולי 100 סבבים. ובמקום מסוים — בלי אזהרה — הסוכן מתחיל "לשכוח": הוא חוזר על decision שכבר קיבל, הוא מנסה לכתוב טסט לקובץ שכבר טיפל בו, הוא שואל אותך משהו שכבר עניתָ עליו.

זה לא bug במודל. זה קיר ה-context. כל סבב בלולאה שלך לא שולח רק את ההודעה האחרונה — הוא שולח את כל ההיסטוריה מחדש: ה-system prompt, ה-goal, כל ה-assistant messages, כל ה-tool_result שחזרו. המודל הוא stateless (כפי שראינו בפרק 2), אז ה-harness אחראי לשלוח את כל ההקשר בכל פעם. ככל שהריצה מתארכת, ההיסטוריה תופחת — וברגע מסוים היא נתקלת בגבול חלון ה-context.

אבל הגבול הזה לא נמצא איפה שאתה חושב. הוא נמוך יותר. הרבה יותר. וזו בדיוק הסכנה: ה-harness שלך נדחס ומאבד מידע הרבה לפני שספרת את כל ה-tokens שזמינים לכאורה. בפרק הזה נפרק בדיוק למה.

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

הדבר שהופך את קיר ה-context לערמומי הוא שהוא לא ליניארי באינטואיציה שלך. אתה חושב על "הודעה אחת" — אבל ה-harness חושב על "כל ההודעות עד עכשיו, בכל סבב, מחדש". זו צמיחה מצטברת: בסבב 5 שלחת מחדש את 4 הסבבים הקודמים, בסבב 30 אתה שולח מחדש את 29 הקודמים. הנה (דוגמה מייצגת) איך זה מרגיש בשטח:

• סבבים 1–10: הכול ירוק. ה-context תופס אולי 15% מהחלון. אתה משוכנע שאין בעיה ושכל הדיבורים על compaction הם פרנויה.
• סבבים 11–25: tool results מתחילים להצטבר. כל קריאת read_file מוסיפה את תוכן הקובץ ל-context לתמיד. אתה ב-50%, אבל עדיין לא שמת לב כי לא מדדת.
• סבב 26: tool יחיד מחזיר JSON של 40KB. בקפיצה אחת אתה מ-65% ל-84%. ה-compaction נורה. כל ההיסטוריה היפה שלך נדחסת — וה-decision מסבב 8 נעלם.
• סבב 31: הסוכן מתנהג כאילו סבב 8 לא קרה. אתה מבולבל. "למה הוא שולח email בלי אישור? הרי החלטנו..."

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

חשבון ה-tokens בזמן אמת — מה קורה בסבב 5 ובסבב 26

כדי שהדינמיקה תהיה ממשית ולא מופשטת, בוא נעשה את החשבון מספרית על דוגמה מייצגת של משימת lead-enrichment — שירוצו 30 סבבים (בחלון של 200K):

שים/י לב מה קורה בין סבב 25 לסבב 26: tool result אחד (Apollo enrichment ל-50 leads) הוסיף ~12,000 tokens בקפיצה אחת — מ-76.2% ל-83.7%. זהו בדיוק המנגנון שגורם ל-compaction לדחוס את ההיסטוריה מהר יותר מהאינטואיציה שלך. בסבב 5 הרגשת בנוח — 11.3% זה כאילו "יש עוד המון מקום". 21 סבבים לאחר מכן הריצה כבר בסכנה.

הנה המספרים שאיתם כדאי לעבוד — ב-system_prompt קבוע של 2,400 tokens ו-tool results ממוצעים של 5,000–8,000 tokens לסבב: אתה מגיע ל-75% (סף ה-backup) תוך בערך 22–25 סבבים. זה פחות מסבב 30, ובהחלט פחות ממה שרוב הבונים מדמיינים כ"ריצה ארוכה".

מבנה חלון ה-Context — מאיפה נגמר המקום

בוא נפרק את חלון ה-context לרצועות. חלון ה-context (context window) הוא כמות ה-tokens המקסימלית שהמודל יכול "לראות" בקריאה אחת — input ו-output יחד. כשאתה קורא למודל בלולאה, הקריאה מורכבת מכמה שכבות שמצטברות:

שלוש הרצועות הראשונות הן ה-input. הרצועה הרביעית היא העוקץ. ה-Claude Agent SDK לא נותן לך את כל החלון ל-input. הוא שומר באופן קשיח חלק מהחלון ל-output שהמודל עוד צריך לייצר, ועוד שוליים ל-safety. לפי ה-research של הקורס, ה-buffer הזה עומד על כ-33K tokens. כלומר: אם החלון הוא, נניח, 200K tokens, ה-history שלך לא יכול לתפוס 200K — הוא נחנק הרבה קודם, כי 33K כבר "תפוסים" עוד לפני שכתבת בית אחד.

למה ה-buffer הזה קיים בכלל? כי המודל חייב מקום ליצור את התשובה. אם תמלא את כל החלון ב-input, לא יישאר מקום ל-output — והקריאה תיכשל או תיחתך באמצע. ה-SDK מגן עליך מזה בכך שהוא שומר את ה-33K מראש. הבעיה היא לא שה-buffer קיים — הבעיה היא שרוב הבונים לא יודעים שהוא קיים, ומגלים אותו רק כשהריצה כבר איבדה היסטוריה.

החשבון בפועל — שלוש שורות שכל בונה harness חייב לדעת בעל-פה

בוא נעשה את החשבון על חלון של 200K tokens (התאם/י למודל שלך — חלקם 200K, חלקם יותר):

שים/י לב להתכנסות המטרידה: ה-buffer מותיר ~167K, וסף ה-83.5% גם הוא נופל בערך באותו אזור. כלומר ברגע שה-history שלך מתקרב למלא את המקום הזמין — ה-compaction כבר נורה. אין "אזור ביטחון" נדיב בין שני המספרים. זה למה הסכנה אמיתית ולא תיאורטית: שני המנגנונים — ה-buffer וה-threshold — מצטלבים כמעט באותה נקודה, וכל קפיצה אחת (tool result כבד) מספיקה כדי לחצות.

הכלל שתישא/י איתך: כשאתה מתכנן כמה context "יש לך", התחל מ-83.5% של החלון, לא מ-100%. ומתוך זה — שמור עוד שוליים משלך, כי אתה רוצה לגבות לפני הסף, לא עליו.

ה-Compaction Buffer Trap — מה קורה כשמגיעים ל-83.5%

עכשiו שיש לך את מבנה החלון, בוא נראה מה קורה כשהוא מתמלא. ה-Claude Agent SDK לא מחכה שהחלון יתפוצץ. הוא מפעיל compaction אוטומטי כשהשימוש נוגע ב-~83.5% מהחלון (מקור: course.research.json → gotchas). ברגע הזה ה-SDK לוקח את ההיסטוריה, מסכם אותה — ומחליף הרבה הודעות בייצוג דחוס יותר. המטרה טובה: לפנות מקום כדי שהריצה תמשיך. הבעיה: אתה לא בחרת מה לשמר.

זה ה-Compaction Buffer Trap: שילוב של שני המספרים. ה-buffer של 33K כבר מקטין את ה-history הזמין, ואז סף ה-83.5% מפעיל דחיסה בתוך מה שנשאר. הריצה שלך נדחסת מוקדם מאוד ביחס לאינטואיציה — וה-compaction הוא lossy: הוא מאבד מידע. אם ה-harness שלך לא תוכנן לזה, decision קריטי שהסוכן קיבל בסבב 12, או deliverable חלקי שבנה בסבב 20, יכולים פשוט להיעלם תחת לחץ ה-compaction. הסוכן ימשיך לרוץ — אבל בלי הזיכרון של מה שעשה. וזו בדיוק נקודת הכישלון: אתה מגלה את זה רק כשהסוכן "שוכח" מה הוא עשה ומתחיל מחדש.

למה "lossy" זה לא תיאורטי

בוא נמחיש עם תרחיש קונקרטי (דוגמה מייצגת). הסוכן שלך רץ על משימת lead-enrichment:

• סבב 8: הסוכן מקבל decision — "Lead מסוג enterprise תמיד עובר לאישור אנושי לפני שליחת email". זה החלטה לוגית קריטית.
• סבב 25: הסוכן צרך כבר הרבה tool results (Apollo enrichment, GitHub stars, drafts). השימוש נוגע ב-83.5%. compaction אוטומטי נורה.
• הדחיסה: ה-SDK מסכם את ההיסטוריה ל"הסוכן העשיר 14 leads ושייך אותם". ה-decision מסבב 8? לא הוזכר בסיכום — נמחק.
• סבב 31: הסוכן מגיע ל-lead enterprise. בלי ה-decision מסבב 8, הוא שולח email בלי אישור אנושי. נזק.

ה-compaction לא "טעה" — הוא עשה בדיוק מה שתוכנן: לסכם היסטוריה כדי לפנות מקום. הוא פשוט לא ידע שה-decision מסבב 8 חשוב יותר מ-14 רשומות enrichment. זה התפקיד שלך כבונה ה-harness: להגיד לו מה קריטי לפני שה-compaction מחליט בעצמו.

{
  "goal": "enrich leads from github stars",
  "decisions": [
    {"t": 1718800200.1, "text": "enterprise leads require human approval"}
  ],
  "deliverables": [],
  "constraints": []
}

Token Accounting — למדוד context בזמן ריצה

אי אפשר לנהל מה שלא מודדים. השלב הראשון הוא להפסיק לרוץ עיוור: בכל turn, נשלוף מתגובת ה-SDK את ספירת ה-tokens האמיתית. תגובת המודל כוללת שדה usage עם המספרים: input_tokens, output_tokens, ולעיתים cache_read_input_tokens ו-cache_creation_input_tokens. אלה הנתונים שמהם נחשב את אחוז השימוש.

# context_monitor.py — מדידת שימוש בכל turn
CONTEXT_WINDOW = 200_000      # התאם לחלון של המודל שלך
OUTPUT_BUFFER  = 33_000       # ה-Compaction Buffer (מקור: research)
COMPACT_AT     = 0.835        # סף ה-compaction האוטומטי
BACKUP_AT      = 0.75         # הסף שלנו — לפני ה-compaction

def usable_history_budget():
    # מה שבאמת זמין ל-history, אחרי ניכוי ה-buffer
    return CONTEXT_WINDOW - OUTPUT_BUFFER   # = 167,000

def context_usage(response):
    u = response.usage
    used = u.input_tokens + u.output_tokens
    pct_of_window = used / CONTEXT_WINDOW
    pct_of_usable = used / usable_history_budget()
    return {
        "input": u.input_tokens,
        "output": u.output_tokens,
        "cache_read": getattr(u, "cache_read_input_tokens", 0),
        "used": used,
        "pct_window": round(pct_of_window * 100, 1),
        "pct_usable": round(pct_of_usable * 100, 1),
        "approaching_compaction": pct_of_window >= COMPACT_AT,
        "should_backup": pct_of_window >= BACKUP_AT,
    }

עכשיו מחברים את זה ללולאה מפרק 2. בכל סבב, אחרי שקיבלנו תגובה מהמודל, נקרא ל-context_usage() ונדפיס שורת מצב. זו השכבה הראשונה: עיניים. בלי לשנות שום התנהגות — רק לראות.

# בתוך לולאת ה-agent מפרק 2
for turn in range(max_turns):
    response = call_model(messages)        # הקריאה הקיימת שלך
    ctx = context_usage(response)

    flag = "🟢"
    if ctx["should_backup"]:           flag = "🟡"
    if ctx["approaching_compaction"]:  flag = "🔴"
    print(f"{flag} turn {turn}: {ctx['used']:,} tok "
          f"({ctx['pct_window']}% window / {ctx['pct_usable']}% usable)")

    # ... המשך הלולאה הקיים: parse tool_use, execute, append tool_result ...

def format_ctx_bar(pct: float, width: int = 10) -> str:
    """Returns an ASCII progress bar representing context usage.

    Examples:
      format_ctx_bar(11.3)  ->  '[█░░░░░░░░░] 11%'
      format_ctx_bar(76.2)  ->  '[████████░░] 76%'
      format_ctx_bar(83.7)  ->  '[████████░░] 84% ⚠'
    """
    filled = int(pct / 100 * width)
    bar = "█" * filled + "░" * (width - filled)
    warn = " ⚠" if pct >= 83.5 else ""
    return f"[{bar}] {int(pct)}%{warn}"

# דוגמת שימוש בלולאה:
# ctx = context_usage(response)
# print(f"turn {turn}: {format_ctx_bar(ctx['pct_window'])} "
#       f"({ctx['used']:,} tok)")

turn  5: [█░░░░░░░░░] 11% (22,600 tok)
turn 15: [████░░░░░░] 47% (95,400 tok)
turn 25: [████████░░] 76% (152,400 tok)  ← 🟡 backup triggered
turn 26: [████████░░] 84% ⚠ (167,400 tok) ← 🔴 compaction!

תרגיל 1 — בנה את ה-context-monitor

🟢 turn  1:   3,240 tok ( 1.6% window /  1.9% usable)
🟢 turn  4:  18,450 tok ( 9.2% window / 11.0% usable)
🟡 turn  9: 152,600 tok (76.3% window / 91.3% usable)
🔴 turn 10: 168,200 tok (84.1% window / 100.7% usable) ← compaction!

Compaction אוטומטי מול מבוקר

עכשיו שאתה רואה את ה-context, השאלה הבאה היא: כשמתקרבים לסף — מי מחליט מה נשאר? יש שתי גישות, והן שונות מהותית:

החוכמה היא לא לבחור אחד מהם בלעדית, אלא לשלב: ה-compaction האוטומטי נשאר כרשת ביטחון של מוצא אחרון (אם משהו השתבש ועברנו 83.5% בכל זאת — שלא נקרוס). אבל אנחנו מקדימים אותו עם threshold-backup מבוקר ב-75%: עוד לפני שה-SDK נוגע בהיסטוריה, אנחנו כבר שמרנו את ה-state הקריטי ל-store חיצוני. כך, גם אם ה-compaction האוטומטי "ימחק" decision מההיסטוריה הפעילה — יש לנו עותק בטוח שאפשר להחזיר.

אסטרטגיית Context — מה תמיד-נשמר, מה מסוכם, מה נזרק

לפני שכותבים קוד, צריך החלטה: מה ב-context מקבל איזה יחס. כל פיסת מידע בהיסטוריה שייכת לאחת משלוש קטגוריות, וזה ה-deliverable השלישי שלך — טבלת אסטרטגיית context:

תמיד-נשמר: ארבעת הדברים שלעולם לא נזרקים

הקטגוריה הקריטית ביותר. ארבעה סוגי מידע שאם הם נמחקים — הריצה נשברת:

• ה-goal — המשימה המקורית. סוכן ששכח מה הוא אמור לעשות הוא חסר ערך.
• decisions — כל החלטה לוגית שהתקבלה במהלך הריצה ("enterprise → human approval"). אלה הכללים שהסוכן בנה לעצמו תוך כדי.
• deliverables — תוצרים, גם חלקיים. קוד שנכתב, רשימה שנבנתה, החלטות ביניים שכבר materialized.
• constraints — מגבלות ו-policies שחלות על הריצה. אלה לרוב יושבים ב-system prompt (שלא נדחס), אבל constraints שנוצרו דינמית צריכים שמירה מפורשת.

distillation: לסכם בלי לאבד את הקריטי

Distillation (זיקוק) הוא להחליף 20 הודעות ישנות בסיכום אחד קצר. זה חזק — אבל מסוכן אם נעשה עיוור. הכלל: סכם רק את ה"איך", שמור תמיד את ה"מה". אפשר לזקק את כל ה-steps שעשית כדי למצוא 3 endpoints ללא טסט — אבל את העובדה שמצאת בדיוק את X, Y, Z (deliverable) אסור לזקק. הסיכום מחליף את התהליך, לא את התוצאה.

הנה ההבחנה ב-before/after קונקרטי (דוגמה מייצגת):

שים/י לב מה נשמר ומה נזרק: התהליך (40 קבצים, ה-grep-ים, הבדיקות אחת-אחת) נזרק — אפשר לשחזר אותו אם צריך. התוצאה (שלושת ה-endpoints המדויקים) נשמרה מילה-במילה. אם הסיכום היה כותב "נמצאו 3 endpoints ללא טסט" בלי השמות — זה היה distillation גרוע: הוא איבד את ה-deliverable. הכלל המעשי: אחרי שכתבת סיכום, שאל את עצמך — "האם הסוכן יכול להמשיך לעבוד רק מהסיכום הזה?" אם הוא צריך לחזור לחומר המקורי כדי לדעת מה לעשות הלאה, הסיכום מחק משהו קריטי.

[tool: apollo_enrich]
{"lead_id": "gh-4821", "endpoint": "/api/v2/people/search", "status": 200,
 "company_size": "enterprise", "email": "tal@acme.com", "title": "VP Eng",
 "linkedin": "linkedin.com/in/tal-acme", "github_stars": 1240,
 "last_active": "2024-11-03"}

Scratchpad — להוציא state כבד מה-context

ה-scratchpad (פנקס עבודה / working memory) הוא הפתרון לקטגוריה השלישית. במקום להחזיק חומר גולמי כבד ב-context, שומרים אותו ל-store חיצוני — קובץ, KV store, או דאטהבייס — ומחזירים ל-context רק reference: כתובת + מטא-דאטה קצר. הסוכן יודע שהמידע קיים ואיפה הוא, ויכול לבקש tool שיקרא חלק ממנו אם צריך — אבל החומר עצמו לא חונק את החלון.

# scratchpad.py — להוציא tool results כבדים מה-context
import json, hashlib, pathlib

SCRATCH = pathlib.Path("./scratch")
SCRATCH.mkdir(exist_ok=True)
THRESHOLD_CHARS = 4_000   # מעל זה — שומרים החוצה במקום ב-context

def maybe_offload(tool_name, result_text):
    if len(result_text) <= THRESHOLD_CHARS:
        return result_text                      # קטן — נשאר ב-context
    key = hashlib.sha1(result_text.encode()).hexdigest()[:10]
    path = SCRATCH / f"{tool_name}_{key}.txt"
    path.write_text(result_text, encoding="utf-8")
    lines = result_text.count("\n") + 1
    # מחזירים ל-context רק reference קצר במקום 50KB
    return (f"[OFFLOADED to {path} — {len(result_text):,} chars, "
            f"{lines:,} lines. Use read_scratch('{path}', start, end) "
            f"to read a slice.]")

def read_scratch(path: str, start: int = 0, end: int = 50) -> str:
    """Read a slice of an offloaded scratchpad file.

    Args:
        path:  Path as returned by maybe_offload() reference string.
               Must be under SCRATCH directory (validated below).
        start: First line to return (0-indexed, inclusive).
        end:   Last line to return (exclusive). Max 100 lines per call.

    Returns:
        The requested lines as a string, or an error message.

    Security: path must resolve inside SCRATCH — never use user-controlled
    data as path component. The sha1-based filenames from maybe_offload()
    are safe; never replace them with user-supplied strings.
    """
    p = pathlib.Path(path).resolve()
    if not str(p).startswith(str(SCRATCH.resolve())):
        return "[ERROR: path outside scratch directory — rejected]"
    if end - start > 100:
        end = start + 100   # enforce max slice size
    lines = p.read_text(encoding="utf-8").splitlines()
    slice_lines = lines[start:end]
    return "\n".join(slice_lines) + f"\n[lines {start}–{end} of {len(lines)}]"

Threshold-Based Backup — הקוד שמציל את ה-state

זה הלב של הפרק. ה-threshold-backup הוא hook בלולאה: כשה-monitor מסמן 🟡 (חצינו 75%), אנחנו שומרים את כל ה"תמיד-נשמר" ל-store חיצוני — לפני שה-compaction האוטומטי של 83.5% נורה. גם אם הדחיסה העיוורת תמחק decision מההיסטוריה הפעילה, יש לנו עותק בטוח, ואנחנו יכולים להזריק אותו חזרה ל-context בסבב הבא כתזכורת.

# critical_state.py — מה תמיד-נשמר + גיבוי מבוסס-סף
import json, pathlib, time

BACKUP = pathlib.Path("./scratch/critical_state.json")

# "תמיד-נשמר" — מתעדכן לאורך הריצה
critical = {"goal": None, "decisions": [], "deliverables": [], "constraints": []}

def record_decision(text):
    critical["decisions"].append({"t": time.time(), "text": text})

def record_deliverable(name, ref):
    critical["deliverables"].append({"name": name, "ref": ref})

def backup_critical_state():
    BACKUP.write_text(json.dumps(critical, ensure_ascii=False, indent=2),
                      encoding="utf-8")
    return BACKUP

def critical_state_reminder():
    # טקסט קצר להזרקה חזרה ל-context אחרי compaction
    decisions = "; ".join(d["text"] for d in critical["decisions"])
    delivs = "; ".join(f"{d['name']}->{d['ref']}" for d in critical["deliverables"])
    return (f"[CRITICAL STATE] goal: {critical['goal']} | "
            f"decisions: {decisions} | deliverables: {delivs}]")

# בתוך לולאת ה-agent
backed_up_this_phase = False

for turn in range(max_turns):
    response = call_model(messages)
    ctx = context_usage(response)

    # 🟡 חצינו 75% — גבה state קריטי לפני ה-compaction של 83.5%
    if ctx["should_backup"] and not backed_up_this_phase:
        backup_critical_state()
        backed_up_this_phase = True
        print(f"🟡 backed up critical state at {ctx['pct_window']}%")

    # 🔴 אחרי ש-compaction אוטומטי קרה — הזרק תזכורת חזרה
    if ctx["approaching_compaction"]:
        messages.append({"role": "user",
                         "content": critical_state_reminder()})
        backed_up_this_phase = False   # אפס לקראת מחזור compaction הבא

    # ... המשך הלולאה: parse tool_use, execute, append tool_result ...

תרגיל 2 — בנה את ה-threshold-backup

{
  "goal": "enrich leads from github stars",
  "decisions": [
    {
      "t": 1718800200.1,
      "text": "enterprise leads require human approval"
    }
  ],
  "deliverables": [],
  "constraints": []
}

Context Budget per Turn — כמה "מותר" ל-tool result אחד

ראינו שתוצאת tool ענקית מסוכנת. אבל איך גודרים את זה שיטתית? קובעים context budget per turn — תקרה לכמה context מותר לאובייקט בודד לצרוך. הכלל פשוט: כל tool_result שעובר את התקרה (למשל 4,000 tokens) חייב לעבור דרך ה-maybe_offload מהסעיף הקודם. כך אף קריאה בודדת לא יכולה להפיל את הריצה.

אינטראקציה עם max-turns — שני הבלמים יחד

בפרק 2 הכרת את ה-max-turns כבלם הראשון נגד לולאות אינסופיות. עכשיו יש לך בלם שני: ניהול context. חשוב להבין איך הם עובדים יחד, כי הם מגינים מפני שתי סכנות שונות אבל קשורות:

הקשר ביניהם: ריצה ארוכה יותר = יותר turns = יותר לחץ context. ככל שמעלים את max-turns כדי לאפשר משימות מורכבות, כך גדל הסיכוי שתפגוש את סף ה-compaction. לכן השניים לא עצמאיים: כשאתה מאשר ל-harness לרוץ 100 סבבים, אתה חייב ניהול context, אחרת ה-100 הסבבים האלה יגררו compaction עיוור באמצע. הכלל: max-turns גבוה ⟸⟹ ניהול context חזק. לא מעלים אחד בלי השני.

מדידה לפני אופטימיזציה — אל תסבך לפני שבדקת

זה אולי הסעיף החשוב ביותר, וקל לפספס אותו בהתלהבות מהקוד. אל תבנה compaction strategy מתוחכמת לפני שמדדת כמה context הריצה הטיפוסית שלך באמת צורכת. הרבה בונים מסבכים את ה-harness עם distillation, offload ו-backup — בשביל משימות שבכלל לא מתקרבות ל-75%. זו הנדסת-יתר: קוד מורכב יותר, יותר באגים, אפס תועלת.

הסדר הנכון:

1. מדוד — הרץ 3–5 משימות טיפוסיות עם ה-context-monitor (תרגיל 1). רשום את ה-pct_window המקסימלי בכל אחת.
2. סווג — אם הריצות הטיפוסיות נשארות מתחת ל-50%, אתה לא צריך כלום מעבר ל-monitor. אם הן נוגעות ב-70%+, אתה צריך backup. אם tool בודד קופץ אותך ל-80%, אתה צריך offload.
3. בנה רק את מה שהמדידה דורשת — לא יותר.

תרגיל 3 — טבלת אסטרטגיית ה-context שלך

תרגיל 4 — מבחן עומס: שבור והצל

שגרת עבודה — איך לעבוד עם context בכל harness מעכשיו

בדוק את עצמך

טעויות נפוצות — סיכום

סיכום הפרק וגשר לפרק הבא

צ'קליסט הפרק

סמן/סמני כל פריט כשהשלמת אותו. הפרק לא "נגמר" עד שכל התיבות מסומנות:

• הבנתי שחלון ה-context הזמין ל-history הוא החלון פחות ~33K buffer, לא החלון המלא.
• אני יכול/ה להסביר מה זה Compaction Buffer Trap ולמה compaction אוטומטי הוא lossy ועיוור.
• בניתי context_monitor.py עם context_usage() שמחזיר input/output/אחוזים/דגלים.
• חיווטתי את ה-monitor ללולאה מפרק 2 וראיתי דגלי 🟢/🟡/🔴 בריצה אמיתית.
• מדדתי 3–5 ריצות טיפוסיות ורשמתי את ה-pct_window המקסימלי לפני שבניתי אופטימיזציה.
• הגדרתי את ארבעת ה"תמיד-נשמר": goal, decisions, deliverables, constraints.
• כתבתי את טבלת אסטרטגיית ה-context (תמיד-נשמר / מסוכם / נזרק) למשימה אמיתית (תרגיל 3).
• בניתי scratchpad.py עם maybe_offload שמוציא tool results כבדים ל-store חיצוני ומחזיר reference.
• קבעתי context budget per turn והגדרתי תקרה ל-tool result בודד.
• בניתי critical_state.py עם threshold-backup שרץ ב-75% (לפני 83.5%).
• חיווטתי את ה-backup hook ללולאה: שמירה ב-🟡, הזרקת תזכורת ב-🔴.
• הרצתי stress test (תרגיל 4): baseline "שכח" מול מוגן "זכר" — ושמרתי את שני הלוגים.
• וידאתי ש-critical_state.json נכתב ומכיל decisions שרדו את ה-compaction.
• סנכרנתי את ה-max-turns עם ניהול ה-context — לא העליתי אחד בלי השני.
• אני מוכן/ה לפרק 4: ה-context management הזה הוא הבסיס ל-structured tools, MCP ו-governance.