Не путайте размер модели с глубиной размышления

title: "Не путайте размер модели с глубиной размышления: когда Luna Max может догнать Terra Medium — и почему Sol Medium иногда рациональнее Terra X‑High" subtitle: "Практическая экономика GPT‑5.6: качество, reasoning-токены, задержка, маршрутизация моделей и multi-agent" language: "ru" date: "2026-07-10" keywords:

• GPT-5.6
• OpenAI
• Luna
• Terra
• Sol
• reasoning effort
• X-High
• Max
• Ultra
• reasoning tokens
• стоимость токенов
• model routing
• Codex
• multi-agent
• subagents
• evals
• latency

Когда Luna Max может догнать Terra Medium — и почему Sol Medium иногда рациональнее Terra X‑High

Дата актуальности: 10 июля 2026 года.

> Главная мысль: более слабая модель с высоким reasoning effort действительно может иногда сравняться с более сильной моделью на Medium. Но «может сравняться» и «является лучшим выбором» — разные утверждения. Высокий effort способен резко увеличить число reasoning-токенов, задержку и стоимость. Поэтому сравнивать нужно не названия режимов, а стоимость принятого результата при заданных требованиях к качеству и времени.

Все внешние факты, цены и результаты бенчмарков в статье снабжены источниками. Формулы и сравнительные расчёты помечены как авторские вычисления на основе официальных тарифов и опубликованных данных. Рекомендации — это инженерные выводы, а не дословная позиция OpenAI.

Короткий вывод

Да, Luna Max может перекрыть Terra Medium на конкретном типе задач. В GeneBench‑Pro Luna Max получила номинально более высокий pass rate, чем Terra Medium: 16,5% против 13,6%. Но для этого Luna Max использовала в среднем 118,2 тыс. trace/response-токенов против 15,9 тыс. у Terra Medium. При действующих API-тарифах только выходная часть такого запуска стоила бы примерно $0,709 против $0,239 — почти втрое дороже.[^genebench][^models]

Да, Terra X‑High может быть альтернативой Sol Medium на отдельных задачах. Но в том же GeneBench‑Pro результат был обратным: Sol Medium показала 22,5% против 18,8% у Terra X‑High, использовала 14,4 тыс. токенов против 31,1 тыс. и имела немного меньшую расчётную стоимость выходной части — $0,432 против $0,467.[^genebench][^models]

Следовательно, высокий effort на более дешёвой модели — не бесплатное «повышение класса». Иногда он закрывает разрыв в качестве. Иногда не закрывает. Иногда закрывает, но делает запрос дороже и медленнее, чем более сильная модель на меньшем effort. OpenAI поэтому рекомендует использовать минимальный reasoning effort, который стабильно даёт нужный результат, а max оставлять для самых сложных quality-first сценариев и обязательно сравнивать с xhigh на репрезентативных задачах.[^guidance][^codex-models]

1. В GPT‑5.6 есть две независимые ручки управления

В семействе GPT‑5.6 пользователь выбирает как минимум две вещи:

1. уровень модели: Luna, Terra или Sol;
2. глубину рассуждения: none, low, medium, high, xhigh или max.

OpenAI позиционирует Luna как модель для экономичных, массовых и чётко определённых задач; Terra — как сбалансированного универсального исполнителя; Sol — как флагман для сложной профессиональной работы, неоднозначных задач, глубокого анализа и кода.[^models][^codex-models]

Источник таблицы: официальная страница моделей OpenAI и руководство Codex.[^models][^codex-models]

Важно: reasoning effort не является другой моделью. Это ограничитель того, сколько рассуждения выбранная модель может применить к задаче. OpenAI пишет, что повышение effort обычно увеличивает время ответа и расход reasoning-токенов, хотя на сложных задачах способно повысить качество.[^reasoning][^subagents]

Удобная инженерная интерпретация выглядит так:

• уровень модели задаёт базовый диапазон способностей, цены и скорости;
• effort определяет, насколько глубоко модель будет исследовать задачу внутри этого диапазона.

Это не официальное описание внутренней архитектуры и не утверждение о числе параметров. Это практическая модель выбора, прямо следующая из того, что OpenAI отдельно предлагает выбирать модель под workload и отдельно настраивать reasoning effort.[^guidance]

2. Почему Luna вообще получила X‑High и Max

На первый взгляд логика кажется странной: если Luna предназначена для массовых и понятных задач, зачем давать ей xhigh и max? Почему просто не перейти на Terra?

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

Высокий effort может быть полезен, когда задача остаётся узкой и хорошо формализованной, но требует больше проверок, перебора вариантов или аккуратного выполнения длинной последовательности шагов. Например, структура ответа, критерии успеха и допустимые действия могут быть заранее известны, а сложность заключается не в неоднозначном понимании мира, а в необходимости не пропустить исключение или проверить множество условий. OpenAI прямо рекомендует Luna для extraction, classification, transformation и structured summaries, а effort повышать, когда задаче требуется больше planning, analysis или checking.[^codex-models]

Кроме того, Luna в 2,5 раза дешевле Terra за каждый входной и выходной токен. Поэтому Luna может потратить заметно больше токенов и всё ещё остаться дешевле — если рост расхода не пересечёт точку безубыточности.[^models]

Но наличие режима не означает, что его следует использовать по умолчанию. В документации Codex сказано, что Max даёт выбранной модели больше времени на одну задачу, предназначен для наиболее трудных проблем и что большинству задач не нужны ни Max, ни Ultra. В API-руководстве OpenAI также советует резервировать max для самых сложных quality-first workload и сравнивать его с xhigh на собственных evals.[^codex-models][^guidance]

Иными словами, Luna Max существует не потому, что она должна универсально заменить Terra, а потому, что бывают узкие задачи, где дополнительное рассуждение на дешёвой модели выгоднее смены модели. Но это гипотеза, которую нужно подтверждать измерениями.

3. X‑High не превращает Luna в Terra, а Max не превращает Terra в Sol

Распространённая ошибка — читать шкалу как единую лестницу:

> Luna Medium → Luna High → Luna X‑High → Terra Medium → Terra High → Sol Medium.

Официальная документация такой лестницы не определяет. Более того, OpenAI отдельно предупреждает, что точного соответствия reasoning-уровней даже между поколениями моделей нет, и рекомендует тестировать знакомую задачу на нескольких настройках.[^codex-models]

Почему прямого пересчёта нет:

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

Последние четыре пункта — инженерная интерпретация поведения, а не раскрытие внутреннего устройства моделей. Её нужно проверять на конкретном workload через evals; OpenAI также рекомендует использовать реальные репрезентативные входы и не предполагать, что максимальный effort автоматически даёт лучший компромисс.[^evals][^optimization][^guidance]

Поэтому корректная формулировка звучит так:

> Более слабая модель на высоком effort может пересечься по качеству с более сильной моделью на низком или среднем effort на определённом распределении задач. Но это пересечение не создаёт универсальной эквивалентности.

4. Реальная стоимость: reasoning-токены оплачиваются как output

Для упрощённого сравнения API-запроса без кеша и платных инструментов используем:

\[ C_m = p_{in,m}\cdot I + p_{out,m}\cdot G_m, \]

где:

• \(C_m\) — стоимость запроса на модели \(m\);
• \(I\) — входные токены;
• \(G_m\) — все сгенерированные токены модели, включая видимый ответ и скрытые reasoning-токены;
• \(p_{in,m}\) и \(p_{out,m}\) — тарифы модели на вход и выход.

Reasoning-токены не показываются как обычный текст, но учитываются в контекстном окне, отражаются в usage-объекте и тарифицируются как выходные токены.[^reasoning]

Для GPT‑5.6 действуют следующие ставки:[^models]

\[ C_{\text{Luna}} = 1I + 6G_L, \]

\[ C_{\text{Terra}} = 2.5I + 15G_T, \]

\[ C_{\text{Sol}} = 5I + 30G_S, \]

если \(I\) и \(G\) выражены в миллионах токенов, а стоимость — в долларах США.

Luna против Terra

Luna дешевле Terra при одинаковом входе, если:

\[ 1I + 6G_L < 2.5I + 15G_T, \]

то есть:

\[ G_L < 2.5G_T + 0.25I. \]

Для output-heavy задачи с небольшим входом это означает: Luna может использовать примерно до 2,5 раза больше generated-токенов, чем Terra, и всё ещё оставаться дешевле. Если Luna начинает использовать в три, пять или семь раз больше токенов, ценовое преимущество может исчезнуть.

Terra против Sol

Terra дешевле Sol при одинаковом входе, если:

\[ 2.5I + 15G_T < 5I + 30G_S, \]

то есть:

\[ G_T < 2G_S + \frac{I}{6}. \]

Для output-heavy задачи Sol может стать дешевле Terra, если Sol решает её менее чем примерно за половину generated-токенов Terra.

Luna против Sol

Luna дешевле Sol при одинаковом входе, если:

\[ G_L < 5G_S + \frac{2I}{3}. \]

Поэтому Luna имеет большой ценовой запас против Sol. Но этот запас ничего не говорит о качестве ответа, числе повторных запусков и стоимости ошибки.

Все три неравенства — авторский вывод из официальных тарифов.[^models]

5. API-доллары и Codex-кредиты дают одну и ту же пропорцию

В актуальной токеновой системе Codex ставки на 1 млн токенов составляют:

Таким образом, отношение цен Sol : Terra : Luna одинаково для входа и выхода — 5 : 2,5 : 1, как и в API-долларах. Следовательно, приведённые точки безубыточности применимы и к токеновым кредитам Codex после умножения на общий коэффициент.[^codex-pricing]

