Claude Code מקדיש שלושה רבעים מתקציב הטוקנים שלו רק לקריאת בסיס הקוד, על פי ניתוח של Red Hat של 219 סשנים מהעולם האמיתי. הממצא הופך את ההנחה הרגילה שסוכני תכנות מבוססי AI מבזבזים זמן על יצירת קוד, ומציע שמפתחים צריכים לתקוף את בעיית ניהול ההקשר (context-management), ולא רק את מהירות המודל.

הנתונים שמאחורי הטענה

Red Hat בחנה 219 אינטראקציות עם Claude Code של Anthropic וחישבה את השימוש בטוקנים לכל תור (turn). לאורך המדגם, החציון של התור הקצה 75% מהטוקנים להזנת הקוד והתיעוד הסובבים, בעוד שרק 25% הוקצו להפקת שורות חדשות. מכיוון שרוב ספקי ה-AI מחייבים על טוקני קלט ופלט באותו תעריף, החלק ה"קורא" של העסקה מניע את רוב העלות.

למה עלות הקריאה חשובה

אסטרטגיית אופטימיזציה

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

בקרת עלויות

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

מיקוד הנדסי

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

צעדים מעשיים לצמצום עומס הקריאה

  • גיזום קבצים לא רלוונטיים – הסרת קבצים שהמשימה הנוכחית אינה זקוקה להם מה-prompt. פרומפטים קטנים יותר משמעותם פחות טוקני קלט.
  • שמירה במטמון (Cache) של קריאות חוזרות – אחסון הפרשנות של המודל לחלקים יציבים בבסיס הקוד ושימוש חוזר בה לאורך תורים, במקום לשלוח שוב את הטקסט עצמו.
  • דחיסת פלטי כלים – כאשר כלים חיצוניים מחזירים גושי מידע גדולים (למשל, דוחות lint), סכמו אותם לפני שאתם מזינים אותם חזרה ל-Claude.
  • שימוש ב-diffs אינקרמנטליים – שליחת השינויים בלבד מאז התור האחרון במקום תוכן הקובץ המלא.

טקטיקות אלו נועדו למנוע מה-AI לקרוא מחדש את אותו צילום מצב (snapshot) של המאגר בכל אינטראקציה, מה שמפחית הן את השיהוי (latency) והן את העלות.

טיעון נגד: מהירות עדיין חשובה

חלק מהמפתחים טוענים שמודל מהיר יותר עדיין משמעותי מכיוון שהוא מפחית את השיהוי של 25% מהטוקנים שכן מיוצרים. בסביבות רגישות לשיהוי – כמו תוספים ל-IDE שחייבים להגיב באופן מיידי – כל מילישנייה קובעת. הפרופיל הדומיננטי של קריאה אינו מבטל את היתרון של מודל מהיר יותר; הוא פשוט מפחית את השפעתו היחסית.

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

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

שורה תחתונה: בתכנות בסיוע AI, השיפור הזול ביותר בביצועים מגיע מהזנת פחות מידע למודל, ולא מגרימת לו לכתוב מהר יותר. המספרים של Red Hat מציגים טיעון ברור: גזמו, שמרו במטמון וסכמו את ה-prompts שלכם, ותראו חיסכון מוחשי הן בזמן והן בכסף.