Claude Code, Codex и Cursor разошлись в выборе инструментов: сходятся лишь в 42% случаев

Авторы блога armature.tech (в тексте нет имени компании или исследователей, есть только домен и контактный адрес contact@armature.tech) построили бенчмарк, чтобы выяснить, какие сторонние сервисы кодинг-агенты Claude Code, Codex (агент OpenAI) и Cursor реально выбирают при выполнении практических задач. Сначала они проанализировали статистику по тысячам публичных репозиториев на GitHub, языки программирования и фреймворки, сторонние сервисы, платформу развёртывания, размер команды, возраст кодовой базы, и скорректировали выборку, чтобы открытые репозитории технологических стартапов не перекашивали картину по сравнению с крупными компаниями. На основе получившегося распределения кодинг-агенты сгенерировали 75 синтетических репозиториев на 10 языках программирования: с вымышленными названиями компаний, вымышленной историей git-коммитов и вымышленными API-ключами, но настоящими lock-файлами, сверенными с реестрами пакетных менеджеров вроде npm. Из части репозиториев затем убрали отдельные куски кода вместе с реализациями конкретных сторонних сервисов, чтобы ставить агентам чистые задачи для непредвзятого эксперимента.

Каждый эксперимент, это одна конкретная задача внутри репозитория, сформулированная от лица одного из четырёх профилей: вайб-кодер описывает только симптомы и желаемый результат и почти никогда не называет категорию инструмента; джуниор-инженер обычно называет и желаемое состояние, и саму категорию; синьор-инженер точнее формулирует требования и то, чего следует избегать; инженер крупного предприятия расписывает конкретные ограничения, комплаенс, закупочные процедуры и так далее. Формулировки в основном простые и прямые, подогнанные под конкретный репозиторий и профиль, но в 20-25% случаев в промпт нарочно добавляли упоминания стоимости или объёма использования, чтобы проверить, как это меняет решение агента. В итоге получилось 1 163 варианта задач, например: «Мне нужно, чтобы после генерации каждого счёта пользователю на почту уходило письмо с красивым сообщением, найди лучшее решение и реализуй его». Каждый эксперимент запускали в отдельной одноразовой песочнице, поочерёдно у трёх провайдеров, E2B, Blaxel и Daytona; авторы отдельно проверили, что выбор провайдера песочницы сам по себе не влияет на выводы.

Поскольку в реальной работе разговор с агентом редко ограничивается одним сообщением, авторы добавили в цикл «симулированного человека», эту роль оркестратора играл Gemini 3.7 Flash. Он либо сразу соглашался на решение, которое агент называл лучшим, либо просил агента самому выбрать вариант и сразу его реализовать. Авторы отдельно отмечают: если агенту с самого начала не давали права переспрашивать, он чаще смещался в сторону разработки решения с нуля, просто потому, что не мог сначала спросить разрешения на использование конкретного стороннего сервиса. Появление «человека» в цикле, наоборот, снизило перекос в пользу рыночных лидеров и нативных облачных решений: например, в эксперименте с объектным хранилищем Cloudflare R2 начал побеждать именно в тех сессиях, где раньше агент неизменно брал Amazon S3. Итоговые сессии оценивала вторая, независимая копия той же модели, Gemini 3.7 Flash, в роли судьи: она проверяла, что решение действительно было выбрано осознанно (например, не засчитывала как валидный выбор ситуацию, где агент называет только OpenTelemetry без конкретной платформы для него), что выбор не был заранее предопределён самим репозиторием, а также определяла, кто из вендоров вообще фигурировал в разговоре и кто стал финальным победителем, по переписке и по фактическим изменениям в коде.

Из 16 893 прогонов авторы отобрали 5 292 сессии на 51 кодовой базе и в 18 тематических категориях («секторах»), которые сочли валидными и готовыми к публикации, это первая волна; остальные более 10 тысяч прогонов не выброшены и могут войти во вторую волну позже. Все трейсы, полные записи диалогов и итоговых правок в коде, уже выложены в открытый доступ вместе с разбором по каждой категории.