Это не следует автоматически переносить на любой интерфейс ChatGPT: конкретный план может считать сообщения, лимиты или кредиты по собственной rate card. Для финансового расчёта нужно использовать тарификацию того продукта, в котором выполняется задача.[^chatgpt-rate]

6. Что ещё входит в стоимость, кроме модели

Упрощённая формула полезна, но реальный production-запрос может включать дополнительные компоненты:

• cached input;
• запись нового prompt cache;
• web search, file search, контейнеры и другие платные инструменты;
• повторные запросы после ошибок;
• параллельных subagents;
• человеческую проверку и исправления.

В GPT‑5.6 reasoning-токены входят в output billing. Токены, поступающие через встроенные инструменты, также тарифицируются по ставкам выбранной модели, а сами инструменты могут иметь отдельную цену.[^reasoning][^pricing]

Prompt caching меняет экономику длинных повторяющихся промптов: чтение кеша получает 90%-ную скидку относительно обычного input, а запись кеша для GPT‑5.6 тарифицируется в 1,25 раза от обычного input. Поэтому для систем с большим стабильным префиксом входная часть может стать существенно дешевле, чем в простом расчёте.[^caching]

Для запросов с входом свыше 272K токенов страницы моделей GPT‑5.6 указывают повышенную ставку для всего запроса: 2× за input и 1,5× за output. Это меняет абсолютную стоимость и вес входа в точке безубыточности.[^long-context]

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

\[ \text{Cost per accepted result} = \frac{\text{все токены + инструменты + повторные запуски + проверка}} {\text{число принятых результатов}}. \]

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

7. Почему «думает дольше» обычно означает «медленнее», но не даёт точного таймера

Reasoning effort — не фиксированное количество секунд. Он задаёт глубину рассуждения, но реальное число reasoning-токенов зависит от задачи. OpenAI указывает, что модели могут использовать от сотен до десятков тысяч reasoning-токенов, а более высокий effort обычно повышает время ответа и token usage.[^reasoning][^subagents]

Задержка в текстовой генерации в основном зависит от выбранной модели и числа генерируемых токенов; значительная часть latency возникает именно на этапе генерации. Поэтому конфигурация, которая производит в пять раз больше reasoning/output-токенов, обычно получает серьёзный штраф по времени, хотя точное отношение не обязано быть линейным.[^latency]

Отсюда важный вывод:

> Более дешёвая цена за токен не гарантирует меньшую стоимость и не гарантирует меньшую задержку.

Она лишь даёт модели запас, который может быть потрачен на более длинное рассуждение.

8. Показательный эксперимент: GeneBench‑Pro

GeneBench‑Pro — специализированный бенчмарк из 129 сложных задач по многоэтапному статистическому рассуждению в генетике, геномике и смежной биологии. Он не является универсальным тестом кода, документов или бизнес-аналитики, поэтому его нельзя превращать в абсолютный рейтинг моделей. Но он особенно полезен для нашей темы, потому что публикует результаты разных reasoning settings и среднее количество токенов.[^genebench]

В таблице ниже:

• pass rate взят из Supplementary Table 1;
• токены — средний объём полного model trace и финального ответа;
• tool calls в это число не входят;
• «output cost» — авторский расчёт по официальной цене output-токенов;
• input и tool fees не включены.[^genebench][^models]

Ограничение интерпретации

В опубликованных результатах есть доверительные интервалы. Например, Luna Max имеет 16,5% с 95%-ным интервалом 11,6–21,7%, а Terra High — 16,2% с интервалом 11,6–21,2%. Эти диапазоны практически совпадают, поэтому корректно говорить о сопоставимом номинальном результате, а не о доказанном превосходстве Luna Max.[^genebench]

9. Luna X‑High против Terra Medium: высокий effort не закрыл разрыв

В GeneBench‑Pro:

• Luna X‑High: 10,8%, 53,1K токенов, около $0,3186 за output;
• Terra Medium: 13,6%, 15,9K токенов, около $0,2385 за output.

Luna X‑High использовала в 3,34 раза больше trace/response-токенов, получила более низкий результат и имела примерно на 34% более дорогую выходную часть. Это конкретный пример, где попытка «докрутить» слабую модель не только не достигла качества следующего уровня, но и потеряла ценовое преимущество на output.[^genebench][^models]

Однако общий total cost всё ещё зависит от входа. Поскольку Luna экономит $1,50 на каждом миллионе input-токенов относительно Terra, при одинаковом некешированном входе около 53,4K токенов входная экономия компенсировала бы разницу в output cost. Это авторский расчёт по стандартным тарифам. Качество Luna X‑High в данном бенчмарке при этом всё равно оставалось ниже.[^models]

