GPT-5.6 Sol, Terra или Luna для API: цены и правило выбора

Короткий ответ: Luna стоит проверить первой на массовых простых задачах с жёсткой автоматической приёмкой; Terra — на смешанном производственном потоке; Sol — на сложном коде и рассуждениях, где сокращение числа ошибок способно окупить доплату. Именно так OpenAI позиционирует три уровня в официальном каталоге моделей, но это описание поставщика, а не доказательство качества на ваших данных.

Указывайте модель явно: gpt-5.6-luna, gpt-5.6-terra или gpt-5.6-sol. Алиас gpt-5.6 на 10 августа 2026 года направляет запросы в gpt-5.6-sol, согласно руководству OpenAI по GPT-5.6. Такое соответствие может измениться, поэтому алиас удобен для знакомства, но не для воспроизводимого сравнения и фиксированного бюджета.

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

До сравнения моделей зафиксируйте четыре условия, способные изменить вывод:

1. Что считается принятым результатом. Для кода это могут быть пройденные тесты и отсутствие опасных изменений; для извлечения данных — валидная схема и полнота обязательных полей; для ответа по документам — подтверждённые цитаты и отсутствие критических выдумок.
2. Какие расходы входят в расчёт. Учитывайте выходные токены, повторные запросы и время исправления, а не только вход.
3. Как используются кэш и длинный контекст. Cached input снижает цену повторно используемых входных токенов, cache write оплачивает запись префикса в кэш, а после 272 000 входных токенов повышенный тариф применяется ко всему запросу.
4. Какой нужен режим обработки. Standard, Batch, Flex и Fast меняют цену и условия выполнения, но не превращают одну модель в другую.

Если условие приёмки звучит лишь как «ответ выглядит лучше», сравнение нельзя воспроизвести, а стоимость принятого результата — надёжно посчитать.

С чего начать: Luna, Terra или Sol

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

Это стартовые гипотезы. Luna не обязана быть быстрее, Terra не является «лучшей по умолчанию», а Sol не гарантирует правильный ответ. Переходить на более дорогую модель стоит для конкретного класса задач, который не проходит заданный порог, а не для всего трафика сразу.

Что у моделей одинаково — и чего это не доказывает

Одинаковое контекстное окно означает только технический предел объёма, а не одинаковые качество, задержку или пропускную способность. В официальном сравнении моделей для всех трёх указаны контекст 1 050 000 токенов, максимум выхода 128 000 токенов и поддержка Responses API, Chat Completions и Batch.

Расширенные карточки Sol, Terra и Luna также указывают максимум входа 922 000 токенов, текстовые и графические входы, текстовый выход и дату отсечения знаний 16 февраля 2026 года. Дата отсечения знаний не является датой выпуска и не гарантирует актуальность ответа.

Сравнение относится к трём универсальным моделям GPT-5.6 в API. Оно не переносится на названия моделей в ChatGPT, стоимость подписки, а также специализированные модели для изображений, аудио, Realtime или embeddings.

Сколько стоят Sol, Terra и Luna

По официальным тарифам OpenAI API, проверенным 10 августа 2026 года, Standard-цены короткого контекста указаны в долларах США за 1 млн токенов в порядке input / cached input / cache write / output:

Cached input — повторно используемые входные токены, уже найденные в кэше. Cache write — запись стабильного префикса в кэш; она стоит в 1,25 раза дороже некэшированного входа. Нельзя считать весь вход кэшированным заранее: расходы зависят от реально записанных и повторно использованных токенов.

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

Batch, Flex и Fast меняют режим, а не модель

По тому же официальному прайсу тарифы Batch и Flex сейчас составляют половину Standard, а Fast — вдвое больше Standard. Для подходящих региональных эндпоинтов новых моделей может применяться надбавка 10%. Доступность, очередь, задержка и применимость регионального режима зависят от проекта, поэтому их нужно проверять отдельно.

Fast — актуальное публичное название ускоренного режима. В журнале изменений OpenAI указано, что оно заменило название Priority Processing; значение priority сохраняется для обратной совместимости в запросах и может встречаться в ответе. Это не делает Priority отдельной четвёртой моделью.

Сначала выберите модель по приемлемости результата, затем режим обработки по требованиям к задержке и сроку выполнения. Дешёвый Batch не решит недостаток качества, а Fast не превращает Luna в Sol.

Порог 272K: повышенная цена действует на весь запрос

Если вход превышает 272 000 токенов, включается long-context pricing: весь вход запроса тарифицируется вдвое дороже, а весь выход — в 1,5 раза дороже. Повышенная ставка не применяется только к «лишним» токенам сверх порога. Для записи кэша сохраняется соотношение 1,25 к стоимости обычного входа. Эти правила также приведены на странице цен OpenAI.

