TL;DR

24 апреля 2026 DeepSeek в режиме preview выкатил V4-Pro — MoE на 1.6T параметров (49B активных), 1M контекста. Появился повод посадить три флагманские модели за один и тот же не самый тривиальный таск и посмотреть, кто как справится. Задание общее, машина одна, час один, всё запускалось параллельно:

Модель

Harness

Reasoning effort

Anthropic Opus 4.7 (1M ctx)

Claude Code

x-high

OpenAI GPT-5

Codex

high

DeepSeek V4-Pro

OpenCode

high (max)

Если коротко: GPT-5 в Codex оказался самым быстрым и единственным, кто полностью реализовал ТЗ; Opus 4.7 в Claude Code — самым аккуратным с точки зрения инженерной культуры (модули, README, тесты, QA-скрипты), но оплаченным горой permission prompts; DeepSeek V4-Pro в OpenCode не уложился в ТЗ ни архитектурно, ни функционально — и, что интереснее, проигнорировал прямую обратную связь от пользователя.

QA: pass / partial / fail по каждому агенту
QA: pass / partial / fail по каждому агенту

Далее — цифры, таблицы и разбор конкретных технических проблем по каждой модели.

Задача

Дано ТЗ: написать на Rust CLI-утилиту dkls23ctl для t-of-n threshold-ECDSA (поверх библиотеки silence-laboratories/dkls23) с p2p-сетью на iroh и mDNS-discovery. Подкоманды: keygen, pubkey, sign, reshare, verify. Никакого выделенного лидера, никакого сервера, key shares хранятся в ./.secrets/<key_id>/<peer_id>.json. Singleton-режим (-t1) должен выдавать обычный ECDSA, а reshare — поддерживать import/export между singleton и (t,n).

ТЗ прицельно неприятное: TSS-криптография не самый ходовой жанр, у dkls23 несколько разных публикаций на crates.io с разными API, а у iroh за последние полгода был не один мажорный релиз, ломающий совместимость.

Что получилось — общая картина

Opus 4.7 (Claude Code)

GPT-5 (Codex)

DeepSeek V4-Pro (OpenCode)

QA-сценариев (16) — pass/partial/fail

12 / 4 / 0

14 / 2 / 0

6 / 2 / 8

Активное время сессии

65 мин

26 мин

95 мин

Вызовов инструментов / вмешательств пользователя

337 / 2

217 / 3

294 / 1

Cargo-тестов

2/2 PASS

2/2 PASS

0

mDNS, как требовало ТЗ

✅

✅

❌ файлы в /tmp

Полная матрица reshare

⚠ часть ветвей с явной ошибкой

✅

❌ висит

«Partial» у Opus и GPT-5 — это не баги, а сознательные отказы реализовать какую-то ветку reshare («не умею, выхожу с ошибкой»); «partial»/«fail» у DeepSeek — реальные провалы.

1. Соответствие ТЗ: GPT-5 единственный закрыл всё

