Одна з найкращих особливостей наших найновіших моделей Claude — це те, як вони реагують на рівень зусиль (effort), не руйнуючи при цьому кеш промптів у Claude Code. Але я отримав безліч запитань від користувачів щодо цього. Що таке effort насправді і коли який рівень використовувати? Навіщо він взагалі потрібен?
Щоб відповісти на це, я вирішив глибоко зануритися в евали (evals) і провести власні тести різних рівнів зусиль на типових робочих завданнях.
примітка: більше інтерактивних діаграм і пояснень до цієї статті можна знайти на https://claude.dev/blog/spending-your-effort/
Якщо говорити загалом, я з'ясував, що effort — це чудовий спосіб керувати тим, скільки перевірок і тестування крайових випадків виконує Claude, а також наскільки активно він покладається на власне судження.
Додаткові зусилля давали кращі результати в тих сферах, де перевірки та тестування крайових випадків є найбільш корисними: апаратне забезпечення, ревʼю коду та безпека.
Але низький і середній рівень зусиль ідеально підходили для швидкого виконання завдань і постійного залучення в процес разом із Claude.
Для звичайної розробки ПЗ я тепер використовую такий цикл: спочатку модель проводить зі мною інтерв'ю, потім реалізує рішення з низьким або середнім effort, я переглядаю результат, а після цього запускаю перевірку з високим effort.
Що таке effort?
Загалом, effort дає моделі приблизне розуміння того, скільки обчислювальних ресурсів ви хочете, щоб вона витратила на завдання. Це певною мірою пов'язано з вашою оцінкою складності самого завдання.
Подумайте про це так: якщо хтось просить вас працювати над чимось 12 годин поспіль, ви, ймовірно, припустите, що від вас просто чекають максимальної віддачі та наполегливості. А якщо те саме завдання треба зробити за 1 годину, ви спробуєте одразу видати найкращий варіант, який відповідає вимогам, а далі очікуватимете на ітерації.
Або ж ви можете заперечити й сказати, що завдання потребує щонайменше 3 години, і працювати ці 3 години, щоб його виконати.
Саме так варто ставитися й до effort. Claude завжди намагатиметься виконати ваше завдання адекватно, але вищий рівень зусиль означає, що модель діятиме самостійніше, приймаючи рішення та проводячи перевірки.
Криві зусиль
Криві зусиль Fable 5.1 та Opus 5.5 — найкращі з того, що ми маємо: на кожному рівні спостерігається зростання балів у бенчмарках і кількості використаних токенів. Нижче наведено графік результатів Terminal Bench 3.0 залежно від рівня effort, отриманий під час моїх тестів для цієї статті.
Але що це означає на практиці? Щоб це оцінити, я спробував виконати кілька завдань із різними рівнями зусиль і детально проаналізував бенчмарки.
Розробка з використанням effort
Найкращий спосіб зрозуміти, як працюють моделі — проводити експерименти. Я виконував одні й ті самі завдання з різними рівнями effort в Opus 5.5, щоб побачити, як змінюється її робота. Я протестував широкий спектр завдань, але тут проілюструю це кількома простими прикладами.
Недостатньо деталізоване завдання на розробку
Якщо я прошу Claude «створити додаток для відстеження фізичної форми та тренувань», рівень effort кардинально впливає на те, наскільки опрацьованим буде додаток, а також на те, скільки рішень Claude прийматиме самостійно. На низькому рівні фітнес-додаток — це просто журнал і простий графік. На вищих рівнях додаток стає складнішим і деталізованішим. А на максимальному з'являється теплова карта.
Якби мені потрібна була проста база для подальших ітерацій, низький effort впорався б із цим. Максимальний effort підійшов би, якби я хотів отримати найкращий результат від Claude з першої спроби.
Частково деталізоване завдання на дизайн
А що, як завдання вже досить добре описане, але я хочу трохи поекспериментувати разом із Claude? Для прикладу я попросив переробити меню /config у Claude Code. Кожен прохід давав приблизно ту саму ідею: використовувати підменю та покращити пошук.
На низькому рівні effort (це зайняло 1 хвилину) я отримав інтерактивний ескіз, який передавав суть, але був зовсім не схожий на Claude Code.
На максимальному рівні (це зайняло 28 хвилин) я отримав макет, дуже схожий на Claude Code, а також низку покрокових демонстрацій для різних сценаріїв.
Якщо моя мета — ітерувати та давати фідбек, низький effort приведе до результату значно швидше. Але максимальний effort одразу дає щось набагато більш відшліфоване. Для цього конкретного завдання я, мабуть, віддав би перевагу низькому effort, щоб краще зрозуміти бачення Claude.
Дуже деталізоване завдання на розробку
А що, як дати Claude багато деталей? Я попросив Claude детально розпитати мене про фітнес-додаток, а потім передав цю специфікацію різним моделям для реалізації з різними рівнями effort.
Я помітив, що за наявності такої специфікації моделі поводилися набагато схожіше. Я отримував дизайни, які виглядали майже однаково і мали подібну реалізацію, але відрізнялися деталями; на максимальному рівні effort Claude витратив деякий час на спрощення кількох деталей.
Головні висновки
У звичайній розробці ПЗ, особливо під час створення нових функцій, рівень effort сильно залежить від того, наскільки я хочу бути залученим у процес. Низький effort дозволяє Claude швидко запропонувати відправну точку, а вищі рівні виконують більше роботи, але при цьому Claude робить більше припущень замість мене.
Особливо продуктивний цикл для розробки функцій, який я використовую:
- Дати Claude специфікацію та попросити розпитати мене про будь-які деталі, яких бракує
- Реалізувати це з низьким effort
- Перевірити, чи правильно модель зрозуміла суть, і за потреби ітерувати на низькому effort
- Верифікувати та протестувати з високим effort
Як рівні effort впливають на результат у складних завданнях
Але це, очевидно, лише прості приклади, з якими Claude легко справляється. А що, коли різниця полягає в тому, чи виконає Claude завдання взагалі?
Щоб знайти такі складні проблеми, потрібно звернутися до бенчмарків, тому я занурився в один із моїх улюблених: Terminal Bench 3 — бенчмарк, створений спільнотою.
Задачі Terminal-Bench 3.0 можна умовно поділити на категорії: безпека, апаратне забезпечення, ML, наука, програмне забезпечення, операційна діяльність та медіа. Усі задачі можна переглянути тут: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0. Вони збираються від спільноти, тому долучитися може будь-хто.
Їх варто прочитати, щоб зрозуміти, з якими типами проблем стикаються ці моделі. Мене здивували масштаб і амбітність багатьох із цих завдань. Вони набагато складніші за ті, з якими я зазвичай маю справу.
Наприклад, деякі задачі включали:
- Апаратне забезпечення (retro-console-soc): створити 8-бітну ігрову консоль на Verilog, яка поміститься в невелику FPGA і відтворюватиме тестовий ROM.
- Наука (takens-embedding-lean): формально довести теорему вкладення Такенса в Lean 4.
- ML (mp-checkpoint-consolidation): об'єднати 16 шардів чекпоінта mixture-of-experts в один файл, який відтворює референсні логіти.
- Операційна діяльність (intrastat-meldung): виконати від початку до кінця місячне подання компанії щодо торговельної статистики ЄС.
- Медіа (layout-config-recreation): відтворити зображення постера як редагований файл макета.
Вищі рівні effort допомагають, коли є багато крайових випадків
Мій головний висновок після аналізу результатів Terminal Bench 3: вищий effort найкраще підходить для завдань із великою кількістю прихованих крайових випадків.
Хороший приклад — html-js-filter, задача Terminal-Bench 3.0, яка вимагає створити HTML-санітайзер, що блокує всі можливі способи впровадження JavaScript на сторінку. Результат Fable 5.1 покращився з 1/5 на low до 5/5 на xhigh.
Типова спроба на low займає близько 2 хвилин. У кожній із цих спроб фільтр писався приблизно за один прохід, а потім тестувався на одній вручну написаній сторінці.
Прогін на high завершується приблизно за 33 хвилини. У тому прогоні, який я відстежував, модель критично проаналізувала свій перший чернетковий варіант, потім прочитала вихідний код встановленого парсера, щоб перевірити його на помилки, запустила багато чистих тестів, поки вони не почали давати той самий результат, що й вхідні дані, виконала стандартний набір XSS-тестів і, нарешті, написала фаззер для випадкових документів.
Для чогось настільки схильного до крайових випадків, як HTML-санітайзер, ці додаткові зусилля цілком виправдані. Витрата більшої кількості токенів заради ретельності також має сенс для складних завдань із високими вимогами до продакшену, як-от оптимізація продуктивності або аудит безпеки.
Але такий рівень зусиль потрібен далеко не для кожного завдання.
На діаграмі нижче показано всі результати Terminal-Bench 3.0 і причини невдач для різних моделей і рівнів effort. Загалом, підвищення effort зменшує кількість помилок через пропущені крайові випадки (фіолетові блоки), але не виправляє ситуації, коли модель обирає хибний підхід (сині блоки).
Сфери, де effort дійсно допомагає
Один із найцікавіших висновків, який я зробив, тестуючи ці моделі на TerminalBench, полягає в тому, що деякі проблемні сфери вигравали від effort значно більше за інші. Деталізацію можна побачити на наступній діаграмі:
Щоб проілюструвати це, я обрав кілька задач із різних сфер Terminal Bench 3.0, де Opus 5.5 не впоралася на low, але успішно виконала їх на high — переважно тому, що тестувала та враховувала крайові випадки:
mvcc-lsm-compaction: задача Terminal-Bench 3.0, яка вимагає виправити баг рушія зберігання на основі звіту про збій, не порушуючи роботу компакції. Результат Opus 5.5 покращився з 0/5 на low до 4/5 на xhigh.
На low (приблизно хвилина на спробу) Claude редагував код до його збірки або запуску відтворювача і не перевіряв, чи зміг би його новий тест виявити початкову помилку.
На xhigh (приблизно 11 хвилин) Claude спочатку відтворив збій, написав рандомізований тест порівняно з референсом, який ніколи не виконує компакцію, і перевірив, що його тести падають на наполовину готових виправленнях.
cli-2ph-simple: задача Terminal-Bench 3.0, яка вимагає написати CLI-солвер лінійного програмування на Python. Результат Opus 5.5 покращився з 0/5 на low до 5/5 на high.
Спроби на low створювали солвер за один прохід, перевіряли його на кількох дрібних задачах і зупинялися приблизно на 10 тисячах токенів. В останньому повідомленні Claude попереджав, що на великих задачах може працювати повільно, але не перевіряв цього.
Під час спроб на high Claude тестував свій солвер на випадкових задачах, порівнюючи його з окремим солвером повного перебору, потім вимірював час на більших задачах, натрапляв на випадки, які працювали надто довго або призводили до збоїв, і переробляв алгоритм пошуку.
gsea-proteomics: задача Terminal-Bench 3.0, яка вимагає провести аналіз збагачення наборів генів (GSEA) на протеомних даних, щоб визначити, який із восьми методів лікування найбільше схожий на цільову тканину. Результат Opus 5.5 покращився з 0/5 на low до 4/5 на high.
На low Claude обирав метод підготовки даних, який звучав логічно, проводив аналіз одним способом і видавав результат.
На high Claude спробував два способи підготовки даних, помітив, що список значущих методів лікування змінився, і розібрався в причинах, перш ніж обрати правильний варіант.
Якби користувач був залучений у процес, Claude, можливо, запитав би його про те, як налаштувати задачу. Але без участі людини високий effort дає кращий результат.
Коли використовувати різні рівні effort у Claude Code
Ось моє емпіричне правило щодо того, коли який рівень effort обирати:
- Low: коли мені потрібні швидкі відповіді в рамках постійної взаємодії, наприклад, брейнштормінг, створення ескізів, прості зміни.
- Medium: для більшості моєї звичайної роботи з розробки ПЗ, наприклад, реалізації нових функцій.
- High: для роботи, де важлива верифікація або є крайові випадки, наприклад, виправлення бага в legacy-кодовій базі.
- Max: коли я хочу, щоб Claude працював повністю автономно для вирішення складних проблем, наприклад, для розробки та верифікації додатка від початку до кінця або пошуку вразливостей у критично важливому ПЗ.
Спробуйте змінювати рівень effort для Opus 5.5 і Fable 5.1 залежно від вашого завдання або навіть посеред розмови за допомогою команди /effort у Claude Code, і дайте знати, чи збігається це з вашою інтуїцією.
