Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 38
Харнес клауд код работает с другими моделями. Если настолько важна была тула, то можно было и не менять
Да, Claude Code можно использовать с другими моделями через API-шлюзы. Но здесь есть ещё вопрос стоимости: работа через API обычно тарифицируется по токенам, иногда с комиссией посредника, тогда как нативный Codex можно использовать в рамках подписки ChatGPT с её лимитами.
Но основная задача была даже не в замене модели или сохранении самого Claude Code, а в том, чтобы отвязать накопленную историю проектов от конкретного агента. Сегодня работаю в Codex, завтра могу вернуться к Claude Code или перейти на другой инструмент, не теряя доступ к прежним обсуждениям. Hansard как раз позволяет это сделать.
Мне на днях тоже заблочили, я еще kimi попробовал)) в целом норм cli у них и без впн))
Да, Kimi Code тоже интересный вариант. Я его пока только присматриваю. А блокировка у вас тоже после проверки личности произошла или по другой причине?
Да по итогу после проверки) Может быть из за попыток сделать стенд для воспроизведения ошибок по пхп, или из за мигания впн из РФ. Потому, что блочат паспорта разных стран)) Видимо перед IPO что-то там шерстят
Понятно, значит, у нас похожая история — у меня тоже блокировка произошла после проверки личности. Причём конкретную причину так и не объяснили, сослались только на нарушение условий использования. Что именно послужило причиной, остаётся гадать. Что хочешь, даже если смена места жительства в США гражданином США привела к бану человека. Наверняка читал где-то? Что уж говорить про нас.
В любом случае ситуация лишний раз показывает, почему лучше не завязывать всю работу на одного провайдера.
Многие модели можно запускать в рамках подписки через claude code (и другие TUIшные обвзяки), это антропики только в этом плане жоско гайки крутят
Можно подключить свою подписку codex'а, а не использовать API.
openai присылали сообщение что с 1 декабря отдельного лимита для чата не будет
За 5 минут и 1 промпт агент пишет powershell скрипт конвертации диалогов.
Сегодня работаю в Codex, завтра могу вернуться к Claude Code или перейти на другой инструмент, не теряя доступ к прежним обсуждениям.
Здесь не все так просто. Пишу свою обвязку и пришлось вникать в нюансы протоколов. Например, Antropic при рассогласовании кеша инвалидирует всю историю рассуждений модели, без которой страдает качество. Рассогласование неизбежно будет при таком переносе истории.
Согласен, с полноценным переносом состояния сессии всё гораздо сложнее, особенно если учитывать thinking blocks, tool calls и особенности кэширования у разных провайдеров.
Но у меня задача немного другая. Мне не нужно продолжить внутреннюю цепочку рассуждений Claude в Codex один в один. Важно сохранить историю обсуждений, принятые решения и возможность найти нужный контекст в старых сессиях.
PowerShell-скрипт может конвертировать формат диалогов, но не решает полностью задачу поиска по истории нескольких агентов и её дальнейшего пополнения.
Кстати, интересно, как вы у себя решаете вопрос переноса состояния между разными моделями? Именно эту часть я пока глубоко не исследовал.
Я переносил историю из Zed. Просто сказал агенту: на этой машине установлен IDE Zed, нужно найти где он хранит диалоги, и экспортировать в MD диалог с названием <name>. Он нашел, написал скрипт и экпортировал в MD, который потом был просто прочитан и изучен в другой обвязке другим агентом. При том, что Zed хранит историю в SQLite БД файлах, в извращеннной форме, все равно было без проблем экспортировано.
А если codex забанят, то куда потом переходить? Есть идеи?
Пробовал Кими, но чёт по сравнению с кодексом прям сильно хуже...
скилы, KB, доки в проекте и работаешь с любым агентом.. К чему это всё?
Скилы, KB и документацию никто не отменяет. И в идеале все важные решения должны быть в проекте.
Но на практике в диалогах остаётся много того, что туда не попало: почему отказались от определённой архитектуры, какие варианты уже пробовали, на чём остановились перед перерывом.
Hansard для меня не замена документации, а возможность найти эти обсуждения, причём независимо от того, с каким агентом они велись.
Искать по диалогам - странное решение. Тем более если вы например работаете с нескольких устройств, или же над проектом работают несколько человек. Все что надо потом найти должно фиксироваться в доках. Обычно если для каждой задачи пишется план, и эти планы заливаются в гит вместе с кодом - этого достаточно чтобы найти что-то
Для командной работы согласен: документация, планы и решения должны храниться в Git, а не только в диалогах с агентом.
Но у меня задача была немного другая — сохранить уже накопленную историю работы над несколькими проектами. Далеко не все обсуждения, промежуточные решения и причины отказа от альтернатив попадали в документацию.
Есть и другой момент: при смене агента необязательно сразу заставлять его перечитывать весь массив документации и историю проекта. Можно сначала восстановить выжимку предыдущих обсуждений — что решили, что уже пробовали, на чём остановились — и затем сверить её с актуальными файлами и Git.
Поэтому для меня это не замена документации, а дополнительный слой памяти, который помогает быстрее вводить нового агента в контекст проекта.
Еще сейчас модно openspec или схожие методологии
Да, OpenSpec интересная тема, надо будет подробнее посмотреть. Но здесь, на мой взгляд, подходы скорее дополняют друг друга.
OpenSpec помогает структурировать дальнейшую работу и фиксировать решения в проекте, а поиск по истории позволяет восстановить то, что раньше не было задокументировано. В том числе причины отказа от определённых решений.
В идеале можно сначала восстановить контекст старых обсуждений, а затем уже оформить актуальные договорённости в спецификации.
Задача "прочитай всю документацию и историю проекта" одинакого глупа как для агента, так и для человека. Относитесь к агенту как к человеку, как бы глупо это не звучало, и думайте именно в этом контексте, как бы вы онбордили нового человека. И окажется, что история переписки в этом процессе вредит, а не помогает. Это задача разработчика понимать, в какой момент пора очередную выжимку работы закинуть в доки и KB иди полапдейтить скил новым тулингом. Если он этого не делает - значит пора поработать над левел ап.
С диалогах остаётся на много более мусора, который загрязняет контекст. И сильно загрязняет. А наша работа сейчас - это именно управление контекстом и этот процесс рандомным быть не должен.
Согласен, загружать всю историю диалогов в контекст было бы плохой идеей. Но хранить архив и загружать его целиком — разные вещи. Речь о возможности выборочно найти старое обсуждение, когда оно действительно понадобится.
Основная задача у меня была сохранить накопленную историю после вынужденной смены агента, а не заменить документацию переписками. Насколько качественно Recall извлекает нужную информацию — это уже отдельный вопрос, который ещё предстоит проверить на практике.
И как по ощущениям codex после claude в плане работы моделей?
Пока рано делать выводы. С более ранними версиями Codex уже работал, потом перешёл на Claude Code — на тот момент он мне больше подходил.
Сейчас модели и инструменты уже другие, поэтому старое сравнение не очень показательно. Пока осваиваюсь и переношу рабочие процессы. Коллеги, например, давно перешли на Codex и вполне довольны.
Думаю, многое зависит от конкретных задач и сложности проекта. Когда накоплю сопоставимый опыт, можно будет предметно сравнить.
Астра сильна, очень сильна. Но сейчас безбожно выедает лимиты. Как клод в мае. Я тогда на chatgpt5.4 переключился и летом почти не вылезая на этой линейке проработал вплоть до астры. Уже вполне тянуло, сейчас так вообще хорошо "мыслит". Но у всех есть свои особенности "поведения" это даже словами сложно описать, надо походить по граблям и почитать, куда кого в какую дичь порой сносит. ESC друг человека. Очень сильно клод и кодекс работают именно в паре. Друг у друга в планах всегда находят косяки и часто серьёзные. Пробовал Спарк 1.3 и потом wonder от Меты, в принципе уже тож вполне юзабельно, по очущениям на уровне опуса 4.8.
Я бы тоже с удовольствием использовал Claude Code и Codex в связке, особенно для взаимной проверки архитектурных решений и планов. Но Anthropic после верификации заблокировала мне платную организацию, а конкретную причину так и не объяснила. Как и многим другим пострадавшим. Когда и решится ли вообще вопрос с доступом — неизвестно.
Поэтому пока осваиваю другие варианты. А идея использовать разные модели и агенты для независимой проверки решений мне близка.
У codex'а даже при подписке соотношение цена/качество моделей оказывается намного хуже,чем у Claude. Представляется, что дешевле и выгоднее вложиться в прохождение верификации и использовать наиболее оптимальный вариант из того что есть на рынке, чем придумывать очередные костыли. Имхо конечно.
По соотношению цены и качества спорить не буду — тут всё зависит от задач, модели и интенсивности использования. У меня пока недостаточно опыта с нынешним Codex для объективного сравнения.
А вот с верификацией ситуация другая. Я её проходил по официальной процедуре, после чего и получил блокировку платной организации. Конкретное нарушение не объяснили, возврат за подписку отклонили.
То есть дело не в нежелании проходить проверку или платить за Claude. Просто продолжать работу нужно сейчас, а гарантий восстановления доступа нет.
И перенос истории нужен не потому, что Codex обязательно лучше Claude, а чтобы в следующий раз не оказаться в такой же зависимости от одного инструмента.
С использованием такой памяти не возникают проблемы? Когда старый контекст наоборот путает агента? Не слишком ли много там шума? Я в процессе разработки все что важно для дальнейшей работы, решения, гипотезы, планы, промежуточные результаты фиксирую в отдельных файлах, такая кастомная память по задачам, вне гит, архивируются отдельно. Фиксируется в полуавтоматическом режиме, когда агент знает что к задаче привязана рабочая папка с планом, в процессе он либо сам ее корректирует при принятии решений либо просишь его отразить, сильно зависит от модели и под что она заточена. Результаты работы уже ложаться в гит, а рабочие папки остаются для истории как контекст, для смежных задач или каких то стратегических решений. А вот целиком диалоги архивировать как то страшновато, бывают участки рассуждений которые я бы точно не хотел пихать в память, потому что уверен что они приведут агента не туда. Хотя возможно это уже тоже как то решили, не углублялся сильно.
Интересный подход с отдельными рабочими папками по задачам. По сути, у вас тоже сохраняется история работы, только уже структурированная, без лишнего шума из диалогов.
Опасения вполне обоснованные. Если агент примет старую гипотезу или отвергнутое решение за актуальное, можно получить проблемы.
Но я и не предлагаю загружать всю историю в рабочий контекст. Для меня Hansard прежде всего поисковый архив: когда нужно вспомнить старое обсуждение, можно найти его, извлечь нужные сведения и сверить с текущим состоянием проекта.
Насколько хорошо он справляется с фильтрацией шума на больших объёмах истории, пока объективно не оценивал. Это ещё предстоит проверить.
А ваш вариант с полуавтоматическим обновлением рабочих материалов мне интересен. Получается, агент сам поддерживает актуальность контекста задачи по мере работы?
Да, в процессе диалога агент часто сам актуализирует план, решения, результаты, либо по моей команде. Можно вообще такое поведение в скилы зашить. Это удобно для продолжения в другом чате, агент читает файлы и знает с какого шага продолжать, какие вопросы остались и.т.д. особенно в длинных эпиках без этого сложно. Иногда использую отдельного агента, который только контролирует выполнение задачи, сам не выполняет, он только следит за планом, актуализирует его, пишет результаты, формирует брифы для агентов исполнителей на отдельные шаги, закрывает задачу. В рабочей папке остаётся результат работы кучи агентов, без диалогов и кучи неважного промежуточного мусора.
Давно модели прекрасно ориентируются. У меня самописная семантическая память агентов с MCP, прекрасно работает. Просто кидаю в чат, собери мне контекст по нашим обсуждениям такого-то вопроса и вперед.
А можно немного подробнее про реализацию? Интересно, откуда собираете историю — из файлов сессий разных агентов или сохраняете контекст непосредственно в процессе работы?
И как организован поиск: embeddings, векторная БД, гибридный поиск? Особенно интересно, как решаете проблему устаревших или противоречащих друг другу решений.
Если есть публичный репозиторий или описание архитектуры, с удовольствием посмотрю. Как раз изучаю разные подходы к переносимой памяти агентов.
Похожая история, поэтому я делаю SpecWithCode — бесплатное приложение для Mac/Windows/Linux: Codex, Claude Code и другие агенты в одном чате, и если один упирается в лимит, работа продолжается на другом с тем же планом и историей. Короткое демо (лимит в нём смоделирован): t.me/antonaipower/155. Буду рад фидбеку.
Интересный проект, спасибо за ссылку! Посмотрел SpecWithCode и SpecWeave. У вас акцент на организации совместной работы агентов и передаче текущей задачи между ними, а у меня в статье — на восстановлении уже накопленной истории после вынужденного перехода.
Подходы действительно разные и, похоже, могут дополнять друг друга.
Подскажите, а SpecWithCode умеет импортировать историю существующих сессий Claude Code и Codex, созданных ещё до установки приложения? Или общая история формируется только для работы, которая уже ведётся внутри SpecWithCode?
Для моего сценария это принципиальный момент. Особенно когда доступ к прежнему агенту уже потерян.
А есть какая-то инфа про этот Hansard, кто его делает вообще? Код видимо закрыт, т.к. на гитхабе ничего найти не смогла. Возможности конечно впечатляют, но не хочется вот так просто давать ноунейм софту доступ к таким чувствительным данным
Аналогично ничего не нашёл. Зато нашёл https://github.com/vshulcz/deja-vu. Готовы попробовать и написать статью на хабр для сравнения?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жизнь после Claude Code: как я переехал на Codex и сохранил историю проектов