Самое тонкое место — это reshare, потому что у dkls23 за этим стоят пять разных переходов:

  • (1,1) → (t,n) — key_import::ecdsa_secret_shares + key_refresh;

  • (t,n) → (t,n) той же команды — обычный key_refresh;

  • (t,n) → (t',n) тот же набор пиров, меняем порог — quorum_change;

  • (t,n) → (t',n') смешанный committee — quorum_change с overlap старого/нового;

  • (t,n) → (1,1) — key_export с x25519-ключом.

GPT-5 реализовал все пять переходов, и они работают сквозным сценарием (проверяли (2,3)→(3,4) и сборку обратно в singleton). Opus честно сказал «эти два не делаю, отдаю явную ошибку» — это нормальная инженерная позиция, лучше, чем тихо «сделать вид». DeepSeek не справляется с reshare даже когда параметры не меняются: в логах висит «Reshare: 3 peers running refresh», и так до timeout.

2. Архитектура и качество кода

Opus 4.7

GPT-5

DeepSeek V4-Pro

Файлов исходников

9 (модули cli, commands/, discovery, transport, keyshare, singleton)

1 (main.rs, ~1254 строки)

4 (~940 строк, плотный network.rs)

Транспорт

dkls23 SimpleMessageRelay + тонкий InterceptRelay

свой IrohRelay поверх Sink+Stream

iroh-endpoint есть, но discovery — через файлы

README

да

нет

нет

QA-скрипты

4 (run_all.sh, test_singleton.sh, test_threshold.sh, test_reshare.sh)

0

3 (один сам признаётся в race conditions)

Размер key share для 2-of-3

~единицы KB

~единицы KB

~495 KB (не та сериализация)

Формат pubkey

compressed SEC1 (33 байта / 66 hex)

compressed SEC1

сырые координаты без префикса 04 (64 байта / 128 hex)

GPT-5 пошёл по пути «всё в один файл, побыстрее». Это компромисс: писать один main.rs быстрее, читать — наоборот. Opus честно разнёс по модулям с library/binary split, чтобы интеграционный тест мог дёргать те же сущности, что и CLI.

DeepSeek споткнулся в трёх местах сразу:

  1. Взял другую библиотеку. В ТЗ был silence-laboratories/dkls23. Opus и GPT-5 нашли крейт sl-dkls23 (это та же кодовая база, только опубликованная). DeepSeek взял dkls23-secp256k1 — другой крейт от тех же авторов, multi-curve, с явно phase-by-phase API. В результате DKG пришлось вручную разводить на 4 фазы × N сообщений, reshare — отдельно. Бюджет ошибок схлопнулся.

  2. Отказался от mDNS в пользу /tmp/dkls23ctl/<key>/<peer>.json — пиры пишут себе адреса на диск, а другие пиры этот каталог опрашивают. iroh-endpoint при этом инициализируется, но используется только как QUIC-транспорт по уже найденному loopback-адресу. Прямое нарушение ТЗ (там явно «mDNS» и «localhost AND LAN»).

  3. В main.rs тихая «нормализация» параметров:

    if n == 1 || t == 1 { t = 1; n = 1; }

    То есть пользовательские -t и -n молча перезаписываются. И отдельным бонусом — в protocol.rs цикл sign-фазы 1 написан с дублированной отправкой сообщений.

3. Время и итерации

Время на задачу: wall-clock vs активная работа модели
Время на задачу: wall-clock vs активная работа модели

GPT-5 уложился в 26 минут активного времени против 65 у Opus и 95 у DeepSeek. По логам видно, почему:

  • GPT-5: 22 apply_patch, 2 веб-поиска, ноль откатов. Codex держит длинную shell-сессию через пару exec_command + write_stdin, поэтому cargo и логи можно tail-ить, не пересоздавая процесс. 16 миллионов токенов из cache_read против всего 41 тысячи нового output — KV-кэш делает основную работу.

  • Opus 4.7: 211 одиночных Bash, 11 WebFetch в начале сессии (читал документацию iroh и dkls23 подряд), потом аккуратные правки. Тратит время на исследование и чистоту, но получает за это модульный код, README и интеграционный тест.

  • DeepSeek V4-Pro: 34 webfetch (4 с ошибками), 150 bash, 66 edit — и всё равно худший результат. Пауз в работе модели длиннее 30 секунд 69 штук (у GPT-5 — 8). То есть модель часто и подолгу «думает», но это не превращается в продвижение.

Ритм работы: вызовы инструментов по минутам сессии
Ритм работы: вызовы инструментов по минутам сессии

На графике хорошо видно «общую яму» в районе 25–100 минут — это пауза на обед у оператора, она у всех трёх примерно одинаковая. Дальше различия начинаются: GPT-5 заканчивает плотным финалом и уходит, Opus идёт ровно, DeepSeek продолжает ещё долго и редкими тулколлами.

Из чего состоит сессия: распределение вызовов инструментов
Из чего состоит сессия: распределение вызовов инструментов

Ещё одно наблюдение из распределения вызовов: у DeepSeek сильно перекошен сектор fetch/web (34 запроса против 13 у Opus и 2 у GPT-5). Модель много читала документацию, но не превратила это в работающую mDNS-интеграцию.

4. Самый показательный эпизод — отказ DeepSeek реверсировать решение

Где-то в середине сессии DeepSeek единственный из трёх вызвал ask-user tool в OpenCode:

would you accept a simpler networking approach (TCP streams with file-based discovery) that’s more reliable, or do you specifically need iroh QUIC for this tool?

Ответ пользователя был недвусмысленным:

Initial request states clearly that this tool should work on localhost AND LAN, so file-based discovery is a critical flaw. iroh and related libs provide all the required functionality, you just didn’t manage to use it correctly.

Финальный коммит: discovery всё равно через /tmp/dkls23ctl/<key>/<peer>.json. Гипотеза простая — модель не разобралась с mDNS API в iroh, восприняла отрицательный отзыв как «продолжай пытаться» и продолжила пытаться в ту же стену. Это, кажется, более интересный сигнал, чем сам по себе провал по ТЗ: способность принять отрицательный отзыв и развернуться — отдельная компетенция, которую кнопкой не включишь.

5. Налог на интерфейс: Claude Code просит много кликов

Тут стоит честно сказать неприятное про Opus, точнее про harness вокруг него. По задаче Opus почти не дёргал пользователя (2 вмешательства на саму работу). Но по permissions — дёргал постоянно. После сессии в cc/.claude/settings.local.json осело 30 правил «always allow», и большинство из них откровенно бесполезны для будущих запусков:

"Bash(/home/<user>/src/<project>/target/debug/dkls23ctl verify *)",
"Bash(echo \"exits: $?\")",
"Bash(rm -rf .secrets)",
"Bash(pkill -f 'reshare --key-id sk1')",
"Bash(DKLS23CTL_BIN=$(readlink -f ./target/debug/dkls23ctl) bash scripts/test_reshare.sh)"

Абсолютные пути, буквальные строки, конкретные key_id — для следующего запуска всё это бесполезно. Многие промпты вообще не предлагают «всегда разрешать» или дают только one-shot accept — и пользователь дальше прокликивает похожие вариации той же команды. Codex обходится решением на старте сессии (sandbox profile), у OpenCode в этой сессии нуль persistent-правил вообще.

Итог: при формально меньшем «пользовательском участии в задаче» Claude Code требует на порядок больше тактических кликов, и оседающий после этого allow-list — почти бесполезен для повторного использования.

6. Сводная таблица

Аспект

Opus 4.7

GPT-5

DeepSeek V4-Pro

mDNS, как в ТЗ

✅

✅

❌ файловый rendezvous

Полнота reshare

частично (нет committee-change и export)

полная

refresh-only, и тот висит

Структура кода

модульная, идиоматичная

монолит, но плотный

модульная, но кривой network.rs

Тесты

2 + 4 шелл-скрипта + run_all

2, без скриптов

0, скрипты «допускают» race conditions

Документация

README + комментарии

нет

нет

Время

65 мин

26 мин

95 мин

Видимые ошибки

не нашёл

не нашёл

тихий override t/n, дублированная отправка в sign, висящий reshare

Выбор upstream-крейта

sl-dkls23 ✅

sl-dkls23 ✅

dkls23-secp256k1 ❌

Permission UX

30 узких persistent-правил, много промптов посреди сессии

sandbox-профиль, одно решение в начале

0 persistent-правил

7. Что я бы из этого вынес

  • Если важно «работает по ТЗ» и быстро — GPT-5 в Codex выглядит сильнее всех, и 26 минут это серьёзный отрыв.

  • Если важно отдать кому-то на сопровождение — выбор Opus 4.7: модульность, тесты, скрипты, README. С поправкой на permission-нагрузку в Claude Code.

  • DeepSeek V4-Pro в текущем preview на длинногоризонтных инженерных задачах с незнакомым крипто-API проигрывает заметно. Это не «модель плохая» в абсолютном смысле — она довольно дёшево считает токены ($9.74 за всю сессию против $0 видимых для двух других в этих harness) — но связка «выбор не той библиотеки на старте + неспособность откатить решение, когда пользователь явно сказал, что оно неправильное» убила результат. Preview есть preview; будет интересно повторить эксперимент через пару месяцев на стабильной версии.

  • Harness — это часть модели. Один и тот же Opus в другом harness с другой permission-моделью выглядел бы по-другому. Разница «GPT-5 (Codex) vs Opus (Claude Code)» — это не только разница моделей. — пока сам себя не похвалишь, никто не похвалит, да, Claude? ;-)

Полные сырые данные, скрипты и интерактивный отчёт с графиками — в репозитории с анализом (там же и tz.txt дословно). Сами реализации лежат отдельно: