Автотест kimi k2.6: 30× дешевле opus, но дефекты нашёл в нашем pipeline

В апреле 2026 я взял 24 доллара 99 центов на счёте у moonshot ai и решил проверить одну гипотезу.

Гипотеза была простая. Если в нашем dev-pipeline (оркестратор, который автоматизирует разработку) вместо дорогого claude opus 4.7 в роли developer-агента поставить дешёвый kimi k2.6, можно ли получить сопоставимое качество за тридцатую долю стоимости.

Через 3 часа на счёте осталось 24 доллара 25 центов, и автотест дал ответ. Только не на тот вопрос, который я задавал.

Зачем нам этот тест

Последние месяцы мы строим оркестратор, который автоматизирует разработку. Человек формулирует задачу, opus-архитектор пишет план, developer-агент реализует код, критик ревьюит. Каждая роль это отдельная llm, у каждой своя цена.

Стоимость одного типового прогона при разной комплектации developer-агента:

Developer-модель	Стоимость прогона	Стоимость 100 прогонов в день
opus 4.7	$1-3	$6900 в месяц
sonnet 4.6	$0.25-0.50	$1500 в месяц
kimi k2.6	$0.05-0.15	$210 в месяц

Разница между all-opus и all-kimi при 100 прогонах в день это 33 раза. Шесть тысяч долларов в месяц лежит на разнице моделей. Понятно, что вопрос «можно ли заменить opus на kimi» это не теоретический интерес.

Но заменить можно только если качество не упадёт. Иначе экономия превращается в отрицательный roi.

Как тестировал

Написал план автосессии на 2-3 часа. Четыре класса задач разной сложности.

Тривиальная: double(n), удвоить число. Средняя: parsePaymentOrderId, парсер строкового идентификатора с 20 тестами. Мультифайловая: класс HttpError плюс константы плюс тесты, три файла. Строгая: isValidEmail, валидатор почты с двенадцатью правилами и тридцатью тестами. Плюс отдельная задача retryWithBackoff с jitter.

Плюс три не-code режима (research, browser, ops), чтобы проверить границы.

Всего 10 запусков.

Результаты по code-задачам

Все 6 code-прогонов прошли успешно. Сводка ниже.

Задача	Время	Тесты	Финальный score
baseline slugify	9m15s	23/23	approved
parsePaymentOrderId	17m04s	20/20	3 → 8/10
double(n)	4m55s	8/8	9/10
HttpError + константы	14m	12/12	1 → 9/10
isValidEmail (12 правил)	14m46s	30/30	9/10
retryWithBackoff	8m32s	8/8	9/10

101 тест из 101 pass. Средний review score 8.7 из 10. Стоимость кодовой части 0.06-0.12 доллара за прогон.

Kimi иногда добавляла валидацию, которой в тз не было. Например, в retryWithBackoff сама добавила maxAttempts < 1 → throw TypeError. Код чистый, явные if-ветви, без regex-кашицы. Это уже хороший знак: модель не пытается быть слишком умной там, где задача простая.

Перелом: момент, когда я посмотрел на debate-логи

После шести успешных прогонов я открыл артефакты и полез смотреть, как именно проходил debate в каждом из них. Debate в нашем pipeline это фаза, на которой критик оппонирует плану архитектора до того, как developer начнёт писать код. Это страховка от того, что план кривой.

Я открыл DEBATE_HISTORY.md первого прогона. 17 байт. Открыл второго. 17 байт. Открыл все шесть. Везде ровно 17 байт. Это размер пустого шаблона.

Дискуссия как будто была. Логи стримились в реальном времени. А на диск ничего не сохранялось.

Дальше копнул содержание дебатов. В четырёх случаях из шести kimi-критик возвращал ровно 33 символа: «no substantial critique». То есть pipeline считал, что критик отработал, но критик физически не мог найти что-то существенное.

Когда я разобрался почему, картинка сложилась. Критик не видит код проекта. Он судит по плану архитектора и описанию задачи, без сорсов. На таком контексте критика всегда формальная, потому что нет, на чём её строить.

И вот тут произошёл перелом. Я пришёл проверять kimi. А обнаружил, что наша собственная схема организации debate была декоративной все эти месяцы.

Рамка: что показал честный прогон

Если посмотреть на десять находок, которые автотест вытащил из pipeline, складывается одна и та же логика.

Каждая ошибка существовала ровно потому, что pipeline никогда не работал под честной нагрузкой. Все мелкие проблемы успешно прятались за коротким временем выполнения и отсутствием artifacts на диске. Стоило прогнать десять задач подряд, как все десять проблем выкатились наружу.

Дефект	Уровень	Что было сломано
DEBATE_HISTORY.md 17 байт	blocker	История дебатов не писалась на диск
Критик без кода проекта	blocker	Критика формальна, не находит реальных багов
Gateway timeout 60s	blocker	Не-code задачи всегда падают на opus-думалке
Render review broken	major	UI рендерил [undefined] undefined: undefined при alt-схеме json
Claude-developer тихий crash	major	При внутренней ошибке cli возвращал пустой error
Kimi пишет файлы в двух местах	major	На всякий случай дублировала output в src/utils/ и в корень
Path-confusion архитектора	observation	Иногда генерировал хостовые пути вместо sandbox-путей
Maxtokens критика 4k	observation	Reasoning не успевает уместиться в один отрезок
Нет live-наблюдения	observation	Невозможно смотреть прогон в реальном времени из браузера
Нет ассертов на size dialogue	observation	Невозможно автоматически обнаружить «пустой debate»

