תוצאת 76x ב-Browser-A של GPT-6.1 Sol: מה Asana בעצם מדדה

Asana פרסמה מחקר עלויות של סוכן דפדפן ב-8 באוקטובר 2026, ומפתח GPT-6.1 Sol כתב על כך למחרת תחת הכותרת "Asana חותכת עלויות מודל פי 76 בבדיקות דפדפן עם GPT-6.1 Sol." ה-76x הוא אמיתי במובן שמישהו מדד אותו, אבל זו לא עובדה על המחיר של GPT-6.1 Sol. זו עובדה על מה שקורה כשמתקנים מטמון פרומפט שבור בסוכן דפדפן ואז מחליפים את המודל שיושב מאחוריו. אותה אופטימיזציה, כשהיא רצה על המודל שכבר היה ל-Asana בפרודקשן — מודל שהיא מכנה מודל B — חתכה עלויות פי 29 בעצמה. GPT-6.1 Sol סיפק את ה-2.6x הנותרים. הניסויים בוצעו על ידי GPT-6 Astra שעבד ב-Codex, והמודל שמאחורי קו הבסיס הוא מודל של מתחרה ש-Asana מכנה מודל B, כך ששתי שכבות מאותו ספק ומתחרה אחד ללא שם מופיעים כולם בסיפור. מה שלהלן מפריד בין החלק של התוצאה שאפשר להעתיק ביום שני לבין החלק ששייך לסטאק המסוים של Asana.

ההשוואה, בניסוח מדויק

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

התכנון היה שישה מדיניויות מטמון וצילום מסך בשני תקציבי היסטוריה, שלוש הרצות לכל תנאי, על פני ארבעה מודלים — 144 הרצות, ובנוסף הרצת המשך בת 12. העלויות חושבו ממוני הטוקנים של כל ספק, וכל תשובה נוקדה מול תשובת ייחוס שהוכנה באופן בלתי תלוי. ארבעת המודלים היו שלושה מודלי חזית ללא שם (מודל A, B ו-C) ו-GPT-6.1 Sol. מודל A הוא מודל קטן וזול יותר ממעבדה אחרת, שיצא בסתיו 2025, במחיר של מחצית מ-GPT-6.1 Sol. מודל B הוא המודל שהיה בפרודקשן, מאותה מעבדה כמו A, שיצא בקיץ 2026, במחיר זהה ל-GPT-6.1 Sol. מודל C הוא גרסה חדשה יותר של מודל B, שיצאה בסתיו 2026, וגם מחירה זהה ל-GPT-6.1 Sol. שלושתם אינם נקובים בשם בשתי הכתבות, כך שההשוואה אינה ניתנת לשחזור על ידי הקורא — כדאי לדעת זאת לפני שאתם מתייחסים ל-29x כמספר על המודל של מישהו אחר. אלה המספרים המפורסמים של Asana ו-OpenAI, ולא מספרים שנבדקו באופן בלתי תלוי.

סולם התוצאות, כולם מספרים של Asana עצמה:

• תפוקת בסיס ב-Model B — לפחות $36.21 לכל הרצה, לפחות 22.5 דקות לכל הרצה. חלק מהרצות הבסיס הגיעו למגבלת הצעדים לפני שסיימו, כך שהממוצע הוא רצפה ולא ממוצע אמיתי.

• Model B, סוכן מאופטם — 1.24 דולר להרצה, מהיר פי 4 מקו הבסיס, קיצוץ עלות של פי 29.

• GPT-6.1 Sol, אותו סוכן אופטימלי — $0.47 לכל ריצה, כארבע דקות, קיצוץ עלות של פי 76 ופי 5 מהיר יותר.

• GPT-6.1 Sol, לפני לעומת אחרי התיקון — מ-$1.97 ל-$0.47 לכל הרצה, קיצוץ של פי 4 משינויים במטמון ובגיזום בלבד.

מכיוון שהבסיס הוא חסם תחתון, גם 76x הוא רצפה. הקריאה הכנה היא "לפחות 76x", לא "76x".

מה באמת השתנה, ולמה זה לא מאפיין של המודל

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

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

לתיקון שני חצאים. ראשית, יש לשמור גם את ההיסטוריה במטמון, עם סמן מטמון על תוצאת הכלי האחרונה. שנית, יש להפסיק לערוך אותה בכל קריאה: לשמור צילומי מסך ולגזום אותם בקבוצות ביחס של 20 ל־1, כך שהסוכן מחזיק עד 20 ואז מצטמצם אל האחרון ביותר. כך כ־19 קריאות רצופות עושות שימוש חוזר בקידומת שלא השתנתה. יש להעלות את תקציב ההיסטוריה מ־120,000 ל־480,000 תווים כדי שטקסט ישן יפסיק להיחתך, והחשבון מתאזן: ב־GPT-6.1 Sol, עלות כל קריאה הייתה נמוכה פי 3 בקירוב משום ש־89% מהקלט הגיעו מהמטמון.

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

