מה בעצם קונים כשמשלמים על מהירות?
מצב Ultrafast זמין כרגע רק עם המודל Astra, ומצטרף לשני מצבים שכבר היו קיימים: המצב הרגיל ומצב Fast. ההבטחה הרשמית ברורה: פי שמונה מהר יותר מהמצב הרגיל, ופי ארבעה מהר יותר ממצב Fast, עם קצב של עד 300 טוקנים בשנייה. זה קצב שאף אדם לא מסוגל לקרוא בו. ההדגמה הראשונה ממחישה את זה היטב: בקשה לסכם שיחת שאלות ותשובות של 54 דקות הסתיימה תוך 19 שניות, כולל איתור השיחה הנכונה, שליפת התמלול וכתיבת הסיכום.
אבל המהירות הזאת לא מגיעה לבד. המצב זמין רק במסלול החדש של 500 דולר בחודש, או דרך ה-API בתשלום לפי שימוש. מי שנמצא במסלול של 100 או 200 דולר לא יכול להפעיל אותו בכלל. ויש מחיר נוסף, פחות גלוי: כל משימה שרצה במצב המהיר אוכלת חלק גדול יותר מהמכסה השבועית. כלומר, השאלה האמיתית היא לא אם המצב מהיר, כי הוא מהיר, אלא כמה מהמכסה אתם מוכנים לשלם על כל דקה שנחסכת.
כדי לענות על השאלה הזאת, בהדגמה שהניתוח הזה מתבסס עליה הורצו שתי משימות שונות מאוד באופיין, כל אחת פעמיים עם אותו פרומפט בדיוק, פעם במצב הרגיל ופעם במצב המהיר. משימה אחת כבדה ומורכבת, עם הרבה קבצים והרבה החלטות, ומשימה אחת שגרתית יותר, מהסוג שעושים כמעט כל שבוע. ההשוואה בין שתיהן מלמדת הרבה יותר מהמספר השיווקי, כי היא מראה איך יחס המהירות ויחס העלות משתנים לפי סוג העבודה.
שלוש מהירויות, מודל אחד
חשוב להבין שמצבי המהירות לא מחליפים את המודל ולא את רמת החשיבה. זה אותו מודל, עם אותה רמת חשיבה שבחרתם, שרץ בקצב אחר ובמחיר אחר. ההבדלים בין שלושת המצבים נראים כך לפי מה שפורסם ולפי מה שנמדד בהדגמה:
Standard
- המצב הבסיסי, זמין בכל המסלולים.
- הצריכה הנמוכה ביותר מהמכסה השבועית.
- מתאים לעבודה שבה לא ממהרים לשום מקום.
Fast
- מצב הביניים, מהיר יותר מהבסיסי.
- צורך יותר מכסה, אבל לא בצורה דרמטית.
- בחירה יומיומית סבירה למי שעובד באינטראקציה.
Ultrafast
- עד 300 טוקנים בשנייה, פי שמונה מהבסיסי.
- רק במסלול של 500 דולר או דרך ה-API.
- זמין כרגע רק עם Astra, ובקרוב גם עם Soul.
מה המספר השיווקי אומר, ומה הוא לא אומר?
המספר "פי שמונה" מתאר את קצב יצירת הטקסט: כמה טוקנים המודל מוציא בשנייה. אבל משימה אמיתית של סוכן קוד היא לא רק כתיבת טקסט. היא כוללת קריאת קבצים, הרצת כלים, המתנה לפקודות, עיבוד מדיה, בדיקות, ולפעמים עשרות סבבים של חשיבה ותיקון. החלקים שתלויים בקצב היצירה מתקצרים דרמטית. החלקים שתלויים בכלים חיצוניים, כמו רינדור וידאו או סריקה של תיקייה ענקית, לא בהכרח מתקצרים באותו יחס. לכן משימה מורכבת כמעט אף פעם לא תגיע ליחס המלא שמופיע בהכרזה.
זה בדיוק מה שקרה בהדגמה. במשימה הכבדה המצב המהיר סיים בערך פי 2.5 מהר יותר מהמצב הרגיל, רחוק מאוד מפי שמונה. במשימה השגרתית, שבה רוב הזמן הוא כתיבה וחשיבה ולא עבודה מול קבצים כבדים, היחס הגיע לסביבות פי שבעה, כלומר קרוב מאוד להבטחה. המסקנה המעשית פשוטה: ככל שהמשימה "טקסטואלית" יותר, תקבלו יותר מההבטחה. ככל שיש בה יותר כלים ויותר עבודה מול קבצים, היחס יורד.
יש גם נקודה שקל לפספס: 300 טוקנים בשנייה זה מהר יותר ממה שאתם מסוגלים לקרוא. אם אתם יושבים מול המסך ועוקבים אחרי מה שהסוכן עושה, חלק מהיתרון פשוט הולך לאיבוד, כי צוואר הבקבוק עובר אליכם. המהירות הזאת מועילה בעיקר כשאתם מחכים לתוצאה סופית ולא קוראים את התהליך, או כשהתוצאה צריכה להגיע לפני שתספיקו לסיים כוס קפה.
מהירות ומכסה הם שני מטבעות שונים
המסלול של 500 דולר מגיע עם מכסה שבועית גדולה, אבל היא עדיין סופית. כל אחוז שהמצב המהיר שורף הוא אחוז שלא יהיה זמין בהמשך השבוע, גם לא במצב הרגיל. לכן ההשוואה הנכונה היא לא "דולרים מול דקות", אלא "אחוזי מכסה מול דקות". משימה שחוסכת חצי שעה ועולה 13 אחוזים נוספים מהמכסה השבועית היא החלטה כלכלית, לא רק טכנית, וכדאי לקבל אותה בכוונה ולא כברירת מחדל.
איך נראו שני המבחנים, צעד אחר צעד?
שני המבחנים נבנו כך שההבדל היחיד בין שתי הריצות יהיה מצב המהירות: אותו מודל, אותה רמת חשיבה גבוהה במיוחד, אותו פרומפט ואותם קבצים. כך אפשר לייחס את ההבדלים בזמן, בעלות ובאיכות למצב עצמו ולא למשהו אחר. כך הם נראו:
מבחן 1, סרטון תדמית של 60 שניות מחומר גלם עצום
המשימה הייתה לבנות סרטון תדמית אנכי של 60 שניות, ביחס 9×16 שמתאים לרשתות החברתיות, מתוך ביקור בקמפוס של חברת טכנולוגיה גדולה. הסוכן קיבל שני קבצים של כ-11 דקות דיבור ורפלקציה על הביקור, ותיקייה של יותר מ-145 ג'יגה של צילומי גלם. הוא היה צריך לעבור על כל החומר, לבחור קטעים ולספר מהם סיפור קוהרנטי. המצב המהיר סיים בכ-19 דקות ושרף 17 אחוזים מהמכסה השבועית. המצב הרגיל רץ כ-50 דקות ושרף 4 אחוזים בלבד.
ההפתעה הייתה באיכות. דווקא הגרסה המהירה סיפרה סיפור טוב יותר והרגישה מותאמת יותר למותג של המקום. הגרסה הרגילה חתכה את הדובר באמצע משפטים, מה שגרם לה להרגיש לא טבעית, והרגישה כאילו נכתבה על ידי מודל חלש יותר, למרות שרצה הרבה יותר זמן.
מבחן 2, מדריך משאבים מתוך סרטון
המשימה השנייה שגרתית יותר: להפוך סרטון שמשווה בין שני סוכנים אישיים למדריך משאבים מסודר, בעזרת סקיל קבוע שמגדיר את המבנה והמיתוג. המצב הרגיל לקח 13 דקות ושרף אחוז אחד מהמכסה. המצב המהיר סיים בדקה ו-43 שניות ושרף 3 אחוזים. שני המדריכים יצאו באורך שבעה עמודים, עם מבנה כמעט זהה, כולל כלל החלטה, השוואה של זיכרון והקשר אישי, ותובנות מרכזיות בסוף.
כאן ההבדל באיכות היה זניח, ואם כבר, לטובת המצב הרגיל: הגרסה שלו כללה גם קישורים שימושיים למקורות הרשמיים, ולא רק לסרטון עצמו. אף אחד מהמדריכים לא היה גרוע משמעותית מהשני, ושניהם היו ראויים לפרסום כמעט בלי עריכה. שתי הגרסאות היו ברמה דומה מאוד, כך שהשאלה הייתה רק אם 11 דקות חיסכון שוות פי שלושה מכסה.
למה המשימה הכבדה עלתה פי ארבעה מכסה?
כשמסדרים את המספרים זה לצד זה, מתגלה דפוס ברור. במשימה הכבדה המצב המהיר חסך בערך 31 דקות, אבל צרך פי 4.25 יותר מכסה. במשימה השגרתית הוא חסך כ-11 דקות, וצרך פי שלושה מכסה, אבל במספרים מוחלטים מדובר בשני אחוזים נוספים בלבד. ההבדל בין שתי המשימות הוא לא רק ביחס, אלא בסדר הגודל: אחוז או שניים נוספים זה משהו שאפשר לספוג מדי פעם, 13 אחוזים נוספים על משימה אחת זה כבר חלק משמעותי מהשבוע.
# same prompt, same model, same reasoning level
task: 60s vertical showreel (145GB raw footage)
standard: ~50 min 4% weekly usage
ultrafast: ~19 min 17% weekly usage
speedup: ~2.5x usage: ~4.25x
task: resource guide from one video (same skill)
standard: 13 min 1% weekly usage
ultrafast: 1m43s 3% weekly usage
speedup: ~7x usage: ~3xהכלל שעולה מההדגמה: במשימות קטנות, שלא דורשות הרבה קלט, הרבה חשיבה והרבה סבבי אימות, המכפיל של צריכת המכסה נע בערך בין פי שניים לפי ארבעה. ככל שהמשימה גדלה ומסתבכת, המכפיל הזה גדל איתה ואוכל יותר ויותר מהמכסה. לכן דווקא המשימות שבהן הייתם הכי רוצים לחסוך זמן, הארוכות והמורכבות, הן אלה שבהן המהירות הכי יקרה ונותנת את היחס הכי פחות טוב מול ההבטחה.
יש כאן גם שיעור על איכות. ההנחה הטבעית היא שאותו מודל עם אותה רמת חשיבה ייתן תוצרים דומים בשני המצבים, אבל במבחן הכבד התוצרים היו שונים מאוד. כנראה שחלק מזה הוא פשוט שונות טבעית בין ריצות, שקיימת גם כשמריצים את אותו מצב פעמיים. המשמעות המעשית היא שאסור להסיק מסקנה על איכות ממבחן אחד. מי שרוצה להשוות מצבים או הגדרות באמת צריך כמה ריצות לכל צד, בדיוק כמו בבחירה בין רמות מאמץ שונות של אותו מודל, שבה ההבדלים בין ריצה לריצה יכולים להיות גדולים מההבדלים בין ההגדרות עצמן.
איך מחליטים מתי למשוך בידית המהירות?
המסקנה של ההדגמה היא שהמצב המהיר הוא ידית חירום, לא דרך עבודה. הוא מצוין כשאתם באמת בלחץ זמן, למשל חמש דקות לפני פגישה, וצריכים תוצר מוכן עכשיו. ברוב שאר הזמן, במיוחד במשימות מורכבות, עדיף לתת לסוכן לרוץ בקצב הרגיל ולהשתמש בזמן הזה לדברים אחרים. מי שעובד באופן איטרטיבי, נותן לסוכן לרוץ, בודק ומשפר, בדרך כלל לא מרוויח הרבה ממהירות קיצונית, כי הוא ממילא לא יושב ומחכה לכל תשובה.
יש גם שאלה של מסלול. אם אתם כל הזמן נתקעים בגבול המכסה של המסלולים הזולים, ייתכן שהמעבר למסלול של 500 דולר משתלם בזכות המכסה הגדולה, והמצב המהיר הוא בונוס שטוב לדעת שקיים. אבל לשדרג רק בשביל המצב המהיר, כשהשימוש שלכם לא מצדיק את המכסה, זו החלטה שקשה להצדיק. מי שעוד בוחן אם הכלי בכלל מתאים לצרכים שלו יכול להתחיל מסקירה מלאה של Codex, שמסבירה את היכולות והמגבלות שלו גם בלי קשר למצבי המהירות.
הכלי הכי טוב לקבלת ההחלטה הוא מדידה. מי שמריץ סוכני קוד באופן קבוע, בצוות או בעסק, כדאי שיתעד כמה זמן לוקחת כל משימה ואיזה חלק מהמכסה היא צורכת, לפי סוג המשימה ולפי המצב. אחרי כמה שבועות כבר רואים איפה המהירות שווה משהו ואיפה היא סתם בזבוז. ארגון שמנהל כמה מנויים במקביל ירוויח מדשבורד ניהולי שמרכז את נתוני השימוש והעלויות במקום אחד, כך שההחלטה על מסלול ועל מצב עבודה תתבסס על נתונים ולא על תחושה.
למה לחץ זמן הוא בעיה של מערכת, לא של מודל?
הטענה המעניינת ביותר בהדגמה היא דווקא לא על המצב המהיר עצמו. אם אתם מוצאים את עצמכם צריכים אותו לעתים קרובות, כנראה שהבעיה היא לא במהירות של המודל, אלא בכך שהעבודה מגיעה לסוכן מאוחר מדי. במקום לשלם פי ארבעה מכסה כדי לסיים משהו ברגע האחרון, עדיף לבנות מערכות שמכינות את העבודה מראש: סיכום שיחות שרץ מיד כשהתמלול מוכן, הכנת חומרים לפגישה שמתחילה יום קודם, או דוחות שמופקים בלילה.
הדוגמה של סיכום שיחת 54 הדקות ממחישה את זה היטב. זה מרשים שהמצב המהיר עושה את זה ב-19 שניות, אבל משימה כזאת יכולה לרוץ באופן אוטומטי ברגע שהשיחה מסתיימת, במצב הרגיל, בעלות נמוכה, בלי שמישהו יחכה לה בכלל, והסיכום יחכה בתיבת הדואר או במערכת המשימות כשתגיעו אליו. כשהתוצאה כבר מחכה לכם, לא משנה אם הסוכן עבד עליה חצי דקה או רבע שעה. המהירות חשובה רק כשמישהו יושב מול המסך ומחכה.
גם מצב Fast הרגיל ראוי להתייחסות. בהדגמה הוא תואר ככלי יומיומי שמשתמשים בו הרבה, בלי שהצריכה שלו מרגישה חריגה, כולל עם מודלים זולים יותר כמו Soul. זה כנראה האיזון הנכון לרוב האנשים: מצב ביניים לעבודה אינטראקטיבית, מצב רגיל למשימות ארוכות שרצות ברקע, והמצב הקיצוני רק כשהגב באמת לקיר. כשהמצב המהיר יגיע גם למודל Soul, שהוא זול יותר, ייתכן שהחשבון ישתנה, כי המכפיל יחול על בסיס נמוך יותר.
מתי המצב המהיר שווה את המכסה, ומתי לא?
לפני שמפעילים את המצב המהיר, כדאי לעבור על שתי הרשימות האלה. הן מבוססות על הדפוס שעלה משני המבחנים: יחס טוב במשימות קצרות וטקסטואליות, ויחס גרוע במשימות כבדות שעובדות מול הרבה קבצים וכלים.
שווה להפעיל
- יש דדליין אמיתי בעוד דקות ולא בעוד שעות.
- המשימה טקסטואלית: סיכום, מסמך, מדריך.
- אין הרבה קבצים כבדים או כלים חיצוניים.
- המכסה השבועית רחוקה מהגבול.
- אתם יושבים מול המסך ומחכים לתוצאה.
עדיף לוותר
- עיבוד וידאו או תיקיות ענק של קבצים.
- משימה שרצה ממילא ברקע או בלילה.
- עבודה איטרטיבית עם הרבה סבבי תיקון.
- המכסה כבר קרובה לגבול השבועי.
- מקווים שמהירות תשפר את האיכות.
חמש תובנות על מצב Ultrafast
היחס תלוי בסוג המשימה
במשימה שגרתית וטקסטואלית המהירות הגיעה לפי שבעה, קרוב להבטחה. במשימה כבדה עם 145 ג'יגה של וידאו היא הגיעה רק לפי 2.5, כי חלק גדול מהזמן לא תלוי בקצב יצירת הטקסט.
העלות גדלה עם המורכבות
במשימות קטנות המכפיל של צריכת המכסה נע בין פי שניים לפי ארבעה. במשימה המורכבת הוא הגיע לפי 4.25, כלומר דווקא איפה שהכי רוצים לחסוך זמן, המהירות הכי יקרה.
ריצה אחת לא מוכיחה איכות
באותו מודל ובאותה רמת חשיבה התוצרים יצאו שונים מאוד. שונות בין ריצות קיימת תמיד, ולכן השוואת איכות רצינית דורשת כמה ריצות לכל צד ולא מבחן בודד.
ידית חירום, לא ברירת מחדל
המצב המהיר מצוין כשבאמת אין זמן, למשל דקות לפני פגישה. כשמשתמשים בו כל יום, הוא שורף את המכסה השבועית מהר ומשאיר פחות מקום לעבודה הרגילה בהמשך השבוע.
מערכת טובה חוסכת את הלחץ
אם צריך מהירות קיצונית לעתים קרובות, כדאי לבנות תהליכים שמכינים את העבודה מראש. סיכום שרץ אוטומטית אחרי שיחה לא צריך להיות מהיר, כי אף אחד לא מחכה לו.
סיכום: מהירות היא כלי, לא אסטרטגיה
מצב Ultrafast עושה את מה שהוא מבטיח: הוא באמת מהיר, לפעמים כמעט פי שמונה, ולפעמים התוצאה שלו אפילו טובה יותר. אבל הוא זמין רק במסלול היקר, הוא שורף מכסה בקצב שמזנק ככל שהמשימה מסתבכת, והיתרון שלו קטן בדיוק במשימות הכבדות שבהן הכי מפתה להשתמש בו. ההמלצה המעשית: להכיר את הידית, לדעת מתי היא שווה, ולהשאיר אותה למקרים שבהם הזמן באמת חשוב יותר מהמכסה.
ובמקום לשלם על מהירות ברגע האחרון, עדיף להעביר כמה שיותר עבודה לתהליכים שרצים ברקע ומוכנים לפני שצריך אותם. למשל אוטומציה שמעדכנת את נתוני ה-CRM אחרי כל שיחה או פגישה רצה בקצב רגיל לגמרי, כי אף אחד לא יושב ומחכה לה, ובכל זאת המידע מוכן ברגע שפותחים את המערכת. זה סוג המהירות שבאמת חוסך זמן לעסק.
מי שרוצה לבנות תהליכים כאלה, שמכינים את העבודה מראש במקום לרדוף אחריה, מוזמן לדבר איתי על זה ולבדוק ביחד איפה כדאי להתחיל.
שיתוף הפוסט
שאלות ותשובות
מה זה מצב Ultrafast ב-Codex?
זה מצב מהירות שלישי שנוסף לצד המצב הרגיל ומצב Fast. הוא מריץ את אותו מודל עם אותה רמת חשיבה, אבל בקצב של עד 300 טוקנים בשנייה, פי שמונה מהמצב הרגיל לפי ההכרזה. כרגע הוא זמין רק עם המודל Astra, ורק במסלול של 500 דולר בחודש או דרך ה-API. בהמשך הוא אמור להגיע גם למודל Soul, שהוא זול יותר, ואז המכפיל יחול על בסיס נמוך יותר.
האם המצב המהיר באמת מהיר פי שמונה?
תלוי במשימה. במבחן שגרתי של הפיכת סרטון למדריך משאבים היחס הגיע לפי שבעה בערך, קרוב מאוד להבטחה. במבחן כבד של עריכת סרטון מתוך 145 ג'יגה של חומר גלם היחס היה רק פי 2.5. ההסבר הסביר הוא שחלק גדול מהזמן במשימות כבדות הולך על כלים, קבצים ועיבוד, ולא על קצב יצירת הטקסט שהמצב המהיר מאיץ. לכן כדאי למדוד על המשימות שלכם ולא לסמוך על המספר מההכרזה.
כמה מכסה שבועית המצב המהיר צורך?
במבחן הכבד הריצה המהירה שרפה 17 אחוזים מהמכסה השבועית של המסלול היקר, מול 4 אחוזים בריצה הרגילה, כלומר פי 4.25. במבחן השגרתי היא שרפה 3 אחוזים מול אחוז אחד. הדפוס הכללי: במשימות קטנות המכפיל נע בין פי שניים לפי ארבעה, ובמשימות גדולות ומורכבות הוא גדל ואוכל חלק משמעותי מהשבוע. ההפרש הזה מצטבר מהר כשמשתמשים במצב באופן קבוע.
האם המצב המהיר פוגע באיכות התוצאה?
לא בהכרח. במבחן הכבד דווקא הגרסה המהירה סיפרה סיפור טוב יותר, והגרסה הרגילה חתכה משפטים באמצע. במבחן השגרתי האיכות הייתה כמעט זהה, עם יתרון קטן לגרסה הרגילה שכללה יותר קישורים למקורות. ההבדלים האלה כנראה נובעים בחלקם משונות טבעית בין ריצות, ולכן לא כדאי להסיק מהם שאחד המצבים איכותי יותר באופן קבוע. השוואה הוגנת דורשת כמה ריצות לכל צד.
האם שווה לשדרג למסלול של 500 דולר בשביל המהירות?
בשביל המהירות לבדה, כנראה שלא. השדרוג הגיוני בעיקר למי שכל הזמן נתקע בגבול המכסה של המסלולים הזולים, ואז המכסה הגדולה היא הסיבה האמיתית והמצב המהיר הוא בונוס. מי שהשימוש שלו לא מצדיק את המכסה, ישלם הרבה על ידית שישתמש בה לעתים רחוקות, ויכול להסתדר היטב עם מצב Fast הרגיל ברוב העבודה היומיומית. כדאי לבדוק קודם כמה פעמים בחודש אתם באמת בלחץ זמן.
מתי הכי כדאי להשתמש במצב המהיר?
כשיש לחץ זמן אמיתי והמשימה קצרה וטקסטואלית יחסית, כמו סיכום שיחה, הכנת מסמך או מדריך לפני פגישה שמתחילה בעוד כמה דקות. במצבים כאלה היחס בין המהירות לעלות הוא הטוב ביותר, והחיסכון בזמן מורגש. במשימות כבדות, עם וידאו או תיקיות גדולות, עדיף לתת לסוכן לרוץ בקצב הרגיל ולעשות משהו אחר בינתיים. שם החיסכון בזמן קטן יחסית, והמחיר במכסה גבוה בהרבה.
למה המהירות לא עוזרת כשעוקבים אחרי הסוכן?
כי 300 טוקנים בשנייה זה מהר יותר ממה שאדם מסוגל לקרוא. אם אתם קוראים את מה שהסוכן כותב תוך כדי, צוואר הבקבוק עובר אליכם והיתרון של המצב המהיר הולך חלקית לאיבוד. המהירות מועילה בעיקר כשמחכים לתוצאה הסופית ולא לתהליך, למשל כשמבקשים מסמך מוכן ובודקים אותו רק בסוף, אחרי שהסוכן כבר סיים לעבוד עליו. במצב כזה כל שנייה שנחסכת מורגשת באמת.
איך נמנעים מהצורך במהירות קיצונית מלכתחילה?
בונים תהליכים שמכינים את העבודה לפני שצריך אותה. סיכום שיחה יכול לרוץ אוטומטית מיד כשהתמלול מוכן, חומרים לפגישה יכולים להיות מוכנים יום קודם, ודוחות יכולים להיות מופקים בלילה. כשהתוצאה כבר מחכה לכם, לא משנה כמה זמן הסוכן עבד עליה, ואפשר להריץ הכול במצב הרגיל ולחסוך את המכסה למה שבאמת דורש אותה. זו גם הדרך הזולה ביותר לקבל תוצאות מהר.
