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

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

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

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

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

גרוע מזה, המייל מאחר. ב-AWS Budgets הנתונים מתעדכנים עד שלוש פעמים ביום, בדרך כלל 8 עד 12 שעות אחרי העדכון הקודם. בזמן הזה שירות שהסוכן העלה ושכח מספיק לחיות חצי יממה בלי השגחה.

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

איפה יש תקרת הוצאות קשיחה, ואיפה רק התראה

API של מודלים: תקרת הוצאות ב-OpenAI וב-Anthropic

ב-Anthropic התקרה קיימת בלי שתעשו כלום. לטירים Start, Build ו-Scale יש תקרה חודשית של $500, $1,000 ו-$200,000. הגעתם אליה, וה-API נעצר עד 00:00 UTC באחד בחודש הבא. אפשר להגדיר מגבלה משלכם מתחת לתקרת הטיר ב-Settings → Billing, בחלק Spend limits. שם גם אפשר, דרך workspaces, לתת מגבלה נפרדת לכל קבוצת מפתחות.

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

1. 1

   OpenAI: ארגון

   Organization limits → Spend → Edit spend limit. הזינו סכום חודשי והפעילו את Enforce a hard limit. בלי המתג הזה הסכום עובד כהתראה רגילה.

2. 2

   OpenAI: פרויקט

   Project settings → Limits → Spend → Edit spend limit, עם אותו מתג Enforce a hard limit. מגבלת פרויקט חלה רק על תעבורה שמחויבת לפרויקט הזה.

3. 3

   Anthropic: סכום משלכם

   Settings → Billing → Spend limits → Set limit או Adjust limit. אי אפשר להגדיר יותר מתקרת הטיר שלכם.

4. 4

   Anthropic: workspace נפרד לסוכן

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

החלק השימושי ביותר בתיעוד של שני הספקים הוא קודי השגיאה. סוכן שנתקע בתקרה יקבל 429, וה-SDK כברירת מחדל ינסה שוב. ב-Anthropic, בתקרת הטיר אין כותרת retry-after, וניסיונות חוזרים לא יעזרו עד תחילת החודש הבא. להבדיל בין התקרה ל-rate limit רגיל אפשר רק לפי הקוד:

# Anthropic, tier ceiling: HTTP 429
error.type = rate_limit_error
error.details.error_code = enforced_spend_limit_reached
# Anthropic, your own limit: HTTP 400
error.type = invalid_request_error
"You have reached your specified API usage limits..."
# OpenAI: HTTP 429
error.code = organization_spend_limit_exceeded
error.code = project_spend_limit_exceeded

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

AWS: spend limit לפרויקטים חדשים ו-budget actions לחשבונות קיימים

ב-16 בספטמבר AWS הכריזה על חוויה חדשה למפתחים, ובה סוף סוף מגבלה שעוצרת הוצאות. היא מוגדרת לפרויקט: AWS Settings → Billing → Cost by project → Set limit. הגעתם לסכום, AWS משהה את הפרויקט ועוצרת את כל המשאבים שלו עד סוף החודש. הנתונים נשמרים.

יש יותר הסתייגויות ממה שמופיע בהכרזה.

• את החוויה החדשה AWS מציעה לנסות דרך פתיחת חשבון חדש, ובתיעוד כתוב במפורש שהיא נפרסת למספר מוגבל של לקוחות. גם וויליסון שם לב לזה ומקווה לזמינות כללית.
• צריך תוכנית בתשלום. המגבלה המינימלית היא הגבוהה מבין $20 והערכה שמרנית של ההוצאות שלכם, וההערכה מתחשבת בחודש הקודם ובמשאבים שרצים. להגדיר $5 על פרויקט שכבר רצים בו instances לא יעבוד.
• אפשר להגדיר מגבלה לכל היותר ל-10 פרויקטים.
• אם לא עושים כלום עם פרויקט מושהה במשך 90 יום, AWS מוחקת את הנתונים שלו לצמיתות.

מצד שני, יש בקרות מוקדמות שמפעילים בנפרד, והן פועלות לפי תחזית. בערך 7 ימים לפני המגבלה מפסיקים לעלות משאבים חדשים, 5 ימים לפני מושהים משאבים לא פעילים, 4 ימים לפני מושהים היקרים ביותר מבין EC2, RDS, Lambda, Bedrock ו-SageMaker. הבקרה האחרונה בדיוק בשביל "ה-Lambda נכנסה ללולאה" ו"Bedrock פתאום האיץ".

אם יש לכם חשבון רגיל והכפתור החדש לא מופיע, האפשרות העובדת הקרובה היא budget actions ב-AWS Budgets. על סף אפשר לתלות פעולה: להחיל IAM policy או SCP חוסמים כדי ששום דבר חדש לא ייווצר, או לעצור instances מסוימים של EC2 ו-RDS. זו לא תקרה: Lambda, אחסון וכל מה שלא ברשימה ימשיכו להוציא, ונתוני התקציב עצמם, כזכור, מאחרים ב-8 עד 12 שעות. אבל לחשבון ניסויים שבו הסוכן משחק, עדיף ככה מאשר כלום.

