אמזון שרפה 1.8 מיליון דולר על משימה אחת — וגילתה אחרי חמישה חודשים

בישיבת צוות פנימית באמזון ב-28 ביולי 2026, מהנדסים בכירים הציגו לעובדים כמה מקרים של חריגות עלות בשימוש ב-AI. את התוצאה הם תיארו במילים “catastrophically expensive”. הסיפור פורסם לראשונה ב-Financial Times, ומאז רץ בכל אתרי הטכנולוגיה — לרוב עם כותרת שמפספסת את מה שבאמת קרה.

המקרה הגדול: פרויקט פנימי שהיה אמור להתאים אוטומטית פרטי מחברים לעמודי מוצר בחנות של אמזון, בנוי על Claude Sonnet. העלות הסופית הייתה 1.8 מיליון דולר, שהם 860% מעל התקציב שהוקצה לו. הפרויקט לא הושק מעולם.

והחלק שצריך לעצור עליו: החריגה לא התגלתה במשך חמישה חודשים.

שני מקרים נוספים, ותופעה שקוראים לה tokenmaxxing

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

ברקע יש פרט שקשה להתעלם ממנו. באמזון פעל לוח מובילים פנימי שדירג עובדים לפי נפח השימוש שלהם בכלי AI. חלק מהעובדים התחילו להעמיס משימות מיותרות על סוכנים כדי לטפס בו — נוהג שקיבל בפנים את הכינוי tokenmaxxing. הלוח נסגר במהלך 2026.

ומה אומרת אמזון? שמדובר בדוגמאות מבודדות, ושבחירה סלקטיבית שלהן לא מייצגת את האופן שבו צוותים בחברה עובדים עם AI; לפי התגובה, החברה “מתנסה, לומדת ומשתפרת” גם ביעילות העלות. שווה להחזיק את זה בפרופורציה: מדובר בחברה שמדווחת הכנסות רבעוניות בסדר גודל של מאה שמונים מיליארד דולר. 1.8 מיליון דולר הם רעש סטטיסטי עבורה — והם בדיוק לא רעש עבור מי שקורא את השורות האלה.

מה הכותרות מפספסות

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

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

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

המנגנון האמיתי: באג ששולח חשבונית במקום שגיאה

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

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

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

מה עושים עם זה בפועל

ארבעה דברים, וכולם זמינים היום:

• להריץ על פרוסה לפני שמשחררים על הכול: תיקייה אחת, מאה שורות, מדגם. זה בדיוק ההבדל בין הפרויקט של אמזון לבין ריצה שפויה — הם כיוונו לקטלוג מלא
• לתת לתקרות לעבוד בשבילכם: בworkflows בקלוד קוד יש התראה מובנית כשריצה מתזמנת יותר מ-25 סוכנים או צפויה לעבור 1.5 מיליון טוקנים, ואפשר להגדיר הנחיית גודל שתכוון לפחות סוכנים. שם גם רואים את מונה הטוקנים בזמן אמת, ואפשר לעצור באמצע
• לנתב עבודה מכנית למודל זול: סריקה, סינון והתאמות הן בדיוק סוג העבודה שלא צריכה את המודל היקר — סוכן משנה על מודל זול עושה אותה באותה איכות בשבריר מהמכסה
• לשים שער אנושי לפני כל דבר בלתי-הפיך: הכלל על אוטומציה עם בלמים נכתב כאן על נזק לנתונים, אבל הוא תקף בדיוק אותו דבר על נזק לארנק

שורה תחתונה

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

מי שרוצה להבין איך המכסה של קלוד קוד נספרת מלכתחילה — מדריך המחיר והמכסה. המקור: הדיווח ב-Financial Times.