[Перевод] Как использовать GPT-5.6 Sol в Codex и не сжечь лимит

Эта статья является переводом оригинальной How to use gpt-5.6-sol without hitting limits от Theo.

Theo использует GPT-5.6 Sol почти постоянно и говорит, что уже потратил на него больше 200 тысяч долларов в токенах. Модель ему нравится, но на тарифе Codex Pro за 200 долларов слишком легко выбрать режим, который съест лимит на несколько часов вперед.

OpenAI довольно часто сбрасывает ограничения, но это не спасает, если пятиточасовое окно заканчивается тогда, когда до его обновления еще четыре часа. Ниже — его практические рекомендации о том, как получать от Sol больше результата и тратить меньше токенов.

Если вам интересно читать про AI Coding ещё больше от практика, то рекомендую подписаться на мой телеграм канал «Тимур Хахалев про AI Coding»

1. Начните с Medium или High

Для большинства задач Theo советует использовать Medium или High. Оба уровня дают хороший результат. XHigh заметно мощнее, но на практике он редко оказывается необходим — даже когда Codex координирует несколько subagents.

Более высокий уровень reasoning не всегда означает лучший результат на единицу потраченного лимита. Сначала стоит найти самый легкий режим, который стабильно справляется с вашим типом задач, и только потом повышать его для сложных случаев.

2. Пока не используйте Ultra

Ultra — это не отдельный уровень reasoning, хотя в интерфейсе он выглядит именно так. По наблюдениям Theo, в текущей реализации Codex есть ошибки: режим может запускать слишком много subagents и передавать им слишком высокий уровень reasoning.

Из-за этого одна задача начинает расходовать лимит гораздо быстрее, чем ожидаешь. Пока поведение не исправят, рекомендация простая: не использовать Ultra в рабочих задачах, где важен предсказуемый расход.

3. Осторожнее с быстрым режимом

Быстрый режим полезен, когда модель обычно долго думает перед началом работы. Но за скорость приходится платить: такой запуск расходует примерно в 2,5 раза больше лимита.

GPT-5.5 часто останавливалась и ждала дополнительного толчка. GPT-5.6, наоборот, способна продолжать работу гораздо дольше и доводить задачу до конца без напоминаний. Это удобно, но расход становится менее предсказуемым.

По оценке Theo, обычный запрос в GPT-5.5 мог занимать от 0,1% до 2% доступного лимита. В быстром режиме пиковый расход доходил примерно до 5%. У GPT-5.6 один особенно длинный запрос может съесть до 15%, а в сочетании с ускоренным режимом — около 40% пятиточасового окна.

Поэтому для повседневной работы он советует временно отказаться от быстрого режима.

4. Контролируйте subagents

Subagents — одна из самых сильных возможностей GPT-5.6 Sol. Модель охотно делегирует части задачи, и обычно это помогает. Проблема в том, что текущая реализация Codex может быть слишком щедрой на такие запуски.

Коротко это работает так: Sol запускает subagent с тем же уровнем reasoning и той же моделью, что и родительский процесс. Поэтому Ultra особенно быстро разрастается в цепочку дорогих запусков.

Что можно сделать:

• снизить уровень reasoning; High обычно остается приемлемым, а Low и Medium сильнее ограничивают расход;

• добавить в глобальный AGENTS.md правило: запускать subagents только по явному запросу;

• если нужны многоуровневые делегирования, отдельно разобраться с настройкой hide_spawn_agent_metadata = false в конфигурации Codex.

Последний вариант требует понимания того, как именно Codex создает subagents, поэтому для большинства задач достаточно первых двух.

5. Выбирайте модель под задачу

Сам Theo большую часть времени продолжает использовать gpt-5.6-sol. Иногда он берет Terra для быстрого просмотра или обратной связи. Luna ему тоже нравится, но она воспринимается скорее как служебный инструмент для кода и генерации subagents, а не как модель, которую пользователь вручную выбирает для каждой задачи.

Его практическая рекомендация для тарифа за 200 долларов:

• Sol High — основной рабочий режим;

• Sol Low — если нужно максимально растянуть лимит;

• Terra Medium — потенциально хороший вариант для большого объема задач, но этот вывод еще требует дополнительной проверки.

6. Заранее задавайте точку остановки

GPT-5.6 может долго работать и делать это качественно. Но иногда она продолжает задачу уже после того, как полезный результат фактически получен. Явная точка остановки помогает и качеству процесса, и расходу токенов.

Например, вместо общего «реализуй эту функцию» можно написать:

Сначала составь план. После завершения плана остановись и дождись моего фидбэка.

А после ревью продолжить:

Теперь реализуй план. Протестируй результат через computer use и продолжай, пока код не заработает. Создай PR и обработай первый раунд ревью. После этого остановись.

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

7. Иногда полезно поручить управление другому агенту

Если у вас есть доступ к другому агенту или инструменту, можно сделать его «драйвером» для Codex. Theo описывает схему, в которой Fable управляет GPT-5.6 и умеет правильно запускать для нее subagents. Cursor уже знает похожие паттерны.

Идея не в том, чтобы всегда добавлять еще один слой автоматизации. Такой подход имеет смысл, когда управляющий агент умеет выбирать более дешевый уровень reasoning, распределять работу и останавливать процесс в нужный момент.

8. Экспериментируйте маленькими изменениями

Сейчас полезно не искать одну идеальную конфигурацию, а наблюдать за тем, как небольшие изменения влияют на результат и расход лимита.

Можно менять модель, уровень reasoning, наличие subagents и формулировку stop points, а затем смотреть статистику через dashboard, ccusage, CodexBar или другой удобный инструмент. Разница между двумя почти одинаковыми запросами иногда оказывается неожиданно большой.

Имеет смысл экспериментировать и с настройками в ~/.codex и ~/.claude, но делать это осознанно: фиксировать изменение, проверять результат и возвращать конфигурацию, если поведение стало хуже.

Главное

GPT-5.6 Sol хорошо подходит для длинных автономных задач, но именно эта сила делает расход лимита менее предсказуемым. Базовая стратегия Theo выглядит так: использовать Sol High без Ultra и Fast mode, не разрешать модели бесконтрольно порождать subagents, явно задавать точки остановки и следить за фактическим расходом.

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