GPT-6.1 Terra или GPT-6 Luna: когда оправдан тариф в 10 раз выше

Сравнение Luna и новой Terra по цене, независимым тестам и реальным типам задач: от текстов до работы с кодом.

GPT-6.1 Terra стоит в 10 раз дороже GPT-6 Luna по обычным входным и выходным токенам Standard API. Но счёт за готовую работу не обязательно будет в 10 раз больше. Если одна модель чаще требует повторных запросов, исправлений и проверки человеком, первоначальная разница в тарифе может измениться.

Я бы не переводил все процессы на Terra только из-за её выхода.
Если задача повторяется и результат легко проверить, первым кандидатом остаётся Luna.
Если работа требует нескольких зависимых шагов и ошибку дорого исправлять, есть смысл проверить Terra на тех же исходных данных.

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

Во сколько обходятся Luna, Terra и Sol

26 октября 2026 года OpenAI представила GPT-6.1 Terra. По цене она заняла место между GPT-6 Luna и GPT-6.1 Sol. Само положение в этой линейке ещё ничего не говорит о выгоде для конкретной задачи.

По официальному прайс-листу OpenAI на 28 октября 2026 года тарифы Standard API для запросов без повышенной ставки длинного контекста следующие. API - программный интерфейс, через который приложение обращается к модели:

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

Получается, Terra в 10 раз дороже Luna по обычным входным и выходным токенам, но только в 5 раз - по кэшированным входным.
По обычному входу и выходу Terra вдвое дешевле Sol.

Это цены API, а не стоимость подписки ChatGPT. В анонсе Terra OpenAI указала доступность модели в ChatGPT Work и Codex для поддерживаемых платных планов, а для разработчиков - через API как gpt-6.1-terra. Появление модели в API не означает, что в обычном окне ChatGPT появилась отдельная кнопка выбора Terra. Разницу между ChatGPT, Work, Codex и API я разбирал отдельно.

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

Это сравнение относится к Standard API. В других режимах обработки запросов (Batch, Flex и Fast), при использовании платных инструментов и некоторых региональных настроек счёт может отличаться. Поэтому тарифы имеет смысл сравнивать при одинаковых условиях.

В терминальном тесте Terra заметно опередила Luna

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

Исследовательская площадка Vals AI опубликовала Terminal-Bench 4.0. Это задания повышенной сложности: агент работает в терминале, выполняет команды и должен получить проверяемый результат. В набор входят не только задачи разработки, но и научные, инфраструктурные и другие технические задачи.

В опубликованном сравнении с агентной оболочкой Mini-SWE-agent результаты выглядят так:

Исследователи использовали 66 заданий и усредняли результаты трёх прогонов. Проценты здесь показывают долю выполненных тестовых задач в этой методике. Это не вероятность того, что модель с первой попытки исправит произвольный баг в вашем проекте.

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

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

В аналитических задачах разница оказалась меньше

Компания Plotly проверила 3 модели на 43 вопросах к синтетическим производственным данным. Это отдельное исследование с другими заданиями, инструментами и настройками, поэтому сопоставлять его проценты с Terminal-Bench напрямую нельзя.

Luna правильно ответила на 38 из 43 вопросов,
Terra - на 40,
Sol - на все 43.
Полный набор вопросов обошёлся соответственно в $0.13, $1.31 и $2.61.

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

В этом испытании стоимость прогона Terra была примерно в 10 раз выше, чем Luna, а правильных ответов оказалось на два больше.

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

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

Для текстов: шаблонная обработка и работа редактора

Привести карточки товаров к одному формату, извлечь из документа нужные поля или переписать сообщение по шаблону - это одна группа задач. Здесь важнее соблюдение заданных правил, чем литературный стиль. Проверка понятна: структура соблюдена, значения не потеряны, лишних фактов нет. Часто её можно автоматизировать или выполнить выборочно.

Для такой операции я первым делом проверил бы Luna: при доступной проверке важно не переплачивать заранее. Это не утверждение, что Luna уже показала равное Terra качество на подобных текстах.

Но подготовить статью по нескольким источникам и сохранить в ней факты, логику, оговорки и авторский тон - совсем другая работа. Формально обе модели могут написать связный текст, но это ещё не означает, что редактор получит материал одинакового качества с одинаковым количеством правок.

OpenAI в анонсе GPT-6.1 Terra говорит об улучшении естественности письма. Однако основные сравнения в анонсе относятся к предыдущей Terra, а не к Luna. Подтверждённого сопоставимого независимого теста именно русскоязычных длинных редакторских текстов на Terra и Luna в изученных источниках я не нашёл.

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

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

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

Для разработки: маленькое изменение и сложная ошибка - разные работы

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

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

