Claude Code, Codex і Cursor: той самий мозок, різний код
Коли завдання просте й чітке — код виходить майже однаковим
Автор дав Claude Code, Codex і Cursor одну й ту саму модель — Claude Sonnet 5.5 у режимі high reasoning — і однакове завдання: доробити WebSocket-проксі, який передає дані з Home Assistant на Kindle-дашборд. У коді вже було чотири відомі баги, плюс запит на auto-reconnect. Додаткова складність — старий Kindle підтримує лише ECMAScript 5, тож сучасний JS-синтаксис там не працює.
Результат перевіряли набором із 16 тестів, навмисно прихованим від агентів: якщо агент бачить тест, він пише код так, щоб тест пройшов, а не щоб робота дійсно працювала. Усі три інструменти набрали 16 з 16.
Там, де рішення було локальним і однозначним — фікс auto-reconnect, зміни в дашборді — код вийшов майже ідентичним: Codex і Claude Code навіть назвали нову функцію однаково. Усі три самостійно додали однакові речі, яких ніхто не просив і яких не було у файлі TASK.md: бейдж про втрату зв'язку з проксі, фікс падіння на зламаному JSON, фікс плутанини return/continue і перевірку статусу проксі при першому підключенні.
Де та сама модель приймає різні рішення
Розбіжності почалися там, де вибір був відкритим — скільки переписувати, а не просто латати. При виправленні модуля проксі Codex залишив більшість оригінального коду й наклав патч. Cursor і Claude Code натомість розбили файл на менші методи: Cursor зберіг 43% оригінального коду (хоча в звіті написав, що «переписав» файл), Claude Code — лише 34%.
Різним був і підхід до самоперевірки: Codex прогнав 10 тестів, Cursor — 33, Claude Code — 42, бо запустив один набір тричі для надійності. Claude Code пішов ще далі — повернув у код оригінальний баг, щоб перевірити, чи власні тести справді його відловлюють. На цьому проєкті це не мало значення, але на більшому й заплутанішому коді такий крок може стати різницею між робочим і непрацюючим результатом.
Codex і Claude Code завершили першу задачу до десятої хвилини, тож лише Cursor дійшов до другого промпту з новим запитом — додати бейдж офлайн-статусу й повідомлення Home Assistant. Автор хотів перевірити, як інструмент реагує, коли під час роботи підкидають новий запит («steering»), але Cursor за замовчуванням просто ставить нову команду в черту, а не обробляє одразу.
Налаштування під Windows — три різні пастки
Жоден з інструментів не запрацював одразу «з коробки» на Windows. Codex ігнорував прапорець `--ask-for-approval`, поки його не прописали в TOML-файлі налаштувань, а потім сервер падав, бо не могла запуститись PowerShell без встановленої змінної середовища. Claude Code за замовчуванням хоче працювати через Bash, тож довелося окремо вказати прапорець для PowerShell замість спроби залізти у WSL. Cursor же відкрив сесію в режимі запиту підтвердження, хоча автор явно вмикав авто-режим.
Ціна і що з цим робити
За той самий Sonnet 5.5 найдешевше вийшло в Claude Code. Codex через OpenRouter платив повну ціну — токени з кешу, схоже, не підхоплювались узагалі. У Cursor потрібна платна підписка для сторонніх моделей плюс додаткова оплата за API, але саме там токени виявились дешевшими: $1.11 за приблизно 3,31 млн токенів проти $3.73 за 1,64 млн токенів у Codex/OpenRouter — за припущенням автора, завдяки читанню з кешу.
Коли завдання просте, вибір інструмента майже не впливає на якість коду — модель однакова, і думає вона однаково. Вибирати варто за тим, що важливо саме вам: мінімальні діфи й швидкість (Codex), агент, що сам перевіряє свою роботу (Claude Code), чи робота в IDE за вищу ціну (Cursor). Перед тим як довіряти результату на серйозному проєкті — перевіряйте тестами, яких агент не бачив, і дивіться, який відсоток оригінального файлу інструмент реально переписав.