Google Cloud Spend Caps: ארבעה שירותים וביטול ידני

Google הכריזה על Spend Caps ב-28 ביולי 2026. זה סוג חדש של תקציב: ב-Budgets & alerts בוחרים Create new budget, ואז Spend cap enforcement במקום Alerts only, ומציינים פרויקט, שירות וסכום. אי אפשר להפוך תקציב קיים ל-spend cap, רק ליצור חדש.

המגבלות של ה-Preview נוקשות:

• תקציב אחד הוא פרויקט אחד ושירות אחד, והתקופה רק חודשית.
• יש ארבעה שירותים: Gemini API, Gemini Enterprise Agent Platform (לשעבר Vertex AI), Cloud Run ו-Cloud Run functions.
• נחסמות רק קריאות חדשות. בקשות שכבר רצות יסתיימו ויחויבו. משאבים קבועים כמו כוח מחשוב ואחסון ממשיכים להצטבר בחשבון.
• אפשר להסיר את החסימה רק ידנית, בכפתור בקונסולה.

לשירותי AI ‏Google מבטיחה הפעלה תוך דקות. לסוכן שהעלה backend ל-Cloud Run ופונה ל-Gemini API, אלה שני תקציבים, וכדאי ליצור את שניהם.

Vercel ו-Supabase: מתג שצריך להפעיל בעצמכם

כאן נמצאת מלכודת הניסוח העיקרית. בספטמבר 2025 Vercel הודיעה ש-Spend Management מופעל כברירת מחדל בצוותי Pro חדשים. זה נשמע כמו תקרה קשיחה. אבל באותה הודעה כתוב שה-deployments ימשיכו לעבוד בלי הפסקה, כל עוד לא הוגדרה תקרה קשיחה ידנית. כברירת מחדל מקבלים מיילים ב-50%, 75% ו-100%.

כדי שהסכום באמת יעצור הוצאות, צריך להפעיל את Pause Production Deployments ב-Settings → Billing → Spend Management. אז כשמגיעים לסכום, Vercel תעצור את ה-production של כל הפרויקטים בצוות: אתרים, API ופונקציות לא יהיו זמינים עד שתפעילו כל פרויקט מחדש. הבדיקה רצה פעם בכמה דקות, ולכן Vercel עצמה ממליצה להגדיר סכום נמוך ממה שאתם מוכנים להפסיד. Spend Management זמין ב-Pro וב-Enterprise עם Flexible Commitment; ב-Hobby החינמי פרויקטים ממילא מושהים כשהמכסות החינמיות נגמרות.

ב-Supabase יש Spend Cap ב-Pro, והוא מנוהל ב-Cost Control בעמוד החיוב של הארגון. הוא מכסה דיסק, תעבורה, קריאות ל-Edge Functions, משתמשים פעילים ואחסון. הוא לא מכסה Compute, read replicas, שחזור לנקודת זמן ו-IPv4: את אלה מוסיפים בכוונה, ועליהם תחויבו בכל מקרה.

מה שאף תקרה לא תעצור

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

שנית: התקרה מגינה מפני החשבון, לא מפני מה שהסוכן עשה. היא לא תבטל שליחת מיילים לכתובות של אחרים ולא תסגור גישה שהסוכן פתח החוצה. איך זה נראה כשסוכן יוצא מגבולות ה-sandbox, פירקנו בתקרית ה-DNS ב-sandbox של OpenAI.

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

מה לעשות לפני שהסוכן מקבל מפתח

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

1. פרויקט או workspace נפרד לסוכן. פרויקט ב-OpenAI, workspace ב-Anthropic, פרויקט ב-AWS או ב-Google Cloud. המפתח של הסוכן מונפק רק שם, והמגבלה של המקום הזה נמוכה ממה שאתם מוכנים להפסיד בלילה אחד.
2. תקרה מתחת לגבול האמיתי. המגבלות נכנסות לפעולה באיחור. אם אתם מוכנים להפסיד $100, הגדירו $70–80. חשבו את הסכום לפי מחיר משימה, לא מחיר טוקן: למה הם שונים, רואים בהשוואה בין GPT-6 Sol ל-Opus 5.5 לפי עלות משימה.
3. קוד שעוצר בתקרה ולא מנסה שוב. קודי השגיאה מופיעים למעלה, והטיפול בהם הוא כמה שורות.
4. סוכן שבוחר ספקים עם תקרה. זה הרעיון של וויליסון עצמו: היה טוב אם סוכנים היו ממליצים בעצמם על שירותים עם תקרה קשיחה ומזהירים מתחילים מפני שירותים בלעדיה. עד שזה יקרה, אפשר לכתוב את הכלל בהנחיות הפרויקט, למשל ב-CLAUDE.md: "אל תעלה שום דבר בתשלום בלי תקרת הוצאות, ושאל קודם".

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