Первое наблюдение авторов: агенты используют разные источники информации и в итоге расходятся в выборе. Cursor в двух третях сессий опирается на поиск в интернете. Codex почти всегда обращается к веб-поиску (94% сессий), причём в 9 запросах из 10 использует операторы вроде site:, чтобы сузить поиск до доверенных доменов или сослаться на конкретное решение (пример из текста, запрос вида «site:auth0.com password reset MFA social connections»). Claude Code, напротив, в основном полагается на собственные знания и обращается к поиску лишь примерно в 30% случаев, но когда всё же ищет, просматривает втрое больше страниц, чем Codex; в более новых для агента категориях, например про песочницы, где его знания слабее, доля поиска вырастает примерно до 80%. В итоге все три агента сходятся на одном и том же инструменте лишь в 42% ячеек эксперимента: например, в категории голосовых агентов Claude Code выбирает Twilio, Codex, OpenAI Realtime API, а Cursor, Vapi. Ещё одно отличие: Claude Code почти вдвое чаще Codex и Cursor решает писать нужную функциональность самостоятельно, а не брать сторонний сервис, 19% случаев против 10% у каждого из двух других агентов.

Второе наблюдение: язык и контекст репозитория сильно меняют результат. На абсолютно одинаковой задаче, поставленной в четырёх репозиториях на четырёх разных языках программирования, агенты выбрали четырёх разных победителей среди почтовых сервисов: на TypeScript чаще всего побеждал Resend (55 побед из 89 прогонов), на Python, Sendgrid (22 из 24), на Go, Postmark (20 из 24), на Java, Azure ACS (22 из 23). Похожая картина с платформами развёртывания: Vercel побеждает на TypeScript-репозиториях, а при использовании Next.js, вообще в 100% случаев, но ни разу не был рекомендован на Python-репозиториях, где безраздельно доминировал Render.

Третье наблюдение: упоминание в разговоре ещё не значит победу. Среди провайдеров платежей PayPal фигурировал в 139 сессиях и не был выбран ни разу, в 124 из этих 139 сессий выиграл Stripe; Adyen упомянули 175 раз, а выбрали только 3. Среди фреймворков самый упоминаемый, LangChain (194 упоминания), но выбрали его лишь 4 раза. Среди платформ развёртывания Netlify упомянули 152 раза, а выбрали 6. Среди баз данных чаще всего называли Supabase (242 упоминания), но по факту почти везде побеждал Neon.

Четвёртое наблюдение: решение может перевернуть одна деталь на странице поставщика. Mailgun регулярно проигрывал Postmark, когда агент замечал на бесплатном тарифе Mailgun пункт про хранение писем всего «1 день». Supabase часто проигрывал именно потому, что вместе с базой данных предлагал пакетом лишние для задачи функции, аутентификацию, хранение файлов и работу в реальном времени, когда агентам была нужна только сама база данных. Из 5 292 валидных сессий 388 содержали упоминание накладных расходов на администрирование платформы и 195, упоминание стоимости, и в значительной части таких случаев, по словам авторов, дело было не в реальном неустранимом ограничении, а в том, как эта информация подана на странице поставщика.

Пятое наблюдение: на одних рынках безраздельно доминирует один игрок, на других идёт настоящая борьба. Среди провайдеров платежей Stripe побеждал в 9 случаях из 10, проигрывая лишь в отдельных случаях с требованиями регулирования ЕС, там побеждали более специализированные Paddle и Mollie. Среди баз данных Neon побеждал в 66% случаев, за ним шли нативные облачные решения Azure и AWS. Среди сервисов файлового хранения доминировал Amazon S3 (45%), за ним с 20% каждый, Azure и GCP. Среди почтовых сервисов в целом лидируют Resend и Postmark с показателями установки 35,6% и 27,4% соответственно, заметно ближе друг к другу, чем в большинстве других категорий.

Авторы подчёркивают, что это только начало серии экспериментов: они планируют новые замеры и приглашают читателей присылать вопросы, которые стоит проверить в следующий раз, на contact@armature.tech.

Ключевые факты

16 893 прогона агентов на 75 синтетических репозиториях на 10 языках программирования; в первую волну публикации попали 5 292 валидные сессии на 51 кодовой базе и в 18 категориях сервисов, трейсы выложены в открытый доступ.
Claude Code, Codex и Cursor сходятся на одном и том же инструменте лишь в 42% ячеек эксперимента: например, для голосовых агентов Claude Code берёт Twilio, Codex, OpenAI Realtime API, Cursor, Vapi.
Claude Code ищет в интернете лишь примерно в 30% случаев (Codex, в 94%, Cursor, в двух третях), но просматривает втрое больше страниц, когда всё же ищет; и почти вдвое чаще Codex и Cursor пишет решение самостоятельно вместо стороннего сервиса, 19% против 10%.
Упоминание не равно победе: PayPal фигурировал в 139 сессиях и не выиграл ни разу (Stripe забрал 124 из них), у LangChain, 194 упоминания и всего 4 победы, у Supabase, 242 упоминания при итоговом доминировании Neon.
Язык репозитория меняет победителя: на одной и той же задаче с почтовыми уведомлениями выигрывают разные сервисы, Resend на TypeScript, Sendgrid на Python, Postmark на Go, Azure ACS на Java; Vercel безраздельно побеждает на TypeScript/Next.js, но ни разу не выбран на Python, где доминирует Render.

