הגדרת ה-"max effort" של Claude Opus 5 מנפחת את המחיר של בקשה שגרתית מ-$0.76 ל-$19.21, תוך אספקת פלט פונקציונלי זהה למדי. ההוצאה הנוספת קונה שלב של ביקורת פנימית, ולא פתרון טוב יותר, והיא מציגה שיפורים מדידים רק במשימות שמתחילות עם כיסוי בדיקות נמוך.

מה הבדיקה הראתה

הניסוי השווה בין רמת המאמץ המוגדרת כברירת מחדל של Claude Opus 5 לבין כפתור ה-"max effort" בשני סוגי פרומפטים: משימות קידוד יומיומיות ובעיות קשות במכוון.

  • עבור משימה טיפוסית, ההרצה ברמת מאמץ נמוכה הסתיימה תוך שתי דקות עלותה הייתה $0.76. העלאת ההגדרה למקסימום דחפה את החשבון ל-$19.21, אך ציון כיסוי הדרישות — המדד שהמודל מדווח עליו כדי לציין עד כמה הוא עמד בבקשה — נשאר זהה.
  • התמליל מראה מעבר מיצירה לעריכה. המודל הפסיק לייצר קוד חדש והתחיל ללטש את מה שכבר כתב. מספר העריכות עלה על מספר הכתיבות החדשות ביחס של 2.4 ל-1. הקריאות לכלי ה-"read" עלו פי 18, והקריאות לכלי ה-"bash" עלו פי 6. בפועל, המודל קרא מחדש מודולים, הריץ מחדש את הבדיקות שלו, ביצע linting ואפילו mutation testing מבלי שהתבקש לכך.

הגדרת ה-"max effort" אינה מציגה אלגוריתם חדש; היא פשוט מעלה את התקציב שהמודל יכול להוציא. ברגע שהתקציב גדול מספיק, המודל עובר למצב של ביקורת עצמית, ומחפש כל שיפור קטן שהוא יכול להצדיק את ההוצאה עליו.

מדוע העלות מזנקת

כאשר המודל מחליט לבצע ביקורת, כל קריאה נוספת ל-"read" או ל-"bash" מוסיפה לחשבון, ואפקטים של כפל מנפחים במהירות את העלות הכוללת.

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

מתי מאמץ גבוה יותר הגיוני

מצב הביקורת מצטיין רק כאשר הפלט הראשוני משאיר מקום לשיפור. בפרויקט Go עם כיסוי בדיקות של 0.73, העלאת המאמץ למקסימום העלתה את הכיסוי ל-0.88.

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

חסרונות פוטנציאליים

  • חריגה בתקציב – משתמשים שהורגלו למחיר של רמת מאמץ נמוכה עשויים להיות מופתעים מעלייה פי 25 עבור אותה תוצאה.

הנחיות מעשיות למפתחים

  • שמרו על פרומפטים שגרתיים ברמת המאמץ המוגדרת כברירת מחדל. תקבלו את אותה תוצאה פונקציונלית בשבריר מהמחיר.
  • שמרו את ה-"max effort" לקוד שנכשל בעמידה בסף איכות ברור — כיסוי בדיקות נמוך, אזהרות linting חסרות, או פערים מדידים אחרים.
  • התייחסו להגדרה כמצב נפרד: שלב אופציונלי של סקירה עצמית, ולא כ"גלגל מהירות" לקבלת תשובות טובות יותר.

שורה תחתונה

מתג ה-"max effort" של Claude Opus 5 מחליף כסף בבדיקת איכות פנימית, ולא בקוד טוב יותר. השתמשו בו במידה, רק כאשר התוצאות הבסיסיות שלכם משאירות פער מדיד שיש למלא; אחרת, ברירת המחדל הזולה מספקת את אותה תוצאה ללא תג המחיר של מצב הביקורת.

מקור: https://dev.to/adrianco_54/retort-thinking-level-results-what-opus-actually-does-with-the-extra-time-55f7

דיון קהילתי: https://t.me/GyaanSetuAi