Почему одна задача расходует 1%, а другая 10%

Пользователь видит один запрос:

Исправь ошибку в отчете.

Codex видит длинную траекторию:

• открыть проект;
• найти реализацию;
• прочитать связанные файлы;
• сформировать гипотезу;
• запустить приложение;
• воспроизвести ошибку;
• внести изменение;
• запустить тесты;
• получить новую ошибку;
• исправить еще раз;
• проверить diff;
• подготовить отчет.

Именно поэтому расходуется не текст сообщения, а весь путь работы.

Базовая модель расхода

Упрощенно:

Расход = входной контекст + reasoning + выход + инструменты + повторные итерации.

В подписке это преобразуется во внутренний allowance и проценты. Точный коэффициент OpenAI не раскрывает полностью.

Фактор 1. Выбранная модель

Sol имеет более высокий потолок качества, но в Codex обычно дает меньше включенных сообщений, чем Terra и Luna.

Это не означает, что Sol всегда дороже на принятую задачу. Если Terra дважды не справилась, суммарный расход может оказаться выше.

Рациональная логика:

• Luna - ясные и дешевые операции;
• Terra - типовая инженерная работа;
• Sol - сложность, неоднозначность и высокая цена ошибки.

Фактор 2. Reasoning effort

Чем выше reasoning, тем больше модель может потратить на:

• планирование;
• анализ альтернатив;
• проверку;
• поиск причин;
• работу с инструментами;
• собственные промежуточные циклы.

Но универсального коэффициента нет. High не равен фиксированным 2x Medium.

На простой задаче разница может быть небольшой. На сложном баге High способен развернуть длинное исследование.

Фактор 3. Размер контекста

В контекст входят:

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

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

Как снизить расход

• указывать релевантные модули;
• давать путь к существующей реализации;
• фиксировать protected areas;
• прикладывать воспроизводимый сценарий;
• не отправлять весь архив, если нужен один компонент.

Фактор 4. История сессии

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

Но длинная сессия накапливает:

• устаревшие гипотезы;
• большие логи;
• отмененные требования;
• многочисленные diff;
• противоречия.

Когда продолжать

• задача является прямым продолжением;
• контекст остается актуальным;
• модель должна помнить принятые ограничения;
• повторное исследование будет дорогим.

Когда начинать новую

• цель изменилась;
• предыдущая сессия застряла на неверной гипотезе;
• контекст переполнен логами;
• новая задача независима;
• нужна независимая проверка.

Фактор 5. Tool calls и терминал

Каждая команда создает новый результат, который модель должна прочитать и интерпретировать.

Особенно дороги:

• длинные build logs;
• полный вывод тестового набора;
• широкие grep/search;
• многократные запуски приложения;
• установка зависимостей;
• browser/computer use;
• большие diff.

Это не значит, что инструменты нужно запрещать. Без них результат может быть непроверенным. Нужно ограничивать шум.

Примеры:

• запускать сначала targeted test, затем полный suite;
• обрезать повторяющиеся логи;
• сохранять результаты в файл и читать нужный фрагмент;
• не запускать сборку после каждого косметического изменения.

Фактор 6. Повторные итерации

Нечеткая задача расходует лимит дважды:

1. агент делает правдоподобную, но неверную работу;
2. пользователь уточняет критерии;
3. агент исследует и меняет проект заново.

Поэтому хороший task package экономит больше, чем снижение reasoning на один уровень.

Минимальный пакет задачи:

• цель;
• текущая проблема;
• ожидаемое поведение;
• scope;
• out of scope;
• точки входа;
• критерии приемки;
• обязательные тесты;
• ограничения;
• формат отчета.

Фактор 7. Subagents и параллельная работа

Ultra и другие multi-agent режимы могут ускорить сложное исследование, но параллельно расходуют больше вычислительного ресурса.

Они оправданы, если задача реально делится:

• исследование нескольких независимых модулей;
• сравнение архитектур;
• параллельная проверка разных гипотез;
• большой code review.

Они не нужны для локальной правки одного файла.

Фактор 8. Cloud tasks

