Аналоги Claude Code: что перенесётся вместе с проектом
Аналоги Claude Code сравниваю по переносу инструкций, команд и подключений. Что проверить в Codex и Gemini CLI перед первой правкой своего проекта и оплатой.
Д
Денис
Продакт LibraChat
11 мин чтения
Инструкцию проекта можно сохранить в знакомом Markdown-файле. С привычным поведением агента всё сложнее: команды, подключения и ограничения требуют отдельной сверки. Когда я начал смотреть аналоги Claude Code, именно эта разница изменила мой короткий список. Мне нужен кандидат, с которым проект продолжит жить по своим правилам, а первая правка останется понятной человеку.
Для сравнения я взял Codex CLI и Gemini CLI. Оба относятся к инструментам работы с локальной средой, поэтому здесь есть общий предмет выбора. Я сверил официальные функции и подготовил карточку переноса из шести строк. Устанавливать агентов и запускать их на рабочем репозитории для этого разбора не стал: дальше отделяю документированный маршрут от предложенной проверки.
Какие аналоги Claude Code работают с проектом?
Claude Code в официальном описании читает кодовую базу, меняет файлы и запускает команды. Если ты используешь именно такой процесс, обычного ответа с функцией в чате может оказаться мало. Замена должна помогать продолжать работу в проекте: видеть нужные файлы, выполнять разрешённые действия и оставлять результат, который можно просмотреть.
Codex CLI описан OpenAI как терминальный инструмент для локального репозитория. Он изучает файлы, вносит изменения и использует установленные инструменты разработки. Модель, усилие рассуждения и полномочия выбираются отдельно. Я рассматриваю его кандидатом, когда хочу сохранить терминальный цикл и явно проверить, какие части привычной настройки переходят из Claude Code.
Gemini CLI тоже работает с инструментами локальной среды: в справке перечислены чтение файлов и выполнение команд, а запросы инструментов оцениваются по политике безопасности. Поэтому его можно включить в тот же список кандидатов. При выборе потребуется проверить действующие настройки контекста и разрешений, а не только название модели в строке состояния.
Кандидат · Подтверждённый рабочий маршрут · Что важно при замене
Claude Code, исходный процесс — Кодовая база, изменения файлов, команды — Какие правила и подключения ты действительно используешь сейчас
Codex CLI — Локальный репозиторий и инструменты разработки; официальный импорт поддерживаемой настройки из Claude Code — Состав выбранного импорта и пункты, требующие завершения настройки
Gemini CLI — Инструменты файловой системы и команд; контекст из инструкционных файлов — Какие инструкции загружены и как устроены политики действий
Я намеренно не ставлю в таблицу скорость исправления бага. Для неё нужны настоящие прогоны на одинаковом проекте и одинаковых условиях. Официальное описание позволяет определить подходящий класс замены. Оно не подтверждает, что конкретный кандидат лучше справится с твоим кодом или потребует меньше ручного внимания.
Есть полезный первый фильтр: какое действие ты потеряешь после ухода от прежнего инструмента? Если ответ — «короткий вопрос по функции», выбор широк. Если это «команда команды, которая собирает отчёт по проекту и проверяет его перед сдачей», уже нужно разбирать устройство команды. Аналог выбирается по необходимой работе, которую предстоит продолжить.
Что перенести из инструкций Claude Code?
Сначала я смотрел на имена файлов: `CLAUDE.md`, `AGENTS.md`, `GEMINI.md`. Казалось, перенос сведётся к смене вывески. В текущей документации картина интереснее. Claude Code умеет использовать существующий `AGENTS.md`; у Gemini CLI имя контекстного файла настраивается, в том числе списком. Разница между агентами не обязана начинаться с трёх копий одного текста.
Для Codex долговременные правила проекта описываются через `AGENTS.md`. У Gemini CLI контекст загружается из нескольких уровней, а команда `/memory show` позволяет посмотреть объединённые инструкции. Мне важно именно это наблюдаемое состояние: какой текст дошёл до текущей сессии. Само присутствие файла в папке ещё не отвечает на вопрос, применилось ли нужное правило.
Вот шесть строк моей карточки переноса. Они описывают условный небольшой проект; никаких рабочих секретов или конкретной внутренней инфраструктуры в них нет:
Где лежат постоянные правила и какие вложенные каталоги их уточняют.
Какие файлы разрешено читать и какие исключены из задачи.
Какие изменения входят в поручение и какие требуют нового решения.
Какие команды проверяют затронутое поведение.
Какие подключения и дополнительные инструменты нужны для работы.
Как выглядит сдача: разница файлов, реальные проверки, оставшиеся вопросы.
Эта карточка короче истории длинного разговора. В ней сохраняется то, что должно работать и в следующем чате. Если важный запрет существует только в реплике двухнедельной давности, я перенесу его в постоянное правило до выбора замены. Так проще проверить каждого кандидата на одном и том же обязательстве.
Однако инструкцию и механизм исполнения нужно описывать отдельно. Фраза «перед сдачей проверь форматирование» задаёт требование. Hook или команда, запускающая проверку на определённом событии, задаёт механизм. После перехода текст может сохраниться, а автоматический запуск — измениться. В карточке я отмечу оба пункта, чтобы случайно не принять одно за другое.
И не буду переписывать правила только ради нового инструмента, если смысл уже точный. Сначала выясню, может ли он прочитать существующий допустимый файл. Если нужна отдельная настройка, сохраню общий источник требований и ясную связь между версиями. Иначе два почти одинаковых документа быстро начнут расходиться, а ошибка будет выглядеть как каприз модели.
Отдельная строка нужна для области действия правила. В учебном проекте основной текст можно редактировать, а в каталоге с примерами названия должны сохраняться буквально. Общая фраза «улучшай понятность» не должна отменять локальное требование. При переходе я проверил бы именно этот узкий случай: какую инструкцию кандидат назовёт для конкретного файла и заметит ли более точное ограничение. Копирование всех правил в один длинный абзац способно скрыть их область действия.
Какие аналоги Claude Code сохранят привычный контроль?
У Codex есть официальный импорт из поддерживаемой настройки Claude Code. Документация перечисляет инструкции, настройки, навыки, плагины, проекты и недавнюю работу; пользователь выбирает состав переноса. После импорта нужно проверить ограничения инструментов, подключения и hooks. Это удобный маршрут для короткого списка, но не сертификат совместимости всего накопленного окружения.
Из этого я делаю осторожный практический вывод: если проект сильно зависит от настройки Claude Code, Codex стоит рассмотреть сначала на переносимости нужных элементов. Не обязательно начинать с повторного ручного описания всей привычки. Но завершение импорта и завершение проверки процесса — разные отметки. Для первой достаточно механизма переноса, для второй нужна конкретная работа в проекте.
У Gemini CLI я отдельно проверил бы иерархию инструкций и инструменты текущей сессии. В его справке описаны глобальный, рабочий и обнаруживаемый при обращении к каталогу контекст. Это позволяет выразить общие и локальные правила. При этом я не вывожу из документации об инструкциях автоматический перенос всех настроек Claude Code: такого опыта в этом разборе нет.
Контроль я оцениваю через три понятных вопроса:
Может ли человек увидеть, какие материалы агент собирается использовать?
Видно ли предлагаемое действие до того момента, когда оно затронет проект?
Можно ли после выполнения сопоставить отчёт с изменёнными файлами и реальными командами?
Ответ зависит и от выбранной конфигурации. Один продукт допускает разные полномочия, а рабочая команда может установить дополнительные ограничения. Поэтому я не обещаю, что каждое действие любого кандидата обязательно потребует отдельной кнопки подтверждения. Мне нужно понять режим, который действительно будет применяться в выбранном окружении.
Для переноса важны и сохранённые решения человека. Например, в проекте запретили менять формат публичного ответа без обсуждения. Такой запрет должен остаться понятным после смены агента, даже если новый кандидат предложит более красивую архитектуру. Польза замены измеряется продолжением нужной работы, а не числом улучшений, которых никто не заказывал.
Что проверить в командах и подключениях?
Здесь я начинаю с самой скучной строки: где выполняется команда. Один и тот же короткий запуск может использовать разные версии инструментов или другой рабочий каталог. Если прежний агент работал в подготовленной среде, новый не получает её свойства от одного факта открытия той же папки. Условия выполнения нужно подтвердить заново.
Предположим, у учебного проекта есть проверка названий файлов и отдельная сборка справочника. Я запишу назначение обеих команд, ожидаемый результат и нужные зависимости. Затем сверю это с новым окружением. Фраза «все проверки прошли» помогает только тогда, когда понятно, какие команды за ней стоят и были ли они действительно доступны.
Подключения я переношу ещё осторожнее. В документации импорта OpenAI прямо отмечено, что части настройки могут потребовать завершения, включая повторный вход и проверку поведения hooks. Это повод пройти список необходимых связей по одной. Наличие названия подключения в конфигурации не означает, что авторизация состоялась или нужное действие уже разрешено.
Для сравнения достаточно придуманных имён и открытого учебного материала. Секреты нельзя вклеивать в пример инструкции или отправлять чату, чтобы он «сам разобрал настройки». Владелец проекта проверяет чувствительные параметры в своей среде. В статье мне нужен состав действий и признаки готовности, а не содержимое чужих настроек.
Я также оставлю список того, что переносить не требуется. Привычная команда могла обслуживать старую задачу, которой больше нет. Поддерживать её только ради сходства с прежним агентом бессмысленно. При выборе замены полезно сохранить необходимые функции и осознанно убрать устаревшие, записав это решение. Тогда отсутствие старой детали будет объяснено заранее.
Первые сомнения можно снять вообще без изменения файлов. Попросить нового кандидата перечислить, как он понимает порядок сборки учебного справочника, и сверить ответ с собственным списком. Если он назвал несуществующую команду, я узнаю об этом до запуска. Если честно попросил недостающую настройку, добавлю её допустимую часть. Такой разговор не подтверждает работоспособность сборки, зато обнаруживает разрыв контекста, который иначе пришлось бы искать после неудачной правки.
Есть ли бесплатный путь без неприятного счёта?
Запрос «бесплатный аналог Claude Code» я разбираю на несколько условий: способ входа, доступный объём модели, подключённые сервисы и стоимость дальнейшей работы. Свободная установка программы сама по себе не устанавливает цену всех этих частей. Особенно если кандидат допускает несколько вариантов авторизации и разных поставщиков вычислений.
В справке Gemini CLI описаны вход через Google, ключ Gemini API и Vertex AI. Условия выбранного варианта нужно смотреть для своего аккаунта и организации. Codex CLI тоже предлагает поддерживаемые способы входа. Я не переношу наличие подписки у одного продукта на другой и не называю пробный доступ обещанием постоянного безлимита.
Для себя я сравнил бы расходы после нескольких принятых изменений. В запись попали бы не только обращения к модели, но и настройка окружения, восстановление недостающих правил, время чтения разницы файлов. Самая дешёвая первая команда может оказаться неудобной, если каждый следующий шаг требует заново объяснять известный проекту порядок.
Если пока нужен только разбор постановки в обычном чате, можно сопоставить условия подготовки текста в LibraChat. Это отдельная работа до запуска агента. Я не приписываю этому тарифу доступ к Codex, Gemini CLI или окружению Claude Code: у внешних инструментов собственные условия.
Как я проверил бы переход на одном изменении?
Для пилота возьму учебный генератор справочника. Нужно изменить порядок двух разделов, сохранив их названия и все ссылки. Это предлагаемая задача, а не отчёт об уже выполненном переходе. У неё небольшой результат и несколько способов ошибиться: затронуть текст, потерять ссылку или перезаписать исходный материал вместо нового файла.
Сначала я дал бы кандидату прочитать разрешённую часть проекта и назвать применимые правила. Потом попросил бы план нужной правки. Только после сверки области действия перешёл бы к изменению и имеющейся проверке. Важен момент, когда недостающее правило обнаруживается: до записи результата исправлять непонимание дешевле.
Подготовить такой контракт можно и в чате LibraChat. Например, предложенным запросом: «Раздели описание моего учебного проекта на постоянные правила, цель одной правки и признаки её приёмки. Не придумывай команды и имена файлов, если я их не дал». Здесь я предлагаю текст обращения, не выдавая его за полученный ответ.
После пилота я записал бы три результата отдельно: правила обнаружены; изменение соответствует задаче; проверка действительно выполнена. Если один пункт не подтверждён, он остаётся открытым. Для содержательного разбора самого изменения пригодится материал об анализе кода с нейросетью. Выбор агента не завершает ревью будущего кода.
Codex я включаю в короткий список за документированный терминальный процесс и маршрут импорта из Claude Code. Gemini CLI — за работу инструментами и настраиваемый контекст. Какой вариант подойдёт, решит сохранение нужной работы в твоём проекте. Даже одинаковый `AGENTS.md` в двух сессиях не доказывает одинакового процесса. Для выбора полезнее найти первое необходимое правило или действие, которое после перехода пока не подтверждено.
Сегодня попробуй заполнить первую строку карточки для своего проекта: где записано правило, которое тебе важнее всего сохранить, и как новый агент сможет подтвердить, что прочитал его. Это уже конкретное начало сравнения.
Claude CodeCodexGemini CLIинструкциипрограммированиевыбор агента