Вывод: Luna X‑High нельзя считать автоматической заменой Terra Medium. Для коротких и средних входов Terra Medium здесь выглядит рациональнее; для очень длинных входов Luna может вернуть ценовое преимущество, но не обязательно качество.

10. Luna Max против Terra Medium и Terra High: догнать можно, но цена может стать нелепой

В том же тесте:

• Luna Max: 16,5%, 118,2K токенов, $0,7092 output;
• Terra Medium: 13,6%, 15,9K токенов, $0,2385 output;
• Terra High: 16,2%, 22,2K токенов, $0,3330 output.

Luna Max номинально обошла Terra Medium и практически сравнялась с Terra High. Но она использовала:

• в 7,43 раза больше токенов, чем Terra Medium;
• в 5,32 раза больше токенов, чем Terra High;
• примерно в 2,97 раза более дорогой output, чем Terra Medium;
• примерно в 2,13 раза более дорогой output, чем Terra High.

Все отношения — авторские вычисления из опубликованных средних токенов и официальных тарифов.[^genebench][^models]

При одинаковом стандартно тарифицируемом input Luna Max стала бы дешевле Terra High только примерно после 250,8K одинаковых входных токенов. Это уже очень длинный контекст, рядом с порогом повышенной long-context тарификации в 272K.[^models][^long-context]

Именно здесь видно различие между двумя вопросами:

• может ли Luna Max достичь качества Terra? Иногда да;
• разумно ли использовать Luna Max вместо Terra? Нередко нет.

Для output-heavy задач это особенно слабая сделка. Luna Max может быть оправдана, если вход очень велик, задача строго ограничена, переключение модели нежелательно и собственные evals показывают реальный выигрыш. Без этих условий Terra Medium или High обычно заслуживает обязательного сравнительного запуска.

11. Sol Low против Terra Medium: более сильная модель иногда выигрывает даже на меньшем effort

GeneBench‑Pro даёт и обратный пример:

• Sol Low: 14,4%, 5,6K токенов, $0,168 output;
• Terra Medium: 13,6%, 15,9K токенов, $0,2385 output.

Sol Low показала немного более высокий номинальный результат, использовала примерно на 65% меньше токенов и имела примерно на 30% меньшую стоимость выходной части.[^genebench][^models]

Но Sol дороже на input. При одинаковом некешированном входе Terra Medium возвращает преимущество по общей цене, когда общий вход превышает примерно 28,2K токенов. Это авторский расчёт из официальных ставок.[^models]

Вывод не в том, что Sol Low всегда лучше Terra Medium. Вывод в другом:

> Сильная модель на низком effort может оказаться эффективнее слабой модели на среднем effort, потому что быстрее находит продуктивную траекторию рассуждения.

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

12. Terra X‑High против Sol Medium: центральное сравнение для сложной работы

Это одна из самых полезных пар для практического A/B-теста:

• Terra X‑High: 18,8%, 31,1K токенов, $0,4665 output;
• Sol Medium: 22,5%, 14,4K токенов, $0,4320 output.

В GeneBench‑Pro Sol Medium была номинально сильнее, использовала в 2,16 раза меньше токенов и имела примерно на 8% меньшую output cost.[^genebench][^models]

Но Terra имеет более дешёвый input. При одинаковом некешированном входе более примерно 13,8K токенов общая стоимость Terra X‑High уже могла бы стать ниже, несмотря на более дорогой output. Это ещё раз показывает, почему нельзя сравнивать только reasoning-токены или только цену модели.[^models]

Для реального workflow выбор зависит от профиля:

• короткий вход, сложное reasoning, дорогая ошибка — Sol Medium может быть рациональнее;
• длинный вход, много документов или кода, допустима небольшая потеря качества — Terra X‑High может сохранить преимущество по total cost;
• если важна latency, 31,1K против 14,4K generated-токенов — серьёзный аргумент в пользу Sol Medium, хотя реальное время нужно измерять отдельно.[^latency]

13. Terra Max против Sol Medium и Sol High: ещё один сигнал не «перекручивать» effort

Terra Max номинально опередила Sol Medium всего на 0,8 процентного пункта, причём доверительные интервалы перекрываются. При этом Terra использовала в 3,77 раза больше токенов и имела в 1,89 раза более дорогой output.[^genebench][^models]

Sol High номинально превзошла Terra Max, использовала в 2,78 раза меньше токенов и дала примерно на 28% более дешёвую выходную часть. При одинаковом входе Terra Max могла бы вернуть общую ценовую фору только при input свыше примерно 91,8K токенов. Последнее число — авторский расчёт по тарифам.[^models]

Практическое правило отсюда:

> Если вы дошли до Terra X‑High или Max, Sol Medium и Sol High должны войти в обязательный сравнительный набор.

Это не универсальный закон, а рациональная политика тестирования, поддержанная официальным советом сравнивать effort на репрезентативных workload и приведённым бенчмарком.[^guidance][^evals][^genebench]