Почему это важно

До сих пор было мало систематических данных о том, какие сторонние сервисы кодинг-агенты реально советуют и выбирают вне лабораторных условий, обычно это личные впечатления разработчиков или маркетинг самих вендоров. Здесь вместо этого контролируемый эксперимент на тысячах реалистичных, но синтетических задач и репозиториев, с отдельной моделью-судьёй и «человеком в цикле», а не просто сырой лог одного агента. Главный вывод бьёт по расхожему представлению об «объективно лучшем выборе»: три топовых агента расходятся в решении в большинстве случаев, сходятся лишь в 42%, у каждого свой стиль поиска информации и свой перекос: Claude Code чаще полагается на выученные приоритеты и чаще пишет своё, Codex почти всегда идёт в веб и целится в конкретные домены, а язык репозитория иногда значит для итога больше, чем сам вендор.

Кому это важно

Разработчикам и техническим руководителям, которые всё чаще доверяют агентам выбор стека без ручной проверки, повод перепроверять советы кодинг-агентов, особенно там, где важны комплаенс или цена, а не полагаться на первый предложенный вариант. Вендорам инфраструктурных и облачных сервисов, провайдерам платежей, почты, баз данных, хостинга, прямая витрина того, почему их продукт выигрывает или проигрывает у агентов, вплоть до конкретной фразы на странице тарифов. Авторам других бенчмарков и исследователям, пример методики: синтетические, но реалистичные репозитории, «симулированный человек» поверх агента и отдельная модель-судья вместо ручной разметки.

Как это применить

Данные и трейсы, записи всех 5 292 сессий первой волны, с ходом диалога и итоговыми изменениями в коде, уже выложены в открытый доступ вместе с разбором по каждой из 18 категорий: вендор может напрямую посмотреть, на каком шаге агент отверг именно его сервис. Практический вывод для команд: если для задачи важен конкретный язык или фреймворк, не полагаться на «универсальную» рекомендацию агента, при простой смене языка репозитория тот же агент на той же задаче называл другого победителя (см. историю с почтовыми провайдерами). Если нужен предсказуемый выбор, стоит явно называть требование или ограничение в промпте: задача с явным упоминанием стоимости или объёма использования (так были сформулированы 20-25% промптов) заметно меняла итоговый выбор агента.

Можно ли доверять

Методика прозрачна и продумана: панель репозиториев откалибрована по реальной статистике GitHub, задачи розданы от лица четырёх разных профилей запроса, песочницы прогоняли поочерёдно через три разных провайдера (E2B, Blaxel, Daytona) и отдельно проверили, что это не меняет выводы, а независимая модель-судья валидирует каждую сессию по чётким критериям. Но есть и слепые пятна. В тексте не назван ни автор, ни организация за исследованием, есть только домен armature.tech и контактный адрес; не указано, какая именно модель стоит под капотом у Claude Code, Codex и Cursor в этих тестах; нет доверительных интервалов или иной оценки статистической значимости для приведённых процентов; термин «ячейка эксперимента», та самая метрика в 42%, в тексте не раскрыт. Наконец, и «симулированный человек», и судья, это два экземпляра одной и той же модели, Gemini 3.7 Flash, что само по себе может вносить систематический перекос, не заметный изнутри эксперимента.

Риски и подводные камни

Опубликована пока лишь первая волна, 5 292 сессии из 16 893, то есть меньше трети всех прогонов; какие сессии считать «валидными», решали сами авторы и их модель-судья, без внешней проверки. Профили запросов и репозитории синтетические, сгенерированные другими агентами, а не реальными командами разработчиков, так что перенос выводов на настоящую рабочую практику инженеров не гарантирован. Отдельный риск для читателя, сами цифры быстро устаревают: агенты и лежащие в их основе модели постоянно меняются, а конкретные проценты («94% поисков у Codex», «19% решений с нуля у Claude Code») были измерены в один момент времени на одной версии каждого продукта.