OpenAI Codex на двух устройствах: как синхронизировать сессии без боли

[R_Sanych]

А как решить проблему что Code Claude очень долго думает, сессия длинная была. Раньше за секунду ответ давал, теперь приходится ждать по 3-5 минут, что очень неудобно. Vpn включен, тариф оплачен. Посоветуйте!

[krox]

Похоже, это скорее про сам Codex, не про синхронизацию.

Уточните, пожалуйста, какие модели используете?
Если с сильным рассуждением (reasoning), то они действительно могут отвечать заметно дольше, особенно на длинных сессиях.

Из наблюдений:

• чем длиннее диалог, тем сильнее может расти время ответа

• иногда помогает начать новую сессию и перенести краткий контекст

У вас примерно какой объём сессии сейчас?

Я сам с таким сильным замедлением пока не сталкивался, поэтому интересно понять, в каких условиях это проявляется. Если вдруг найдёте обсуждения или решение (например, на Reddit или профильных чатах) — будет полезно, если поделитесь здесь.

[R_Sanych]

Model Sonet 4.6. Объем сессии не знаю как посмотреть, но по времени недели две по несколько часов в день)

[krox]

Похоже, вы сейчас не про Codex.

Sonnet 4.6 — это модель от Anthropic (Claude), а не из экосистемы OpenAI Codex. У них модели ChatGPT разных версий и ChatGPT-codex

Но поведение, которое вы описываете, в целом похоже: при очень длинных сессиях (особенно если там много контекста/кода) ответы могут заметно замедляться.

В таком случае обычно помогает:

• начать новую сессию

• перенести краткий контекст вручную

«Две недели по несколько часов в день» — это как раз тот случай, где контекст уже может быть очень большим.

Если разберётесь, от чего именно зависит задержка — будет интересно узнать

[R_Sanych]

Так тогда и сделаю, начну новую сессию с краткой историей старой сессии, надеюсь мысль модель не потеряет) Спасибо!

[krox]

В старой сессии попроси выжимку в md файл сделать.

[SlavaVSLK]

Если самый простой вариант:

Создаёте файл типа my-work-journal.md к примеру после каждого действия (исполнения промпта) пусть пишет туда короткую выжимку чего поменял с timestamp к примеру, и второй файл например my-work-backlog.md перед тем как начать новую сессию пусть пишет туда на чем остановились и что планируете делать дальше (кратко или подробно, тут уже по ситуации). Ну и собственно должен быть хотя бы основной файл с ТЗ или что у вас там есть (то над чем работаете). В новой сессии пихаете ему файл ТЗ, просите прочитать конец журнала изменений (можно в журнал писать только последние изменения, если вам не нужна вся история попыток, удач/не удач и так далее) и backlog что бы не рассказывать чего вы там собирались делать. Это примитивный вариант, но работает, когда у вас объёмная работа, которая не помещается в одно контекстное окно. Лучше конечно изначально большую задачу пилить на селкие составляющие

[SlavaVSLK]

А, ну и что бы весь этот входной контекст меньше ел токенов, просите писать его на английском

[R_Sanych]

Коды по тысячи строк доходят)

[past]

Тут вижу проблему XY.

Старайтесь не работать длинными сессиями. Делить эрпики на задачки, задачки на подзадачки. Пока они не будут у Вас укладываться в 1 копоткоживущую сессию. Всё ± как в классической разработке. Кроме того длинная сессия - замусоренных контент. Лучше по окончании задачки заставляйте кодекс обновлять марудауны с контекстом. Если всё же никак не можете обходиться без длинных сессий, просто кладите их в гит вместе с проектом.

[krox]

Да, согласен, это в целом хороший подход — разбивать задачи и не раздувать сессии.

Я как раз пришёл к похожему выводу: длинные диалоги быстро начинают «засоряться» и хуже работают.

В моём случае проблема была чуть в другом — хотелось сохранять и переносить уже накопленный контекст между устройствами, а не терять его при переключении.

Поэтому и появился инструмент для синхронизации.

Но как альтернатива — да, короткие сессии + явное сохранение контекста (в markdown или git) выглядит хорошей стратегией. При этом это скорее дополняет подход, чем заменяет — в моём случае как раз хотелось сохранить и переносить накопленный контекст между устройствами без ручных действий.