Десять дефектов в одном прогоне это не плохая модель. Это незрелость собственной инфраструктуры, которую видно только под честной нагрузкой.

Применение: что починил

Закрыл автотест на 10 прогонах. Дальше ушло бы повторение находок. Вместо продолжения сел чинить pipeline.

Сделал семь точечных правок.

Maxtokens критика поднял с 4k до 8k. Добавил fallback на reasoning, когда модель уходит в размышления и не успевает напечатать вывод.

DEBATE_HISTORY.md теперь пишется на каждом раунде. Версии critique и architect-response сохраняются отдельно, чтобы можно было post-mortem-ить любую дискуссию задним числом.

В system-prompt kimi-developer добавил три правила: один файл это один путь, без дублей. Только относительные пути. Не заводи wrapper-директории с именем проекта.

В system-prompt opus-архитектора добавил path-rules. Объяснил, что developer работает в изолированном sandbox, и хостовые пути невалидны.

Review-render стал defensive: толерантен к drift в именах полей в json-ответе opus.

Claude-developer при пустой ошибке теперь подставляет диагностику: exit code, длины stdout и stderr, stack trace.

Gateway timeout поднял с 60 секунд до 200 секунд.

Дополнительно сделал то, чего не было: добавил endpoint GET /pipeline/live?sessionId=... с server-sent events и standalone dashboard, в котором видно timeline каждой фазы в браузере. Это та самая observability, которой не хватало.

Smoke-тест после фиксов

Простая задача capitalize(word). Что произошло на дебатах после фиксов.

Kimi-критик вернул не 33 символа, а 743. И в этой критике нашёл в плане opus три реальных бага.

Первый: план неявно предполагает, что .js-файлы по умолчанию это esm, при том что без package.json или без "type": "module" node трактует их как commonjs. То есть начальная запись esm всегда упадёт на node --check.

Второй: использование word[0] работает с utf-16 кодовыми единицами, а не с unicode code points. На non-bmp символах со surrogate pairs это сломает поведение.

Третий: специальный кейс length === 1 избыточен. Общая логика покрывает его, и наличие специального кейса усугубляет surrogate-pair баг.

Opus откликнулся ответом на 6800 символов. Принял два замечания целиком, одно частично, переписал план на code-point-safe итерацию через destructuring. Второй раунд kimi подтвердила, что план ок. Дальше kimi написала код ровно в трёх файлах, без дубликатов. Opus одобрил 9 из 10. Все 8 тестов pass за 70ms.

Шесть минут реальной технической дискуссии, которая поймала esm/cjs баг до написания строчки кода. Это и есть смысл двухагентной схемы.

Где аргумент проседает

Несколько честных оговорок.

Бенчмарк на десяти задачах не доказывает production-готовность. Десять прогонов это маленькая выборка. На сотне задач kimi может всплыть в специфических кейсах: сложные регулярки, оптимизация под производительность, многомодульная архитектура с зависимостями. Для production я бы повторил тест на 100-200 задачах с разной типологией.

Я не тестировал не-code режимы. Research, browser и ops в этом прогоне все падали по gateway timeout до того, как добраться до собственно kimi. После фикса timeout не было повторного валидационного прогона на этих режимах. Это отдельная задача.

Стоимость прогона включает только api-вызовы. Там нет стоимости электричества, времени человека на ревью реального кода в production-задачах, потенциальной стоимости ошибок, которые kimi пропускает. Реальная total cost of ownership выше, чем 12 центов.

Качество критика deepseek-reasoner я не сравнивал с kimi-критиком. В прогоне я заменил kimi на critic-роли на deepseek-reasoner после того, как старая kimi-конфигурация выдавала пустую критику. Это могло смешать переменные: возможно, часть улучшения это смена модели, а не фикс контекста. Чистый эксперимент потребовал бы a/b теста.

Сама методология автотеста потребовала переработки в процессе. В финальном отчёте я подробно расписал, что сам автотест мог бы уложиться в 60-90 минут вместо 3 часов. Часть времени ушла на повторное подтверждение известных находок и две ошибки после compact-сессии (перепутал endpoint). Фиксация этого не самобичевание, а часть методики: следующие автотесты не повторят.

Финал

Если выжать в одну фразу:

Честный автотест дешёвой модели это всегда стресс-тест архитектуры, в которую её ставят. Если архитектура хрупкая, модель это подсветит просто тем, что отработает по правде.

Бюджет всего эксперимента 74 цента. Найдено десять дефектов в собственной инфраструктуре, шесть из которых blocker-level. Сэкономлено по прогнозу 5-7 тысяч долларов в месяц на api при ramp-up до 100 прогонов в день.

Это и есть формула, ради которой стоит делать автотесты на дешёвых моделях. Не «работает ли kimi». А «работает ли наш pipeline под честной нагрузкой». Первый вопрос дал ответ за десять минут. Второй за десять прогонов.

Опубликовано: 2026-04-23, через несколько часов после закрытия автотеста.