14. Предельная отдача от Max снижается

По данным GeneBench‑Pro переход от xhigh к max дал:

• Luna: +5,7 п.п. при дополнительных 65,1K токенов;
• Terra: +4,5 п.п. при дополнительных 23,2K токенов;
• Sol: +1,9 п.п. при дополнительных 7,5K токенов.

Расчёт выполнен из Supplementary Table 1.[^genebench]

Прирост качества есть, но он оплачивается большим дополнительным trace. Особенно показателен Luna Max: она получила заметный прирост против Luna X‑High, однако для этого более чем удвоила среднее число токенов — с 53,1K до 118,2K.[^genebench]

Это не доказывает универсальный закон убывающей отдачи для всех задач. Но подтверждает, почему OpenAI не рекомендует max глобально и предлагает сравнивать его с xhigh именно на собственном workload.[^guidance]

15. Когда Luna X‑High или Max всё-таки имеет смысл

Luna с высоким effort может быть рациональна при сочетании нескольких условий:

1. Задача чёткая и повторяемая. Критерий правильности известен, output можно автоматически проверить, а неоднозначность ограничена. Это соответствует официальному позиционированию Luna.[^codex-models]
2. Основной failure mode — недостаточная проверка, а не недостаточная широта суждения. Это рабочая гипотеза, которую нужно подтвердить разбором ошибок.
3. Вход большой или хорошо кешируется. Более дешёвый input Luna способен компенсировать дополнительный output.[^models][^caching]
4. Повышение effort даёт измеримый прирост pass rate. OpenAI рекомендует повышать High/X‑High только при подтверждённом выигрыше и оставлять Max для hardest quality-first задач.[^guidance]
5. Переключение на другую модель ухудшает стабильность конкретного production-пайплайна. Это должно подтверждаться собственными evals, а не предполагаться.
6. Цена ошибки невысока или результат проходит автоматический валидатор. Тогда можно позволить более дешёвому уровню попытаться решить задачу с большим бюджетом.

Если эти условия не выполняются, Luna X‑High/Max часто превращается в попытку компенсировать модельный предел грубой силой.

16. Когда лучше сразу перейти на Terra

Terra — естественный базовый выбор, когда задача:

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

Это соответствует официальному описанию Terra как прагматичного all-rounder для everyday work с сильным reasoning и tool use.[^codex-models]

Практический baseline:

• Terra Medium — для обычной многошаговой работы;
• Terra High — для сложной отладки, планов миграции, ревью и задач с существенными trade-offs;
• Terra X‑High — только если Medium/High не проходят eval и сравнение с Sol Medium не даёт лучшего результата;
• Terra Max — quality-first исключение, а не штатный режим.[^guidance]

Последние четыре пункта — рекомендуемая политика автора, согласующаяся с официальным принципом «use the lowest effort that produces the result».[^codex-models]

17. Когда Sol Medium рациональнее «раскрученной» Terra

Sol Medium особенно уместна, когда проблема:

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

OpenAI позиционирует Sol именно для complex, open-ended и high-value work, а дефолтный режим Power в Codex использует gpt-5.6-sol с Medium reasoning.[^codex-models]

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

• Terra High;
• Terra X‑High;
• Sol Medium;
• иногда Sol High.

GeneBench‑Pro показывает, что Sol Medium способна превзойти Terra X‑High по качеству и token efficiency, но это только один домен. Решение должно приниматься по собственным задачам.[^genebench]

18. Sol High, X‑High и Max — не только для «нерешаемых» задач

Называть эти режимы исключительно инструментом для нерешаемых задач слишком узко. OpenAI описывает High/X‑High как настройки для трудных многошаговых workflow, глубокого планирования, сложной отладки, исследований и высокоценной работы. max предназначен для задач, где важнее качество, чем latency и token usage.[^reasoning][^guidance]

Рациональные случаи:

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

Но «дорогое решение» не означает «автоматически Max». Сначала нужно проверить Medium, затем High, затем X‑High. Max следует включать только после измеренного прироста.[^guidance]

19. Max и Ultra — принципиально разные режимы

Max увеличивает объём рассуждения одного выбранного агента над одной задачей. Ultra использует subagents для параллельной обработки отдельных частей сложной работы. В ChatGPT Work Ultra применяет maximum reasoning и может проактивно делегировать подходящие подзадачи; в API близкий механизм доступен как multi-agent beta.[^codex-models][^subagents][^guidance]

Ultra не следует воспринимать как «ещё один шаг после Max» на той же шкале. Это другая вычислительная форма:

• Max углубляет один поток;
• Ultra расширяет работу на несколько потоков;
• параллельность может уменьшить wall-clock time;
• суммарное потребление токенов обычно растёт, потому что каждый subagent выполняет собственную модельную и инструментальную работу.[^subagents]

