Десь місяць я намагався зрівняти наші пропрієтарні моделі з open-weight.
Не по всій компанії — лише в моторному відсіку. OwlMeans — це пайплайн розробки на основі AI: ти описуєш, чого хочеш, у вигляді історій користувача, а команда спеціалізованих AI-ролей перетворює їх на повноцінний фулстек-застосунок, який належить тобі. Під капотом кожна з цих ролей звертається до мовної моделі. Сьогодні це комбінація моделей Anthropic та OpenAI — Claude бере на себе більшість важкої роботи, а OpenAI підключається для окремих ролей. Це конфігурація, якій я довіряю. У неї також є своя ціна.
Тож я зробив очевидний експеримент. У open-weight моделей видався дуже гучний рік — до середини 2025-го найкращі open-weight LLM виходили з Китаю: GLM, Kimi, Qwen і DeepSeek на рівних змагалися з пропрієтарним фронтиром у кодингу. І коштують вони лише частку ціни. Якби я зміг запустити свій пайплайн на open-weight без погіршення результату, математика була б непереборною.
Місяць я витратив на те, щоб під’єднати їх, прогнати бенчмарки й налаштувати. Ось що сталося насправді — включно з тією частиною, на яку я не очікував і яка зрештою виявилася головною.
Ставка: пайплайн має робити модель взаємозамінною
Ось що змусило мене думати, що це взагалі спрацює.
OwlMeans не кидає моделі розпливчастий prompt і не молиться. Він розбиває проєкт на дуже дрібні, чітко окреслені задачі, кожна з яких виконується з дуже малим контекстом — одна історія користувача, одне виправлення, зміна обсягом в один файл. Роль бізнес-аналітика формулює роботу, архітектор її проєктує, роль розробника реалізує один шматок, а виправляч прибирає за всіма. Ніхто не просить одну модель «зібрати застосунок». Її просять зробити одну маленьку, добре специфіковану річ.
У цього дизайну є тиха побічна дія: що менша й точніше задана задача, то менше важить вибір моделі. Коли контекст крихітний, а інструкція точна, майже будь-яка компетентна модель приземляється приблизно в одне й те саме місце. Менше простору для геніальності — і менше простору заблукати. Саме тому й наші витрати на токени лишаються адекватними: дослідження агентних циклів прямо кажуть, що вартість токенів зростає квадратично від контексту, який ти переоплачуєш на кожному кроці, тож тримати кожну задачу маленькою — це різниця між робочим рахунком і некерованим.
Тож моя гіпотеза була проста: якщо пайплайн уже перетворює задачу на товар широкого вжитку, він має зробити те саме й із моделлю. Заміни пропрієтарну модель на GLM — і застосунок, що вийде з іншого кінця, має бути практично тим самим застосунком.
Здебільшого я мав рацію. І це не мало того значення, на яке я сподівався.
Що зламалося першим: моделі, які думають забагато
Шлях через open-weight не був лагідним.
Першою стіною стали «мислячі» моделі. GLM, Kimi, Qwen — вони міркують за замовчуванням. Звучить чудово, доки ти не ставиш жорсткий ліміт на вихід, і модель витрачає весь свій бюджет на мовчазне міркування, а тоді повертає нічого. Порожній контент. Роль кодера спрацьовувала, модель додумувалася рівно до стелі по токенах і віддавала порожній рядок. Пайплайн давився не-відповіддю.
Я виставив effort: none. Це тихо проігнорували. Модель продовжувала думати.
Це не моя унікальна примха — це брудний секрет reasoning-моделей у продакшені. Зусилля на міркування, як влучно зауважено в одному хорошому розборі, — це ручка вартості, а не ручка якості: викрути її вгору — і можеш потроїти кількість мислячих токенів заради кількох балів на бенчмарку, а в нагороду отримати сюрпризи в рахунках і порожні виходи, коли міркування з’їдає місце, де мала жити твоя відповідь. Виправлення вийшло неромантичним: жорсткий, абсолютний ліміт на токени міркування для кожної ролі, налаштований модель за моделлю, щоб думання не голодоморило вихід. Кодери отримують короткий повідок на міркування; ролі планування — більше свободи. Універсального налаштування немає. Кожна модель хотіла власного.
Другою стіною став структурований вихід. Мій пайплайн спирається на те, що моделі повертають чистий, валідний за схемою JSON, аби наступна стадія могла на ньому діяти. Пропрієтарні API тепер у цьому дуже хороші — строгий режим структурованого виходу в OpenAI знижує частку помилок формату нижче 0,1%. Багато open-weight моделей у багатьох провайдерів до цього ще не дотягують. Вони видають битий JSON у відчутній частині відповідей, особливо на довгих виходах і вкладених схемах. Тож я перестав силоміць нав’язувати JSON хитким моделям і дозволив їм користуватися tool call, а ще переписав обробку джерел так, щоб агент видобував лише релевантні фрагменти й застосовував patch-diff замість переписування цілих файлів. Менший контекст — менше шансів зламати формат. Ця одна зміна зробила для надійності open-weight більше, ніж будь-яка заміна моделі.
Третьою стіною стали самі провайдери. Та сама open-модель поводиться по-різному залежно від того, хто її хостить — швидкість, надійність, ба навіть те, чи взагалі працює структурований вихід. Я прогнав цілу купу. Деякі були чудові. Деякі провалювали валідацію схеми на кожному виклику. Деякі обрізали відповідь. Кілька просто не вміли віддавати потрібні мені моделі. Зрештою я почав маршрутизувати через OpenRouter, який розкидає кожну модель по шістнадцяти-двадцяти-плюс базових провайдерах і перемикається між ними при збоях — і сперся на його варіант :nitro, що сортує провайдерів за чистою пропускною здатністю, аби відіграти трохи швидкості. Під кінець я міг перемикати весь пайплайн між open-weight пресетом і пропрієтарним одним прапорцем і проганяти один і той самий проєкт через обидва.
Саме цей перемикач і дав мені змогу нарешті порівняти їх чесно. А порівняння — це там, де стало цікаво.
Несподіванка: вихід вийшов практично однаковим
Я очікував, що open-моделі видаватимуть помітно гірший код. Вони цього не зробили.
Оскільки пайплайн дробить усе на крихітні задачі, кінцевий результат вийшов майже однаковим у різних моделей. Та сама структура, та сама поведінка, той самий застосунок. Відмінності були дрібні й майже естетичні — здебільшого якість CSS і випадкові оздоблення. Ось частина, яку я вважаю по-справжньому кумедною: просунутіші моделі грішили цим більше. Дай фронтир-моделі маленьку, точну задачу — і вона стає креативною: додає до UI завитушку, якої ніхто не просив, вирішує, що твоїй формі бракувало анімації. Haiku просто робить те, що треба. Що розумніша модель, то ймовірніше вона імпровізуватиме саме тоді, коли імпровізація — це останнє, чого ти хочеш.
Тож питання якості — те, через яке всі б’ються на бенчмарк-лідербордах — здебільшого розчинилося. І лишило мене дивитися на дві осі, і тільки дві: ціну та швидкість.
І я б сказав, що це чесне місце, де всій цій індустрії варто приземлитися. Нейтральні аналітичні майданчики вже розводять моделі рівно за цими лініями — інтелект, швидкість і ціна як три різні колонки — бо щойно інтелекту «достатньо» для задачі, ти живеш саме зі швидкістю та ціною.
Де дешеві моделі перестають бути дешевими
На папері open-weight виграють у ціні з розгромним рахунком. Вони коштують частку від того, що пресет Anthropic-плюс-OpenAI бере за токен. Це і є вся причина за це братися.
Але ціна за токен — це пастка, і я зайшов у неї прямісінько.
З пропрієтарного боку моделі Anthropic несуть більшість навантаження — і Sonnet та Haiku роблять менше помилок і інферять швидше, ніж те, що я отримую через OpenRouter, навіть з увімкненим Nitro. На один запит різниця у швидкості не драматична. Але вона накопичується. А справжній податок — це помилки: з open-weight пресетом агенту доводиться частіше зупинятися й щось виправляти. Поганий JSON тут, заплутаний diff там, retry, повторне планування. Кожне з цього — це більше токенів і більше реального часу на годиннику.
Це та математика, яку ніхто не виносить на сторінку з цінами. Модель, яка вп’ятеро дешевша за токен, але потребує retry, на практиці не є вп’ятеро дешевшою — 20% частоти збоїв на крок приблизно подвоює твій рахунок за токени, а в агентному циклі ці збої накопичуються через кроки. Уся індустрія тихо переучує цей урок наново: дешевші токени породили більші рахунки, бо retry з’їдають заощадження живцем.
Саме це я й спостерігав. Цінова перевага на лічильнику пережовувалася циклом «зупинись-і-виправ». А коли я склав усе докупи — повільніший інференс, зайві retry, повторне планування — реальний розрив між моїм пропрієтарним пресетом і open-weight пресетом вийшов десь у 5 разів. Не на бенчмарку. На справжній роботі, від початку до кінця.
Щоб було ясно, чого я не стверджую: це не про те, що open-weight погані. Це про open-weight у моєму пайплайні, сьогодні, на тих провайдерах, що я тестував, з тим тюнінгом, який я встиг зробити. Що підводить мене до частини, у якій я певен найменше.
Чому я поки що не довіряю власним цифрам
Ось незручне зізнання. У мене є цифра 5x. Я їй не цілком довіряю — і думаю, що тобі теж не варто, — і не тому, що вона хибна, а через те, як подібні речі зазвичай вимірюють.
Епоха бенчмарків розпадається на очах. Стандартні бенчмарки кодингу насичені та забруднені; галузь провела 2025-й, спостерігаючи, як таблиця результатів перестає відображати реальну спроможність. А лінива зрізана дорога, до якої всі тягнуться — дати сильній моделі оцінити вихід — сама ненадійна: LLM-як-суддя показує велику, чутливу до порядку дисперсію на задачах кодингу. Просити одну фронтир-модель сказати мені, чи хороший код іншої моделі, — це не доказ. Це vibe із довірчим інтервалом.
Тож мій наступний крок — не ще один бенчмарк. Це подивитися на справжній код, який ці моделі навайбкодили, власними очима й реальними метриками — чи воно збирається, чи проходить тести, чи його можна підтримувати, чи хотів би я цим володіти. Цілком можливо, що GLM і Kimi виявляться такими, що дають кращий загальний результат, коли я суджу по реальному артефакту, а не по синтетичному балу. Так само можливо, що open-моделі просто ще не дотюнені — бюджети міркування й дюжина дрібних ручок майже напевно потребують підлаштування під кожну модель, а я лише дряпнув по поверхні. Моє чесне очікування: щойно ти зійдеш із синтетичних бенчмарків і почнеш порівнювати реальні виходи, уся картина стане каламутнішою, а не чистішою.
Я й далі копатиму. Але місяць уже навчив мене того, що справді має значення, і це не модель.
Урок, що вартий більше за результат
Відступи на секунду від лідерборда.
Усе, що зробило open-weight придатними в моєму пайплайні — ліміти міркування для кожної моделі, щоб думання не голодоморило вихід, fallback на tool call для хисткого JSON, видобування фрагментів і patch-diff, що стискають контекст, перемикання провайдерів і маршрутизація за пропускною здатністю, призначення моделей під кожну роль — нічого з цього не є моделлю. Це структура навколо моделі. Це місяць неромантичної інженерії, що лежить між «дешеві токени існують» і «ти зрелізив робочий софт».
Це, власне, і є весь продукт. Кодинговий агент — це кодинговий агент, а не команда розробки софту. Модель — це товар широкого вжитку; ти можеш замінити її завтра, і після цього місяця я можу точно сказати тобі, скільки насправді дає ця заміна. Цінність ніколи не була в моделі. Цінність — у пайплайні, який змушує будь-яку модель видавати код, яким ти можеш володіти й який можеш підтримувати, і який бере на себе retry, збої формату, тюнінг під кожну модель, щоб ти не платив за них своїми вихідними.
Це та сама обіцянка, яку OwlMeans дає клієнтам, і я щойно витратив місяць, доводячи її собі зсередини: OwlMeans — це команда навколо агента. Ти описуєш свій продукт у вигляді історій користувача. Пайплайн розбиває його, запускає, виправляє й віддає тобі типізоване монорепо, що належить тобі — код, який ти далі розвиваєш будь-яким агентом, яким захочеш. Вартість передбачувана за історію, бо саме пайплайн робить її передбачуваною.
Ти можеш пропустити мій місяць
Тож ось чесна пропозиція, і я зроблю її так, як хотів би, щоб її зробили мені.
Якщо ти вайбкодиш справжній продукт, ти зіткнешся рівно з цим питанням — яка модель, який провайдер, як тримати рахунок низьким, щоб вихід при цьому не розсипався. Можеш зробити те, що зробив я: витратити тижні на під’єднання пресетів, відкрити, що effort: none — це брехня, дивитися, як твої дешеві токени випаровуються в retry, і вивчати модель за моделлю, що там насправді правда. Для мене це вартувало того, бо будувати цей двигун — це моя робота.
Це не твоя робота.
Ти можеш дозволити пайплайну, який уже відбився в цьому бою, зробити це за тебе — підібрати економіку моделей, проковтнути retry, нав’язати структуру й віддати тобі код, яким можна володіти й який можна підтримувати, з вартістю, яку ти можеш передбачити за історію. Ось і вся пропозиція. Я спалив місяць і купу токенів, щоб знайти ці 5x. Ти можеш просто отримати пайплайн.
Якщо проблема в тому, щоб заощадити час і токени на вайбкодингу, це найдешевший місяць R&D, який тобі ніколи не доведеться відпрацьовувати.
OwlMeans — це пайплайн розробки на основі AI: опиши, чого хочеш, у вигляді історій користувача й отримай фулстек-застосунки, чат-боти, AI-агентів і пайплайни даних — типізовані, готові до SSO і твої, щоб розвивати їх далі будь-яким агентом. Подивись, на що він здатен →