Помимо Terminal-Bench, есть небольшое исследование компании Bito от 28 октября. Bito провела сравнительные сессии по разработке и оценивала ответы с помощью другой модели и подготовленных критериев.
В их суммарной оценке:
Luna получила 56%,
Terra - 69%,
Sol - 74%.
Средняя стоимость сессии составила соответственно $0.04, $0.24 и $0.98.

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

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

Для своего проекта я бы проверял Luna и Terra на одинаковой задаче с одинаковой версией репозитория и одинаковыми разрешёнными инструментами. Смотрел бы на прошедшие тесты, корректность изменений, появившиеся регрессии и объём ручной проверки. Сама по себе удачная формулировка объяснения не означает, что исправление действительно работает. Для инженерных задач есть и матрица выбора модели и reasoning в Codex, которую я составлял для предыдущего поколения моделей.

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

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

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

У Terra и Luna по официальным спецификациям заявлен контекст до 1,05 млн токенов. Но одинаковый размер контекста не доказывает одинаковую способность понимать связи между модулями. И миллион токенов на входе не заменяет поиск по репозиторию, проверку версий файлов и тестирование.

В исследовании Bito на этапе прослеживания кода:
Terra набрала 89% баллов по их оценочной шкале,
Luna - 74%,
Sol - 90%.
Результаты получены на небольшой выборке с использованием модели-судьи. Это подсказка о возможностях, а не доказательство того, что Terra точнее разберёт любой репозиторий.

Вместо общего «разберись во всём проекте» я бы поставил проверяемую задачу. Например, в условном проекте попросил бы найти создание заказа, проследить его путь до записи в базу и показать файлы, где обрабатываются ошибки. Такой пример нужен для объяснения проверки, а не для изображения несуществующего личного теста.

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

И есть ещё экономический нюанс: при запросах длиннее 272 тысяч входных токенов меняется тарификация. Поэтому не стоит воспринимать большое контекстное окно как бесплатный способ передать модели весь проект.

Цена токенов и стоимость принятой задачи

У тарифа есть точная цифра. У готовой работы появляется ещё и цена переделок.

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

По тарифу Standard API такая операция обойдётся примерно в $0.0013 на Luna и $0.013 на Terra. Если выполнить тысячу операций точно такого же объёма, получится $1.30 против $13.00.

Это стоимость одинакового объёма токенов. Число успешно принятых результатов, дополнительные запросы и ручная правка в эти суммы не включены.

Для чтения кода можно взять другой условный пример: 100 000 обычных входных токенов и 3 000 выходных.
Тогда один запрос стоит
$0.0115 на Luna,
$0.115 на Terra,
$0.23 на Sol.
Если чтение сопровождается несколькими попытками, поиском файлов, проверкой ссылок или дополнительным выводом, фактическая сумма будет другой. Если срабатывает кэширование, она тоже изменится.

В статье от 24 сентября я уже рассказывал, что в отдельные дни видел в своей статистике около 200-300 млн токенов суммарного использования. Тогда же писал, почему оставил GPT-5 nano на отдельной функции: она справлялась с задачей. Это моё опубликованное наблюдение на тот момент, а не проверка Terra против Luna и не измерение экономии.

Для меня рабочая единица сравнения здесь другая:
Полная стоимость принятой работы = расходы на все вызовы модели и инструменты + затраты на проверки и исправления + значимые последствия ошибок.

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

Доплата за Terra может окупиться меньшим числом повторных попыток и ручных исправлений. А может просто увеличить расходы. Без замера на самой функции этого не определить.

Как я бы выбирал между Luna, Terra и Sol

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

1. Выбрать несколько типичных задач.
   Для текста - реальные исходные материалы и критерии точности. Для разработки - одинаковые задачи с тестами. Для изучения кода - одни версии файлов и проверяемые ссылки на функции и зависимости.

2. Задать одинаковую цель.
   Сравнивать Luna и Terra на одинаковых входных данных и с сопоставимыми доступными инструментами. Различия в настройках рассуждения и среде выполнения записывать, а не скрывать.

3. Посчитать принятые результаты.
   Учитывать не только первый ответ, но и повторные попытки, недостающие факты, ошибки в коде и время редактора или разработчика на проверку.

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

5. Менять модель только при доказанной пользе.
   Если Luna закрывает функцию стабильно, нет оснований автоматически переходить на Terra. Если Terra заметно улучшает результат в сложном процессе, доплата может быть разумной. Если сложности и цена ошибки ещё выше, стоит добавить к проверке Sol.

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

Появление Terra расширило выбор между Luna и Sol, но само по себе не требует менять работающие процессы.

Мой вывод: на понятной и дёшево проверяемой работе сначала стоит испытать Luna.
Там, где модель принимает больше решений, делает несколько зависимых шагов и ошибка обходится дорого, нужно сравнить Terra с Luna, а иногда и с Sol.

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