Fable: цена высока, и разработчики снова делят код между моделями
Разработчик и блогер Саймон Уиллисон процитировал в своём блоге фрагмент статьи Дрю Бройнига «Fable & The End of the Free Lunch» («Fable и конец бесплатного сыра»), опубликованной 23 августа 2026 года.
Бройниг описывает, как изменился подход его команды к работе с ИИ-моделями для написания кода. До появления модели Fable вкладываться в улучшение инструментальной обвязки (harness) для работы с кодом или в стратегии управления контекстом казалось бессмысленным: очередная новая модель выходила по той же цене или дешевле и сама закрывала большинство проблем.
Затем появилась Fable. По словам Бройнига, модель оказалась превосходной, и остаётся такой до сих пор. Но цена оказалась настолько высокой, что для большей части задач по написанию кода команде вполне хватало моделей Opus, а также моделей, которые Бройниг называет «5.6», K3 и даже GLM.
Из-за этого в команде начали заново думать о том, какую работу поручать какой модели, то есть распределять задачи между моделями с разной ценой и возможностями, а не полагаться на одну самую мощную.
Ключевые факты
- Саймон Уиллисон процитировал статью Дрю Бройнига «Fable & The End of the Free Lunch» от 23 августа 2026 года.
- До Fable инвестировать в улучшение кодового харнесса или стратегий работы с контекстом казалось бессмысленным, новая модель по той же цене решала проблемы сама.
- Fable оказалась отличной моделью, но с высокой ценой.
- Для большинства задач хватало моделей Opus, «5.6», K3 и GLM, они оказались достаточно хороши.
- Команда начала заново распределять работу между моделями по цене и возможностям.
Почему это важно
Цитата фиксирует смену логики в разработке с помощью ИИ. Раньше расчёт был простым: подождать несколько месяцев, и новая модель окажется мощнее и дешевле прежней, а любые огрехи инструментов и подходов к работе с контекстом она компенсирует сама. С появлением модели Fable, которая оказалась заметно дороже конкурентов, эта логика перестала работать: команде пришлось вернуться к вопросу, какую модель ставить на какую задачу, вместо того чтобы полагаться на одну самую сильную.
Кому это важно
Разработчикам и командам, которые строят инструментальную обвязку (harness) вокруг ИИ-моделей для написания кода, а также техническим руководителям, планирующим бюджет на использование разных моделей.
Как это применить
Наблюдение Бройнига подсказывает практический подход: не ставить по умолчанию самую мощную и дорогую модель на все задачи. Если для основной массы кода хватает более дешёвых моделей (в тексте названы Opus, «5.6», K3 и GLM), а дорогая модель уровня Fable нужна только для сложных случаев, стоит осознанно распределять задачи между моделями по цене и требуемому уровню качества.
Можно ли доверять
Это личное наблюдение разработчика Дрю Бройнига, процитированное в блоге Саймона Уиллисона, не независимое исследование и не официальное сравнение моделей. Конкретных цифр по цене Fable или бенчмарков в цитате нет, поэтому вывод стоит воспринимать как опыт одной команды, а не как объективный рейтинг моделей.
Риски и подводные камни
В тексте не раскрыто, что такое Fable и кто её выпустил, а также к чему именно относятся названия «5.6», K3 и GLM, они упоминаются вскользь, без пояснений. Экстраполировать вывод «дорогая модель не всегда нужна» на любые задачи и любые команды не стоит: результат сильно зависит от конкретного типа кода и требований к качеству.
«До появления Fable тратить много времени на улучшение кодового харнесса или стратегий работы с контекстом казалось бессмысленным. Приходила новая модель по той же цене (или дешевле!) и сама закрывала большинство проблем. Но потом появилась Fable. Она была (и остаётся!) великолепной. Но цена оказалась настолько высокой, а Opus, как и «5.6», K3 и даже GLM, оказался достаточно хорош для большей части нужного нам кода. Поэтому мы начали думать, какая работа куда идёт.»
— Дрю Бройниг, «Fable & The End of the Free Lunch»