Ultra лучше подходит для задач, которые чисто делятся на независимые направления: исследование нескольких источников, параллельное ревью безопасности/тестов/поддерживаемости, анализ разных модулей, построение нескольких альтернатив. OpenAI советует осторожнее относиться к параллельным write-heavy workflow: одновременные изменения кода могут создавать конфликты и coordination overhead.[^subagents]

20. Архитектура «Sol-советник + Terra-исполнители» — разумна

В локальном Codex можно определять custom agents с разными моделями, reasoning settings и инструкциями. Официальная документация прямо указывает, что Terra подходит для read-heavy scans, exploration, large-file review и обработки supporting documents, а более сильный gpt-5.6 — для неоднозначного многошагового планирования и финального follow-through.[^subagents]

Практическая схема может выглядеть так:

Координатор

Sol Medium или High

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

Рабочие агенты

Terra Medium

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

Terra High

• security review;
• проверка архитектурных рисков;
• анализ edge cases;
• критическая проверка плана.

Luna Medium или High

• extraction;
• классификация;
• нормализация;
• преобразование форматов;
• структурированные сводки.

Финальная проверка

Sol High

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

Это авторская архитектурная рекомендация, основанная на официальных описаниях ролей моделей и поддержке индивидуальных конфигураций subagents.[^subagents][^codex-models]

Она особенно полезна, когда дорогая модель нужна для постановки и синтеза, а основную массу чтения и механической работы можно отдать более дешёвым workers. Но экономия не гарантирована: subagents потребляют больше суммарных токенов, поэтому необходимы ограничения на число потоков, глубину вложенности и объём возвращаемых материалов.[^subagents]

21. Как выбирать модель по типу работы

Таблица — практическая рекомендация автора. Официальные основания: позиционирование моделей, guidance по effort и документация subagents.[^codex-models][^guidance][^subagents]

22. Диагностируйте тип ошибки до повышения effort

Повышать effort имеет смысл не при любой неудаче.

Ошибка типа A: модель не проверила очевидную вещь

Примеры:

• не прошла по всем условиям;
• не сопоставила два источника;
• не проверила тест;
• пропустила edge case;
• остановилась слишком рано.

Вероятный следующий эксперимент: поднять effort на один уровень, добавить чёткие success criteria или инструментальную проверку.

Ошибка типа B: модель выбрала неверную постановку

Примеры:

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

Вероятный следующий эксперимент: повысить уровень модели, улучшить контекст или декомпозировать задачу, а не сразу включать Max.

Это диагностическая эвристика автора. OpenAI рекомендует сначала разбирать реальные failure traces, делать точечное изменение и повторно запускать те же eval cases, не меняя одновременно модель, промпт и effort.[^prompt-guidance][^optimization]

23. Правильный эксперимент: не «какая модель умнее», а «какая конфигурация проходит мой SLA»

Для выбора конфигурации нужен небольшой, но репрезентативный eval-набор. OpenAI называет evals обязательным компонентом надёжных приложений и рекомендует тестовые данные, отражающие реальные production-входы.[^evals][^optimization]

Минимальный набор метрик:

• доля полностью успешных задач;
• доля результатов, принятых человеком без правок;
• серьёзность ошибок;
• число повторных запусков;
• input, cached input и output/reasoning tokens;
• число tool calls;
• p50 и p95 latency;
• стоимость одного запроса;
• стоимость принятого результата;
• время человеческой проверки.

Для каждой задачи стоит запускать одинаковый prompt и одинаковый контекст на нескольких конфигурациях. Не следует одновременно переписывать prompt, менять модель и повышать effort: иначе невозможно понять причину изменения результата. OpenAI прямо рекомендует при миграции сначала сохранить baseline, затем менять одну переменную и повторять eval.[^prompt-guidance]

Практический набор кандидатов

Для чётких массовых задач:

• Luna Medium;
• Luna High;
• Luna X‑High;
• Terra Low;
• Terra Medium.

Для обычной сложной работы:

• Terra Medium;
• Terra High;
• Terra X‑High;
• Sol Low;
• Sol Medium.

Для quality-first задач:

• Sol Medium;
• Sol High;
• Sol X‑High;
• Sol Max;
• при чистой декомпозиции — multi-agent/Ultra.

Побеждает не конфигурация с максимальным benchmark score, а самая дешёвая конфигурация, которая выполняет требования к качеству, latency и риску.

24. Маршрутизация лучше одной глобальной модели

Одну конфигурацию редко разумно использовать для всего продукта. Более эффективна маршрутизация:

Если задача чёткая, повторяемая и автоматически проверяемая:
    начать с Luna Medium

Если задача многошаговая, но знакомая и хорошо ограниченная:
    начать с Terra Medium

Если задача неоднозначная, высокоценная или требует самостоятельной стратегии:
    начать с Sol Medium

Если результат не проходит из-за недостаточной проверки:
    поднять effort на один уровень