Предположим, один запрос содержит 300 000 обычных входных и 10 000 выходных токенов, без кэша и инструментов. Тогда расчёт выглядит так:

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

Два расчёта, которые быстро показывают масштаб

Для Standard-запросов с коротким контекстом базовая стоимость равна:

text
стоимость API =
  input_tokens / 1 000 000 × цена input
  + cached_input_tokens / 1 000 000 × цена cached input
  + cache_write_tokens / 1 000 000 × цена cache write
  + output_tokens / 1 000 000 × цена output

Рассмотрим массовую классификацию: 100 000 запросов по 2 000 входных и 100 выходных токенов, без кэша. Всего получается 200 млн входных и 10 млн выходных токенов.

• Luna: 200 × $0,20 + 10 × $1,20 = $52.
• Terra: 200 × $2 + 10 × $12 = $520.
• Sol: 200 × $5 + 10 × $30 = $1 300.

Разница десятикратная на каждой ступени, но пример ничего не говорит о равенстве качества. Если Luna чаще нарушает схему, а повтор или исправление обходится дорого, её итоговая экономия может исчезнуть.

Для рабочего сравнения используйте более полный знаменатель:

text
стоимость принятого результата =
  (все расходы API + расходы повторных запросов + стоимость ручного исправления)
  / число принятых результатов

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

Воспроизводимая проверка на собственных запросах

Выберите 30–100 характерных задач. Такой набор не обязан быть публичным бенчмарком: важнее, чтобы он отражал ваши реальные входы, инструменты, ограничения и цену ошибки.

1. До запуска запишите проверяемые условия приёмки: требуемые поля, тесты, критические ошибки, допустимую задержку и предел ручного исправления.
2. Прогоните один набор с одинаковыми инструкциями и инструментами на трёх явных ID. Не используйте для сравнения алиас gpt-5.6.
3. Для каждого запуска сохраните модель, режим обработки, входные, кэшированные, записанные в кэш и выходные токены, число повторов, задержку и время исправления.
4. Посчитайте долю принятых ответов и стоимость одного принятого результата.
5. Выберите самую дешёвую модель, прошедшую заранее заданные пороги. Повышайте уровень только для классов задач, где более дешёвый кандидат систематически не проходит проверку.

Итоговая таблица эксперимента может быть такой:

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

Минимальный прогон через Responses API

OpenAI рекомендует Responses API для сценариев с рассуждением, инструментами и несколькими ходами, но Chat Completions также поддерживается. В справочнике создания Responses запрос принимает явный model и режим service_tier.

Следующий пример запускает один и тот же вход на трёх ID и сохраняет ответ вместе с usage. Он не оценивает качество автоматически: проверку условий приёмки нужно добавить отдельно для вашей задачи.

js
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const models = ["gpt-5.6-luna", "gpt-5.6-terra", "gpt-5.6-sol"];
const serviceTier = "default";
const input = "Верни JSON с полями category и reason для этой заявки: ...";

for (const model of models) {
  const response = await client.responses.create({
    model,
    service_tier: serviceTier,
    input,
  });

  const record = {
    model,
    serviceTier: response.service_tier,
    output: response.output_text,
    usage: response.usage,
  };

  console.log(JSON.stringify(record));
}

Если вы проверяете Fast, передайте актуальное значение fast или обратно совместимое priority согласно справочнику и сохраните фактически возвращённый режим. Публичное название Fast и значение priority в поле ответа обозначают режим обработки, а не качество модели.

Решение перед внедрением

• Большой объём и строгая автоматическая проверка: сначала испытайте Luna. Оставайтесь на ней, только если повторы и ручное исправление не уничтожают разницу в цене.
• Смешанная очередь без одного доминирующего типа задач: начните с Terra и отдельно выделите типы задач, которые не проходят проверку.
• Сложное рассуждение, код или дорогое исправление: испытайте Sol и посчитайте, покрывает ли рост доли принятых результатов доплату.
• Вход длиннее 272K: пересчитайте весь запрос по повышенным ставкам до выбора модели.
• Требование минимальной задержки: сравните Fast отдельно от выбора модели и проверьте доступность для своего проекта.
• Региональная обработка: уточните применимость эндпоинта и возможную надбавку, не перенося условия одного проекта на другой.

Практический следующий шаг — взять 30–100 своих задач, закрепить условия приёмки и прогнать их через Responses API на трёх явных model ID. Перед внедрением ещё раз проверьте актуальные цены и текущее соответствие алиаса. Выбор завершён не тогда, когда найдена самая дешёвая строка прайса, а когда самая дешёвая из прошедших проверку моделей даёт приемлемую стоимость принятого результата.