שבעה מבחנים בין Sonnet ל-Opus: מתי משתלם לשלם כפול?

האם המודל היקר באמת שווה פי שניים?

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

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

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

כמה עולה כל מודל, ואיך נקבע המנצח?

התמחור פשוט לזכור. Sonnet 5.5 עולה 2 דולר למיליון טוקנים של קלט ו-10 דולר למיליון טוקנים של פלט. Opus 5.5 עולה 4 דולר לקלט ו-20 דולר לפלט, כלומר בדיוק פי שניים בשני הכיוונים. לעומת Sonnet 5 הקודם, הגרסה החדשה רצה מהר יותר בכשלושים אחוז ועולה עד שלושים אחוז פחות ברוב סוגי העבודה, כך שהפער בין המודל הבינוני למודל הבכיר נעשה משמעותי יותר מבחינה כלכלית.

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

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

איפה Opus 5.5 הוביל, ולמה זה לא תמיד הספיק?

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

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

מה קרה כשהמשימה הוגדרה היטב?

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

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

במבחן החמישי שני המודלים השתמשו בסקיל פשוט שבונה דפי הסבר, כדי לענות על השאלה אילו מודלים מקומיים אפשר להריץ על מחשב ביתי עם כרטיס גרפי של 32 ג'יגה. Opus הסביר טוב יותר את הכלל המרכזי: המודל צריך להיכנס לזיכרון של הכרטיס הגרפי, ולכן מודל של 20 ג'יגה ירוץ ומודל של 43 ג'יגה לא. Sonnet היה ויזואלי יותר, והתחיל מהסבר של מה זה בכלל מודל מקומי, אבל פחות הסביר את הסיבה. הזמנים היו דומים ו-Sonnet עלה חצי, בערך 3 דולר פחות. סבב הבהרה אחד היה מביא אותו לתוצאה טובה יותר, ולכן הסבב הלך אליו.

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

מה אומרים המספרים בסוף שבעת המבחנים?

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

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

במבחן דף הנחיתה, לעומת זאת, רואים את המקרה ההפוך: Sonnet צרך כ-20 מיליון טוקני קלט ו-134 אלף טוקני פלט, ו-Opus צרך כ-37 מיליון טוקני קלט ו-148 אלף טוקני פלט, רץ כמעט פי שניים זמן ועלה כמעט פי שניים. ההבדל בין המקרים הוא אופי המשימה. כשהמשימה פתוחה, Opus חוקר יותר וקורא יותר, וזה עולה. מי שרוצה להבין איך רמת המאמץ עצמה משפיעה על המספרים האלה ימצא השוואה של שש רמות המאמץ ב-Opus 5.5 על אותה משימה.

איך בונים מפת ניתוב של מודלים לפי סקיל?

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

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

# model-routing.md
# Decided by running each skill on both models with the same input.

| Skill / task                 | Model  | Why                                        |
|------------------------------|--------|--------------------------------------------|
| resource-guide (from video)  | sonnet | Skill defines the layout. Same output, half the cost. |
| html-explainer               | sonnet | Visual is fine. One follow-up prompt fixes gaps.      |
| spreadsheet + investor deck  | either | Near identical output. Pick the cheaper run.          |
| bug fix with failing test    | sonnet | Clear definition of done: the test passes.            |
| motion / brand video         | opus   | Taste in motion and sound. Sonnet never caught up.    |
| open-ended strategy / plan   | opus   | Vague goal, needs a thinking partner.                 |

Re-test a row when: a new model ships, the skill changes, or output quality drops.

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

איך כותבים פרומפט שהמודל הזול מצליח בו?

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

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

Build a 90-day growth plan for our new newsletter. Goal: 1,000 subscribers.

Definition of done:
- Starts on the first day of next month, split into 3 monthly phases
- Each phase: goal number, 5-8 tasks with an owner, and one metric to track
- A table of subscriber sources with an expected number for each
- A short list of open decisions we must make before launch
- Output: one HTML page, readable on mobile, no external libraries

Use only the data in ./audience.md and ./channels.md. Mark any assumption clearly.

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

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

חמש תובנות מההשוואה

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

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

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

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