מדריך: בקר הוצאות לכל ריצת סוכן עם Responses API של OpenAI

סוכני AI שרצים אוטונומית הם דבר נהדר, עד שמגיע החשבון בסוף החודש. ב-20 באוגוסט 2026 פרסמה OpenAI ב-Cookbook הרשמי שלה מתכון חדש בשם "Build a per-run spending controller with the Responses API", שמלמד בדיוק את מה שהרבה צוותים חיפשו: איך להצמיד תקציב נפרד לכל הרצת סוכן, ולעצור אותה לפני שהיא שורפת טוקנים בלי פיקוח. במדריך הזה נעבור על הרעיון, על אבני הבניין המרכזיות, ועל איך מיישמים את זה בפועל בצוות ישראלי שמריץ סוכנים בפרודקשן.

01מה OpenAI פרסמה ולמה זה שונה מהגבלת תקציב רגילה

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

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

02אבני הבניין: כך בונים את הבקר בפועל

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

1. הגדרת תקציב לריצה: כל משימה שנכנסת למערכת מקבלת מזהה ריצה (run ID) ותקרת הוצאה, בדולרים או בטוקנים.
2. מעטפת סביב הקריאה ל-API: פונקציה אחת שכל קריאות ה-Responses API עוברות דרכה, במקום קריאות ישירות מפוזרות בקוד.
3. מדידת שימוש: אחרי כל תשובה קוראים את נתוני ה-usage (טוקני קלט ופלט) ומתרגמים אותם לעלות לפי תמחור המודל שבו משתמשים.
4. אכיפה: לפני כל קריאה נוספת בודקים אם נותר תקציב. אם לא, עוצרים את הריצה ומחזירים תוצאה חלקית או הודעת כשל מסודרת.
5. תיעוד: כל ריצה נרשמת עם העלות הסופית שלה, מה שמאפשר לנתח אילו סוגי משימות יקרים במיוחד.

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

class RunBudget:
    def __init__(self, limit_usd: float):
        self.limit = limit_usd
        self.spent = 0.0

    def charge(self, usage, price_in, price_out):
        self.spent += (usage.input_tokens * price_in
                       + usage.output_tokens * price_out)

    def exceeded(self) -> bool:
        return self.spent >= self.limit


def guarded_call(client, budget, **kwargs):
    if budget.exceeded():
        raise RuntimeError("Run budget exceeded")
    resp = client.responses.create(**kwargs)
    budget.charge(resp.usage, PRICE_IN, PRICE_OUT)
    return resp

03למה זה חשוב במיוחד לצוותים בישראל

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

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

04צעד אחר צעד: כך מטמיעים את הדפוס אצלכם

1. פתחו את המתכון "Build a per-run spending controller with the Responses API" ב-Cookbook הרשמי של OpenAI ועברו עליו מקצה לקצה לפני שאתם כותבים קוד.
2. מפו את כל הנקודות בקוד שלכם שקוראות ל-Responses API, ואחדו אותן לפונקציית מעטפת אחת.
3. הגדירו מחלקת תקציב לריצה עם תקרה, מונה הוצאה ובדיקת חריגה, כמו בדוגמה למעלה.
4. עדכנו את מחירי הטוקנים של המודל שבו אתם משתמשים בקובץ קונפיגורציה, לא כקבועים מפוזרים בקוד, כדי שעדכון תמחור לא ידרוש שינוי לוגיקה.
5. החליטו מה קורה בחריגה: עצירה מיידית, החזרת תוצאה חלקית, או העברה לאישור אנושי. עבור סוכני פרודקשן, עצירה מסודרת עם לוג ברור עדיפה כמעט תמיד.
6. הריצו את הבקר בסביבת בדיקה עם תקרות נמוכות בכוונה, כדי לוודא שהמערכת נעצרת יפה ולא קורסת באמצע משימה.
7. רק בסוף, כווננו את התקרות האמיתיות על סמך נתוני עלות היסטוריים של ריצות מוצלחות.

05מה הלאה

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