Если результат не проходит из-за неверной постановки или слабого суждения:
    перейти на следующий уровень модели

Если задача делится на независимые ветви:
    использовать subagents; сильную модель оставить координатором

Это авторская routing policy. Она соответствует официальному совету выбирать модель под workload, использовать минимальный достаточный effort и применять multi-agent только там, где задача хорошо делится на независимые workstreams.[^guidance][^subagents]

Полезно также применять эскалацию по результату:

1. дешёвая конфигурация делает первый проход;
2. валидатор проверяет структуру, тесты или фактические ограничения;
3. только неуспешные или неоднозначные случаи уходят на более сильную модель;
4. финальная модель получает краткое описание failure, а не весь шум предыдущего trace.

Такой каскад часто рациональнее, чем запускать Sol High или Max на каждом запросе. Это инженерная рекомендация, которую следует подтвердить собственными evals.

25. Ответы на главные вопросы

Может ли Luna Max перекрыть Terra Medium?

Да, на отдельных задачах. GeneBench‑Pro показывает такой номинальный crossover: 16,5% против 13,6%. Но Luna Max использовала в 7,43 раза больше trace/response-токенов и имела почти втрое более дорогой output. Поэтому crossover по качеству не означает crossover по эффективности.[^genebench][^models]

Может ли Luna X‑High заменить Terra Medium?

Иногда возможно, но общего правила нет. В GeneBench‑Pro Luna X‑High была слабее и дороже по output. Эту пару нужно A/B-тестировать; предполагать эквивалентность нельзя.[^genebench]

Может ли Terra X‑High заменить Sol Medium?

Может на некоторых workload, особенно при длинном input и умеренной цене ошибки. Но GeneBench‑Pro показал более высокий результат и меньший token trace у Sol Medium. Это одна из обязательных пар для сравнения.[^genebench]

Почему тогда OpenAI разделила Luna, Terra и Sol?

Потому что модельный уровень и reasoning budget дают разные trade-offs. Luna оптимизирует массовую стоимость, Terra — баланс, Sol — максимальный capability headroom. Effort позволяет менять глубину работы внутри каждого уровня. Это следует из официального позиционирования и отдельных органов управления model/effort; точная внутренняя причина архитектурного решения публично не раскрыта.[^models][^guidance]

Есть ли смысл в Luna Max?

Есть, но это нишевая конфигурация. Она оправдана, когда задача остаётся узкой, input велик или кешируется, дополнительный effort измеримо повышает pass rate, а Terra не даёт лучшей экономики. Использовать Luna Max просто потому, что она дешевле за токен, — ошибка.

Terra X‑High или Sol Medium — кто главный «работник»?

Для многих сложных профессиональных workflow это действительно одна из самых полезных пар для сравнения. Но официальным дефолтом Codex Power является Sol Medium. Terra High/X‑High может выиграть на длинных входах и регулярной работе; Sol Medium — на неоднозначности, качестве и token efficiency. Решение определяется evals.[^codex-models]

Sol High/X‑High/Max нужны только для почти нерешаемых задач?

Нет. Они нужны для трудных и высокоценных задач, где прирост качества оправдывает latency и расход. Но Max не должен быть автоматическим выбором даже там: OpenAI рекомендует доказать его преимущество над X‑High на репрезентативных тестах.[^guidance]

Sol Ultra — это просто ещё больше reasoning?

Нет. Ultra — multi-agent режим: он использует максимальное reasoning и может проактивно распределять независимые части работы между subagents. Это может ускорить задачу по wall-clock, но обычно увеличивает суммарный token consumption.[^subagents]

Разумна ли схема Sol Ultra Advisor + Terra workers?

Да, особенно для read-heavy и параллельных ветвей. Codex поддерживает custom agents с индивидуальными model и reasoning settings, а OpenAI прямо рекомендует Terra для более лёгких parallel worker-задач. Но количество агентов и глубину делегирования нужно ограничивать.[^subagents]

26. Итоговая рабочая политика

1. Начинайте с типа задачи, а не с престижа модели.
2. Используйте минимальный effort, который проходит eval.
3. Luna X‑High/Max всегда сравнивайте с Terra Medium/High.
4. Terra X‑High/Max всегда сравнивайте с Sol Medium/High.
5. Считайте input, reasoning/output, кеш, инструменты, повторные запуски и проверку.
6. Оптимизируйте cost per accepted result, а не стоимость одного запроса.
7. Max используйте для hardest quality-first задач после измерения выигрыша.
8. Ultra используйте только при реальной декомпозиции на независимые ветви.
9. Сильную модель разумно оставлять координатором, а дешёвые модели — специализированными workers.
10. Не переносите результат одного бенчмарка на весь workload.

Пункты 1–10 — итоговые рекомендации автора, основанные на официальном model guidance, документации reasoning/subagents и анализе GeneBench‑Pro.[^guidance][^codex-models][^subagents][^genebench]