Cloud task может продолжать работать автономно и расходовать тот же пятичасовой pool, что локальные сообщения.

Пользователь иногда забывает о запущенной задаче и параллельно начинает новую. В результате проценты уменьшаются быстрее ожидаемого.

Рабочее правило:

Перед запуском тяжелой задачи проверить активные cloud tasks и текущий reset.

Фактор 9. Длина финального ответа

Output и reasoning часто стоят дороже входа в API-моделях. В подписочном allowance внутренняя формула не опубликована, но длинные отчеты также увеличивают общий объем работы.

Codex не нужно каждый раз просить писать подробный учебник.

Достаточный итог:

• что изменено;
• какие файлы;
• какие тесты запущены;
• результат;
• что не проверено;
• риски.

Когда делить задачу

Делить полезно, если части независимы и имеют собственные критерии приемки.

Например:

1. исследовать причину;
2. согласовать план;
3. реализовать;
4. независимо протестировать.

Не стоит делить связанную фичу на десять микрозадач, если каждый агент вынужден заново изучать тот же контекст.

Когда выбрать более дешевую модель

• задача повторяется;
• есть точная схема результата;
• ошибка легко обнаруживается;
• нет сложной архитектуры;
• context window ограничен;
• можно автоматически валидировать ответ.

Когда выбрать Sol сразу

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

Матрица относительной тяжести

Это качественная, а не точная процентная шкала.

Практический протокол экономии

1. Классифицировать задачу до запуска.
2. Выбрать минимально достаточную модель.
3. Начать с базового reasoning.
4. Дать точки входа и критерии приемки.
5. Ограничить scope.
6. Запускать targeted tests до полного suite.
7. Не дублировать активные cloud tasks.
8. После неудачи определить причину: модель, reasoning или постановка.
9. Повышать только один параметр за раз.
10. Считать стоимость принятого результата.

Plus, Pro или API

Plus подходит для нерегулярной и умеренной агентной работы.

Pro становится рациональным, если:

• Codex регулярно упирается в лимит;
• простой пользователя стоит дороже подписки;
• Work и Codex активно используют общий pool;
• задачи выполняются ежедневно.

API полезен, если:

• процесс массовый;
• нужен отдельный бюджет;
• требуется программная маршрутизация;
• использование нужно учитывать по клиентам;
• важны логи и SLA.

Что меняем после этой статьи

1. Не оцениваем задачу по длине запроса.
2. Учитываем всю агентную траекторию.
3. Перед запуском проверяем scope и активные cloud tasks.
4. Не используем High как страховку от плохой постановки.
5. Разделяем независимые этапы, но не дробим связанный контекст механически.
6. После неудачи повышаем один параметр, а не все сразу.

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

Навигация по серии

• Предыдущая статья: Почему Plus не безлимитный и что показывают проценты Codex
• Следующая статья: Как теперь ставить задачи GPT-5.6: меньше микроменеджмента, больше результата и границ
• Страница всей серии

FAQ

Почему одинаковые запросы расходуют разный процент?

Потому что учитывается не длина сообщения, а вся траектория: модель, reasoning, контекст, файлы, tools, тесты и повторные итерации.

Высокий reasoning всегда дороже?

Обычно он требует больше вычислений и времени, но точный учет зависит от продукта. Главное - оценивать стоимость принятого результата, а не одного запуска.

Как снизить расход?

Сузить scope, убрать лишний контекст, выбрать минимально достаточную модель и effort, не дублировать параллельные задачи и завершать run по ясным критериям.

Источники и границы выводов

Материал подготовлен по состоянию на 10 июля 2026 года. Функции, доступность и лимиты OpenAI могут меняться. Перед операционным решением стоит проверять актуальную документацию.

• GPT-5.6: Frontier intelligence that scales with your ambition
• GPT-5.6 in ChatGPT
• OpenAI model guidance
• OpenAI prompt guidance
• Reasoning models
• Codex models
• Codex rate card
• Projects in ChatGPT
• Deep research in ChatGPT
• Scheduled Tasks in ChatGPT

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