Как только задача уходит агенту, встаёт выбор модели, и меню в Devin Desktop длинное. Соблазн - выбрать по бренду или по принципу "бери самую сильную, не ошибёшься". И то и другое кажется безопасным: сильная модель ведь справится с чем угодно. Но выбор модели - это не выбор "лучшей вообще", а подбор под неопределённость конкретной задачи.
Наивная стратегия проста: закрепить один флагман на всё. Она экономит решение сейчас - не надо думать перед каждой задачей - и потому липкая. Плата приходит позже и незаметно: сильная модель на тривиальном поиске или однострочном diff тратит кредиты и время там, где хватило бы быстрой, а на потоке таких задач разница набегает в реальную стоимость.
Ломается "всегда самая сильная" с двух сторон. Сверху - переплата и лишняя латентность на простых задачах. Снизу - если по привычке выбрать быструю модель на действительно сложную задачу с неоднозначной архитектурой, она сэкономит копейки и провалит суть, а переделка обойдётся дороже любой экономии. Ни одна точка на шкале не оптимальна для всего диапазона задач.
Профессиональный ход - переложить выбор на неопределённость, а не на бренд. Быстрый вариант - для задач с низкой неопределённостью: поиск по коду, извлечение, простой предсказуемый diff. Сильный - там, где неопределённость высока: неоднозначная архитектура, сложный debug, план, затрагивающий несколько систем сразу. Вопрос не "какая модель лучше", а "насколько эта задача рискованна и двусмысленна".
Именно этот выбор Devin предлагает не делать вручную по умолчанию. Adaptive - рекомендуемый роутер: он анализирует задачу и сам направляет простое к быстрым и экономным моделям, а сложное - к более способным, балансируя качество и стоимость. Документация прямо называет его лучшим выбором по умолчанию для большинства. Смысл делегирования здесь тот же, что и в остальном продукте: рутинное решение отдают механизму, а внимание человека берегут для случаев, где оно действительно нужно. Ручной выбор осмыслен тогда, когда у вас есть причина не доверять маршрутизации на конкретном классе задач.
Каталог за пределами Adaptive стоит воспринимать как снимок, а не как список на будущее. На срезе в нём встречались специализированные модели: варианты для быстрой и для тщательной работы, отдельные - под Tab, под retrieval, под Quick Review, а часть вариантов помечена как доступные только в Devin Local. Конкретные имена меняются от релиза к релизу, и запоминать их наизусть смысла мало.
Почему книга здесь особенно осторожна с именами и цифрами. Каталог, доступность и тарифы меняются быстрее, чем печатается любой текст. На дату этого среза в документации всё ещё висела уже истёкшая акция на одну из моделей "до 8 августа" - живой пример того, как страница отстаёт от факта. Поэтому источник истины здесь - фактический model picker и страница usage, а не запомненная строка.
Цена невнимания двусторонняя и потому коварная. Переплата на простом незаметна поштучно и болезненна на потоке. Недобор мощности на сложном незаметен в момент запуска и болезнен на результате - когда дешёвая модель уверенно выдала правдоподобно неверный план, и его ещё надо распознать и откатить. Правдоподобно неверный план опаснее очевидно плохого именно тем, что проходит первую проверку взглядом и тратит время уже на реализации, а не на старте. Обе ошибки дешевле предупредить выбором по риску, чем лечить после.
Оправдан ручной выбор в двух ситуациях. Первая - когда вы знаете класс задачи лучше роутера: например, заведомо тяжёлый архитектурный разбор, где стоит сразу взять сильную модель. Вторая - когда вы честно сравниваете модели между собой. Но сравнение имеет смысл только на одинаковых критериях: одна и та же задача, один и тот же контекст, один и тот же способ проверки результата.
Проверять выбор модели нужно тем же мерилом, что и любую работу агента, - доказательством результата, а не ощущением "эта поумнее". Сравнивайте вывод на одинаковом входе и по одинаковому критерию: прошли ли тесты, решена ли задача, сколько это стоило. Разные задачи, поданные разным моделям, ничего не говорят о моделях - только о задачах.
Типичный провал - выбирать по бренду и сравнивать на неравных условиях: одной модели достался простой случай, другой сложный, а вывод делают о моделях. Признак прост: решение о модели объясняют её именем, а не риском задачи и не замером на равном входе. Спросите сначала, насколько задача неопределённа, - и в большинстве случаев ответом будет "оставь Adaptive", а ручной выбор прибереги для случаев, где у тебя есть измеренная причина.