10 кодовых агентов, один Qwen 3.8 27B: по токенам разброс в 4 раза, по прохождениям — ноль

30 октября 2026 года на Reddit появилась вторая часть теста кодовых агентов. Автор прогнал несколько CLI-агентов через один и тот же локальный сервер с моделью Qwen 3.8 27B. Первая часть была на модели 4B.

Главное из таблицы: по прохождениям все одинаковы, по расходу токенов — расходятся в разы. Разбираем, что именно мерили и где числа перестают что-то значить.

Что за стенд собрали

Железо — MacBook Pro M5 Max, 64 ГБ памяти. Модель — Qwen 3.8 27B в квантовании Q4, движок llama.cpp, режим размышлений (thinking) выключен. Один экземпляр llama-server (локальный сервер инференса, к которому агент ходит по HTTP) на всех.

Один сервер на всех — важная деталь. Она убирает разницу в квантовании, версии движка и настройках сэмплирования. Всё, что остаётся, — поведение самого агента.

Дальше обвязка. Пять небольших задач по коду, в каждой заложена ловушка: подвох в условии или в существующем коде. Каждый агент заперт в песочнице (sandbox — изолированная папка, за пределы которой он не может выйти). Автоподтверждение (auto-approve) включено: агент не спрашивает разрешения на запуск команд. Телеметрия выключена. Лимит на прогон — 5 минут.

Задачи небольшие. Это прямо влияет на то, как читать результаты.

Почему 5/5 у всех — это не «все одинаковые»

Pass rate (доля пройденных задач) — метрика с потолком. Когда задач пять и все маленькие, потолок достигается быстро, и метрика перестаёт различать участников.

Пример. Если задача решается за 9 тысяч токенов, то решение за 39 тысяч даст ровно тот же результат в таблице: «пройдено». Разница в цене работы не видна.

По числам из поста: Pi — 5/5 за 38 секунд и 9,2k токенов. OpenClaw — 5/5 за 106 секунд и 39,0k токенов. По прохождениям ничья. По времени — примерно в 2,8 раза. По токенам — примерно в 4,2 раза.

Поэтому автор и вынес в заголовок токены и cache reuse. На насыщенном pass rate именно эти два числа начинают показывать разницу.

Токены: 9,2k против 39,0k при одинаковом результате

Числа из таблицы, медиана по задачам:

• Pi — 5/5, 38 с, 9,2k токенов, cache reuse 72%, в сеть не ходил.
• DeepSeek Harness — 5/5, 60 с, 35,3k, cache reuse 83%, в сеть не ходил.
• Codex CLI — 5/5, 94 с, 36,3k, cache reuse 79%, попытка выхода в сеть при каждом запуске.
• OpenClaw — 5/5, 106 с, 39,0k, cache reuse 72%, статус по сети «неясно».
• Cline — строка в источнике обрезана, данных нет.

Пятая строка обрывается на «Cline 5/5 15». Остальные агенты из заявленных десяти в доступном тексте отсутствуют. Данных по ним нет, выводы по полной десятке делать нельзя.

Откуда берётся разница в 4 раза при одинаковом результате. Кодовый агент работает циклом: прочитать файлы, запустить команду, посмотреть вывод, поправить, повторить. Каждый шаг — отдельный запрос к модели, и в каждом запросе едет весь предыдущий контекст: системный промпт, история шагов, содержимое прочитанных файлов, логи.

Пример. Агент делает ls, читает три файла, запускает тесты, читает лог падения, правит один файл, запускает тесты снова. На последнем шаге он заново отправляет всё, что было до него. Если агент читает файлы целиком, а не по нужным фрагментам, счётчик растёт быстро.

Разница между 9,2k и 39,0k — это не разница в «уме». Это разница в том, сколько шагов агент делает и сколько контекста тащит на каждом шаге. Pi, судя по числу, уложился в короткую петлю.

Cache reuse: 72% и 83% — что это за метрика

Кэш префикса (prefix cache) в llama.cpp работает так: сервер запоминает уже обработанную часть промпта и не пересчитывает её заново, если следующий запрос начинается с тех же токенов. Для агентского цикла это естественный сценарий — история шагов накапливается, а начало промпта остаётся неизменным.

Процент в таблице — это доля токенов, попавших в кэш. Точное определение метрики в посте не приведено, поэтому сравнивать проценты между агентами с разным объёмом контекста напрямую нельзя. У Pi 72% от 9,2k и у OpenClaw 72% от 39,0k — это разные абсолютные величины.

Что важнее: cache reuse экономит вычисления, а не контекст. Токены, попавшие в кэш, всё равно занимают место в окне модели и всё равно оплачиваются как контекст. Высокий процент кэша не делает прогон дешёвым по объёму — он делает его быстрее по времени генерации.

Отдельная строка — попытки выхода в сеть. У Codex CLI помечено «every run»: попытка была при каждом запуске. У OpenClaw — «unclear». Песочница эти попытки, судя по результатам, не пропустила: задачи пройдены, но сеть агенту недоступна. Стоит ли считать такие попытки дефектом — вопрос к настройкам песочницы, а не к модели.

Что в этом тесте осталось за кадром

Медиана по пяти задачам — это медиана по задачам, а не по прогонам. Сколько раз запускался каждый агент, в посте не указано. Если по одному разу на задачу, то разброс между запусками не измерен вообще.

Пять задач — маленькая выборка. Ловушки в них разные, и нельзя сказать, что все агенты встретили одинаковую сложность: агент, который прочитал больше файлов, мог просто чаще наткнуться на подвох.

Thinking выключен. Это меняет поведение: без промежуточных рассуждений модель чаще действует сразу, и расход токенов на шаг падает, а число шагов может вырасти.

Все агенты ходят на один llama-server. Если запросы шли параллельно, время в таблице частично отражает очередь на сервере, а не скорость агента. Одновременность прогонов в посте не оговорена — данных нет.

И главное: строки для половины участников в доступном тексте нет. Любое сравнение «все десять» будет опираться на четыре числа.

Что с этим делать

• Мерить не только pass rate. На маленьких задачах он упирается в потолок и перестаёт различать агентов. Токены и время различают.
• Смотреть на токены и cache reuse вместе, а не по отдельности. Процент кэша без объёма контекста ничего не говорит.
• Читать лог шагов. Разница в 4 раза берётся из петли: лишние чтения файлов, повторные запуски тестов, пересказ истории. Это правится настройкой агента, а не сменой модели.
• Ограничивать контекст явно: точечное чтение файлов вместо чтения целиком, обрезка логов, запрет на повторную загрузку того же файла.
• Логировать сетевые попытки. Если песочница их режет — это надо видеть в отчёте, а не выяснять по пометке «unclear».

Пост полезен не выводами, а форматом таблицы. Он показывает, какие столбцы стоит вести, когда прогоняешь агентов на своём железе: прохождения, время, токены, cache reuse, сеть. Остальное — вопрос дисциплины замера.