Я никогда не использую дешевые модели и низкий эффорт Изначально на эффортах High/xHigh/Max я работал просто на всякий случай. Со временем стал проверять на своих задачах какой эффорт у какой модели дает нужный результат по скорости и расходу лимита подписки В каналах разработчиков, особенно в комментариях у них, часто вижу людей, которые для разработки используют дешевые модели, по типу Luna, а для планирования, оркестрации и архитектуры что-то вроде Sol 6.1 Low или Opus 5.5 Medium Я же ориентируюсь на то, что пока подписки субсидируются, не имеет смысла использовать дешевые и заведомо более слабые модели. Одновременно лимитов подписки мне часто не хватает, поэтому есть мотивация снизить эффорт или работать с тем же Sol вместо Astra Но я никогда не выбираю связку модель+эффорт ориентируясь на комментарии людей в телеграме. Перед выбором всегда прогоняю исследования публичных бенчмарков + тесты на своих задачах Тест выглядит так: подбираю с агентом несколько разнотипных задач, которые уже были решены, многократно проаудированы и приняты → запускаю их решение в отдельных временных копиях проекта → результаты оценивают отдельные агенты: смотрят разницу относительно уже рабочего решения, скорость работы агента, оценивают количество и критичность ошибок. Аудит результатов всегда в слепую, агенты не знают какой модели принадлежат варианты решения При этом я сравниваю так и полную петлю разработки. Например, что если писать код будет дешевая модель, а аудировать и давать ей правки, дорогая. Даю им несколько раундов работы и сравниваю с аналогичной схемой, в которой всё делают дорогие модели Так вот, пока ни разу не вышло так, что схема «дешевая модель пишет + дорогая модель аудирует» по стоимости и скорости работы не победила у схемы «дорогая модель пишет + дорогая модель аудирует». Под дешевой моделью подразумеваются и подходы, когда берём дорогую модель с низким эффортом В живых замерах оказывается так, что дешевая модель больше косячит → на аудит и рекомендации по исправлению всех этих косяков уходит больше времени и токенов дорогой модели → дешевая модель по ним правит и снова в чем-то косячит → дорогая снова это аудирует → дешевая модель снова правит и косячит. И вот такая схема на деле оказывается дороже схемы, в которой сразу пишет дорогая модель и аудирует за ней дорогая модель. Иногда схема с дешевыми моделями действительно оказывается чуть дешевле, но при этом сильно медленнее из-за количества раундов. Экономия при этом ни разу не была настолько существеннной, чтобы ради этого пожертвовать скоростью