Финальный вывод

Вопрос «может ли более слабая модель на X‑High или Max перекрыть более сильную модель на Medium?» имеет простой ответ:

Да, иногда может. Но это не означает, что так дешевле, быстрее или надёжнее.

Высокий effort увеличивает вычислительный бюджет внутри выбранной модели. Он не гарантирует переход на следующий capability tier. На некоторых задачах Luna Max способна приблизиться к Terra High; на других Luna X‑High не достигает Terra Medium. Terra Max может приблизиться к Sol Medium, но использовать в несколько раз больше токенов. А Sol Medium иногда оказывается одновременно сильнее и token-efficient, чем Terra X‑High.

Поэтому правильный вопрос звучит не так:

> Какая модель формально слабее или сильнее?

А так:

> Какая комбинация модели, effort, контекста, инструментов и orchestration даёт минимальную стоимость принятого результата при моих требованиях к качеству и latency?

Именно на этом уровне Luna, Terra, Sol, Max и Ultra перестают быть маркетинговой лестницей и становятся нормальными инженерными инструментами.

Источники

[^models]: OpenAI, Models — GPT‑5.6 Sol, Terra and Luna. Цены, reasoning levels, context window и max output. Дата обращения: 10 июля 2026 года. Официальная документация.

[^codex-models]: OpenAI, Codex Models — Choosing Sol, Terra, and Luna; reasoning effort; Max and Ultra. Дата обращения: 10 июля 2026 года. Официальная документация.

[^guidance]: OpenAI, Model guidance for GPT‑5.6. Рекомендации по medium, high, xhigh, max, Pro и multi-agent. Дата обращения: 10 июля 2026 года. Официальная документация.

[^reasoning]: OpenAI, Reasoning models. Reasoning tokens, billing как output, reasoning mode и effort. Дата обращения: 10 июля 2026 года. Официальная документация.

[^pricing]: OpenAI, API Pricing. Тарификация токенов и встроенных инструментов. Дата обращения: 10 июля 2026 года. Официальная документация.

[^codex-pricing]: OpenAI, Codex Pricing. Токеновая rate card в кредитах для GPT‑5.6 Sol, Terra и Luna. Дата обращения: 10 июля 2026 года. Официальная документация.

[^chatgpt-rate]: OpenAI Help Center, ChatGPT Rate Card. Продуктовая тарификация и отличие message-based credit rates от API/Codex token billing. Дата обращения: 10 июля 2026 года. Официальная справка.

[^caching]: OpenAI, Prompt caching. 1,25× cache write и скидка на cache reads для GPT‑5.6. Дата обращения: 10 июля 2026 года. Официальная документация.

[^long-context]: OpenAI, GPT‑5.6 model pages. Повышенная тарификация при input свыше 272K токенов. Дата обращения: 10 июля 2026 года. Sol, Terra, Luna.

[^latency]: OpenAI, Production best practices — Improving latencies. Влияние модели и числа generated tokens на latency. Дата обращения: 10 июля 2026 года. Официальная документация.

[^genebench]: OpenAI, GeneBench‑Pro: Evaluating Multistage Statistical Reasoning in Genetics and Genomics. 129 задач, pass rates, доверительные интервалы и token traces по reasoning settings. Официальный PDF.

[^subagents]: OpenAI, Subagents — ChatGPT Work and Codex. Параллельные agents, расход токенов, heterogeneous model settings, Ultra и рекомендации для workers. Дата обращения: 10 июля 2026 года. Официальная документация.

[^evals]: OpenAI, Working with evals. Использование evals при выборе и обновлении моделей. Дата обращения: 10 июля 2026 года. Официальная документация.

[^optimization]: OpenAI, Model optimization. Репрезентативные production inputs, baseline и итеративное измерение. Дата обращения: 10 июля 2026 года. Официальная документация.

[^prompt-guidance]: OpenAI, Prompting guidance for GPT‑5.6 Sol. Сохранение baseline, изменение одной переменной и повторный eval. Дата обращения: 10 июля 2026 года. Официальная документация.

#GPT56 #OpenAI #Luna #Terra #Sol #Reasoning #ReasoningModels #Codex #MultiAgent #Subagents #AIEconomics #LLM #ИИ #МоделиИИ

Где это применимо

Model routing, evals, reasoning-token economics и multi-agent orchestration

Материал полезен командам, которые выбирают GPT-5.6 tier и reasoning effort для production workload, Codex или multi-agent workflow.

• Сравнивайте cost per accepted result, а не цену одного запроса.
• Повышайте effort, когда не хватает проверки; меняйте tier, когда не хватает judgment или capability.
• Проверяйте Luna X-High/Max против Terra Medium и Terra X-High/Max против Sol Medium на собственных evals.

Обсудить AI-автоматизацию