היכן שבחירת המודל באמת השתלמה

הסירו את תיקון זרימת העבודה והשוו תפוחים לתפוחים: באותו סוכן מאופטם, GPT-6.1 Sol עלה פי 2.6 פחות מ-Model B, באותו מחיר מחירון. הגורם הנוסף הוא התנהגות פגיעת מטמון, לא המחירון. Sol קרא 89% מהקלט שלו מהמטמון; Asana אינה מפרסמת את השיעור המקביל עבור Model B, כך שה-2.6x הוא תוצאה מדודה ללא פירוק מפורסם. התייחסו לזה כ"המודל הזה, בעומס העבודה הזה, השתמש טוב יותר במטמון שלו", ולא כיתרון כללי של פי 2.6 לעומת מודל שאיננו יכולים לנקוב בשמו.

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

למי שמתמחר את זה: תעריפי ה-API הסטנדרטיים של GPT-6.1 Sol הם $2.00 למיליון אסימוני קלט, $0.10 למיליון אסימוני קלט במטמון ו-$10.00 למיליון אסימוני פלט, והנחת הקריאה מהמטמון שלו היא פי 0.05 מתעריף הקלט — העמוקה ביותר בלוח התעריפים הנוכחי של OpenAI. GPT-6 Astra, המודל שעשה את עבודת ההנדסה ב-Codex, עולה $10.00 בקלט ו-$50.00 בפלט, וזהו פער פי חמישה שעליו התבסס מסגור ההשקה של OpenAI. הסיבה שהמחקר הניב ריצות בעלות $0.47 ולא ריצות בעלות $2 היא לא לוח התעריפים; היא ש-89% מבקשה מאוד חזרתית חויבו בשיעור של 1/20 מתעריף הקלט. בסוכן עתיר מטמון, שורת ההנחה עושה יותר עבודה מאשר מחיר הכותרת, ובקטלוג שלנו מחירי המחירון של הספקים עוברים הלאה עם תוספת של 0%, כך שכאשר ספק מזיז מונה של קלט במטמון, הוא מזיז אותו בחשבון שלך באותו יום.

המספר האחר במחקר: תקציב ההיסטוריה הכריע אם הסוכן בכלל ענה

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

• בתקציב של 120,000 תווים, Model C לא השיב באף אחת מ-18 ההרצות שלו ו-GPT-6.1 Sol השיב ב-3 מתוך 18 — רוב ההרצות הגיעו למגבלת השלבים בלי להפיק תשובה.

• ב־480,000 תווים, כל ריצה על שני המודלים ענתה, כל אחת עם התשובה הנכונה.

• המודלים החדשים יותר שרפו את התקציב הקטן יותר מהר יותר: מודל C קיצץ לראשונה את ההיסטוריה שלו בקריאה 10, ומודל A בקריאה 64.

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

זו טענה שונה מ"זול יותר". תקציב היסטוריה קטן מדי על מודל מוכשר מייצר סוכן שנכשל מכך שנגמר לו המקום, והוא נכשל גם בכך שהוא פוגע בתקרת הצעדים, שזו הדרך היקרה ביותר להיכשל — אתה משלם על כל הריצה ולא מקבל דבר. העלאת התקציב העלתה את העלות לכל קריאה והפחיתה את העלות לכל תשובה, וזה המספר היחיד שבעל מערכת בפרודקשן צריך לעקוב אחריו. אם אתם מעריכים מודל לא מוכח עבור סוכן כזה, הדפוס בסיכון נמוך הוא להשאיר את נתיב הפרודקשן שלכם על המודל שאתם סומכים עליו ולהציב את החדש מאחורי failover או נתיב מפוצל, כך שכשל בגלל מגבלת צעדים יופיע כעובדת ניתוב ולא כתקרית. כל מודל בהשוואה הזו נגיש דרך API אחד ל-200+ מודלים כשתמחור המחירון של הספקים מועבר ללא שינוי, מה גם שהופך את הנחת קריאת המטמון להשוות בין ספקים באותה חשבונית במקום בחמישה לוחות בקרה.

מה לקחת מזה, לפי הסדר

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

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

• גיזום בקבוצות. בדיקת ההמשך של Asana מצאה ששמירה על כל צילום מסך עלתה פי 1.2 פחותלכל קריאה מאשר תנאי הגיזום הטובים ביותר ב-Model B וב-GPT-6.1 Sol, וכ-5% פחות ב-Model C. גיזום עדיין חשוב למשימות ארוכות, לחלונות הקשר קטנים ולקריאות מטמון יקרות — אך ההצדקה ליחס אצווה של 20:1 נוגעת ליציבות המטמון, ולא לצילומי המסך עצמם.

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

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

החלק שבאמת חדש, והחלק שלא

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