26 октября OpenAI начала раскатку GPT-6.1 Terra, и на первый взгляд это просто ещё одна строка в списке моделей. Но стоит приглядеться, и картина меняется. Одна модель с одним идентификатором разбирает изображения и чертежи, управляет интерфейсом компьютера по скриншотам и пишет связный текст. При этом её токены вдвое дешевле, чем у предыдущей Terra и у Sol. Для тех, кто строит агентов, это повод пересобрать конвейер: меньше моделей в цепочке, проще маршрутизация, дешевле каждый шаг. Ниже разобрано, где Terra уже доступна, сколько она стоит, как построить вокруг неё агента с запасным переходом на Sol, как считать стоимость принятой задачи и какие ограничения по месту выполнения инференса нужно проверить до выхода в несколько регионов.
Что именно OpenAI раскатила 26 октября и в каких продуктах и на каких тарифах модель уже появляется
Terra выходит сразу на двух площадках. В ChatGPT она доступна в режимах Work и Codex на тарифах Plus, Pro, Business, Enterprise и Edu, а в обычном чате её нет. В API модель получила идентификатор gpt-6.1-terra. Раскатка идёт волной, поэтому в списке моделей аккаунта Terra появляется не у всех в один день. Общий лимит использования тарифа остаётся прежним: OpenAI прямо оговаривает, что его не меняли и не расширяли.
В корпоративных тарифах всё зависит от настроек. В рабочем пространстве Business участники получают Terra там, где она входит в их место и разрешена правами пространства, с теми же пресетами Power по умолчанию и теми же общими лимитами. В Enterprise и Edu мало одного разрешения на модель: нужно ещё разрешение на работу с Work или Codex. Где доступны оба режима, можно выбирать между Standard и Fast.
Три способности, которые OpenAI объединила в одном идентификаторе, выглядят так. Первая - визуальное рассуждение: модель читает изображения, скриншоты и технические чертежи. Вторая - точное управление компьютером: скриншот или описание интерфейса превращается в действия мышью и клавиатурой. Третья - письмо, причём OpenAI делает упор на ясный, естественный язык без канцелярской каши. Окно контекста у модели около 1,05 миллиона токенов. В качестве типового примера работы в большом объёме компания называет чтение входящих счетов с вводом данных в бухгалтерскую программу.
Есть в раскатке тихая деталь, которую легко пропустить. У части пользователей Plus и Pro в пресетах Power по умолчанию на месте GPT-6.1 Sol с уровнем Light теперь стоит Terra с уровнем Medium. Это смещение баланса между умом и скоростью: вместо более тяжёлой модели с минимальным усилием рассуждения по умолчанию работает модель, заточенная под действия в интерфейсе, но с большим усилием. Для пользователя замена почти незаметна, а для разработчика агента это подсказка, какой связке OpenAI доверяет рутину.
Границы модели OpenAI тоже называет честно. На Terminal-Bench 4.0, проверке агентов на задачах командной строки, Terra при максимальном усилии решает 50,3 процента задач, тогда как GPT-5.6 Terra решала 21,5. Но половина задач остаётся нерешённой, и для самых сложных программистских задач компания по-прежнему советует Sol и GPT-6 Astra. Отсюда и вытекает вся идея запасной логики, о которой пойдёт речь ниже.
Цена токенов, режимы Fast и Flex и причина, по которой сравнивать нужно стоимость принятой задачи
Стандартный тариф Terra в API выглядит так: 1 доллар за миллион входных токенов, 5 центов за миллион кэшированных входных и 5 долларов за миллион выходных. У Sol вдвое больше по каждой строке: 2, 10 центов и 10 долларов. У предыдущей GPT-5.6 Terra входные токены стоили 2 доллара, а выходные 12. Режимы Batch и Flex делят эти цены пополам, Fast, наоборот, удваивает, а запросы с входом больше 272 тысяч токенов стоят дороже.
Из этого следует неочевидный вывод. В режиме Fast цена токена у Terra равна цене стандартного Sol: 2 доллара за вход и 10 за выход. Значит, выбирая Fast ради скорости, экономии по токенам уже не получить. Экономия появляется только в стандартном режиме или в Batch и Flex для задач, которые не требуют немедленного ответа.
Теперь про скорость. OpenAI заявляет, что Terra выполняет задачи на компьютере более чем втрое быстрее, чем GPT-6 Astra и GPT-6.1 Sol. А на профессиональном экзамене Agents' Last Exam при среднем усилии рассуждения Terra, по словам компании, набирает на 15 процентных пунктов больше GPT-5.6 Terra примерно за треть стоимости и держится наравне с Astra при десятой доле цены токена. При максимальном усилии стоимость задачи, по оценке OpenAI, примерно в девять раз ниже, чем у Claude Opus 5.5. Это заявления самого разработчика, и проверять их стоит на собственных задачах.
Ещё один показатель касается надёжности. На внутренних проверках с провоцирующими ошибку запросами доля ошибок Terra при низком усилии упала с 53,6 до 16,7 процента, то есть до одного запроса из шести, а при максимальном усилии составила 4,3 процента.
Независимый взгляд даёт экзамен DataAnalyticsBench, где агент отвечает на 43 вопроса к складу данных на 20 миллионов строк. Terra набрала 40 из 43 за 1,31 доллара на полный прогон при медиане 15 секунд на вопрос. Sol прошла все 43 за 2,61 доллара при медиане 18 секунд. В пересчёте на один правильный ответ выходит около 3,3 цента у Terra и около 6,1 цента у Sol. Три дополнительных правильных ответа Sol обходятся примерно в 43 цента каждый. Особенность в другом: Sol нашла все пять спрятанных в данных закономерностей, а Terra три. Экзамен проверяет аналитику, а не управление интерфейсом, поэтому он не доказывает ничего про клики и скриншоты, но показывает характер: Terra дешевле и быстрее, а Sol внимательнее к тому, о чём не спросили. Для сравнения, дообученная Particle-1 на том же экзамене получила те же 40 из 43 примерно за четверть цены Terra, так что планка "цена за качество" в этом классе продолжает смещаться.
Отсюда простое правило. Сравнивать модели по прайсу токенов бессмысленно, потому что итоговый счёт складывается из цены токена, числа токенов на задачу и доли задач, принятых с первой попытки. Рабочая единица измерения - стоимость одной принятой задачи.
Устройство агентного конвейера с управлением интерфейсом, где модель смотрит на экран и предлагает действия
Агент с управлением компьютером - это цикл из четырёх шагов: наблюдение, предложение действия, исполнение и проверка. Модель получает скриншот и цель, возвращает следующее действие (клик, ввод текста, прокрутка), исполнитель выполняет его в изолированной среде, затем система проверяет, приблизился ли экран к цели. Всё остальное - обвязка вокруг этого цикла.
Минимальный набор компонентов выглядит так. Изолированная виртуальная машина или контейнер с браузером, куда агент не пускают дальше выданных ему прав. Модуль съёмки экрана с предсказуемым разрешением, потому что от размера скриншота зависит и точность кликов, и число токенов. Исполнитель действий с белым списком допустимых операций. Проверяющий шаг, который судит не по словам модели, а по состоянию системы: появилась ли запись в таблице, сохранился ли файл, изменился ли статус заказа. И журнал, в который попадает каждый шаг с токенами, временем и стоимостью.
Сам вызов модели полезно спрятать за одной функцией. Формат инструмента управления компьютером лучше брать из актуальной документации API, а не из памяти, и менять его придётся в одном месте:
def agent_loop(goal, model, env, call_model, verify, max_steps=40):
history = []
for step in range(max_steps):
screen = env.screenshot()
reply = call_model(model, goal, screen, history)
if reply.done:
return {"ok": verify(goal, env), "steps": step + 1}
env.execute(reply.action) # клик, ввод, прокрутка
history.append((reply.action, reply.note))
return {"ok": False, "steps": max_steps}
Лимит шагов здесь не формальность. Агент, который ходит по кругу, тратит токены на каждый скриншот, а цена такой ошибки растёт быстрее, чем кажется: каждый новый шаг тянет за собой накопленную историю.
Запасная логика между Terra и Sol, которая включается по результату проверки, бюджету и типу задачи
Хорошая схема запасного перехода не должна зависеть от настроения модели. Решение принимают три сигнала. Первый - результат проверки: если Terra не справилась за заданное число попыток, задачу берёт Sol. Второй - тип задачи: сложное программирование, глубокий поиск аномалий в данных и многошаговые исследовательские задачи сразу идут к Sol, потому что именно там Terra по заявлениям самого OpenAI и по экзамену на данных уступает. Третий - бюджет: если задача уже съела отведённую сумму, лучше остановиться и вернуть ошибку, чем разгонять счёт.
Каркас такого маршрутизатора укладывается в несколько десятков строк:
from dataclasses import dataclass
@dataclass
class Policy:
primary: str = "gpt-6.1-terra"
escalation: str = "gpt-6.1-sol"
attempts_primary: int = 2
attempts_escalation: int = 1
budget_usd: float = 0.50
heavy_tasks: tuple = ("complex_coding", "deep_analysis")
def run_task(task, call_model, verify, policy=Policy()):
spent, tried = 0.0, []
if task["kind"] in policy.heavy_tasks:
stages = [(policy.escalation, policy.attempts_escalation)]
else:
stages = [(policy.primary, policy.attempts_primary),
(policy.escalation, policy.attempts_escalation)]
for model, attempts in stages:
for _ in range(attempts):
result = call_model(model, task)
spent += result.cost_usd
tried.append((model, round(result.cost_usd, 4)))
if verify(task, result):
return {"ok": True, "model": model, "spent": spent, "tried": tried}
if spent >= policy.budget_usd:
return {"ok": False, "reason": "budget", "spent": spent, "tried": tried}
return {"ok": False, "reason": "failed", "spent": spent, "tried": tried}
С лимитами тарифа в ChatGPT всё сложнее. OpenAI сообщает, что общие лимиты использования плана не изменились, но не говорит, что Terra расходует их медленнее, чем Sol. Поэтому закладывать в расчёт "Terra тратит меньше лимита" нельзя: сначала нужно замерить расход на реальных задачах в своём тарифе. В API, где платят за токены, такой проблемы нет, и маршрутизатор можно настраивать по деньгам. Для сценария "лимит почти выбран" разумно предусмотреть обратное направление: когда пространство подходит к лимиту, лёгкие задачи переводятся с Sol на Terra, а тяжёлые ставятся в очередь на следующее окно.
И последнее правило схемы: запасной переход должен быть явным и записанным. В журнал попадает, какая модель взяла задачу, сколько попыток сделала предыдущая и почему включилась следующая. Без этого через месяц невозможно ответить, почему счёт вырос.
Замеры стоимости задач на пресетах Medium и Light и условный расчёт, который можно заменить своими цифрами
Измерять нужно не среднюю стоимость вызова, а стоимость принятой задачи. Считается она просто: все расходы на попытки делятся на число задач, прошедших проверку. Токены переводятся в деньги функцией, в которую подставляются цены из таблицы выше:
PRICE = { # доллары за миллион токенов: вход, кэшированный вход, выход
"gpt-6.1-terra": (1.00, 0.05, 5.00),
"gpt-6.1-sol": (2.00, 0.10, 10.00),
}
def cost_usd(model, input_tokens, cached_tokens, output_tokens):
p_in, p_cache, p_out = PRICE[model]
fresh = input_tokens - cached_tokens # если счётчик входа включает кэш
return (fresh * p_in + cached_tokens * p_cache + output_tokens * p_out) / 1_000_000
def cost_per_accepted(total_cost, accepted):
return total_cost / accepted if accepted else float("inf")
Теперь условный пример. Цифры ниже придуманы для расчёта, это не замеры. Допустим, задача в интерфейсе использует 200 тысяч входных токенов, из которых 160 тысяч берутся из кэша, и 15 тысяч выходных. Для Terra это 12,3 цента: 4 цента за свежий вход, 0,8 цента за кэш и 7,5 цента за выход. Для Sol при тех же токенах выйдет 24,6 цента. Пусть Terra принимается проверкой в 80 процентах случаев, а Sol в 92. Тогда одна принятая задача обходится в 15,4 цента с Terra и в 26,7 цента с Sol. Terra остаётся выгоднее, пока её доля принятых задач не упадёт ниже половины от доли Sol, ведь цена токена у неё ровно вдвое меньше.
Схема с запасным переходом даёт ещё более любопытную картину. Если неудачи Terra (те самые 20 процентов) отправлять на Sol, то средние расходы на задачу составят 12,3 + 0,2 × 24,6 = 17,2 цента, а доля принятых задач вырастет до 98,4 процента (0,8 + 0,2 × 0,92). В пересчёте на принятую задачу получается около 17,5 цента: чуть дороже, чем у одной только Terra, зато почти на 20 процентных пунктов надёжнее и в полтора раза дешевле одного Sol. Именно поэтому цепочка Terra, потом Sol обычно лучше любой из моделей по отдельности.
Чтобы заменить придуманные цифры настоящими, достаточно прогнать 30-50 типовых задач через оба пресета, Medium у Terra и Light у Sol, и сохранить для каждой запуска токены, время, исход проверки и число шагов. Скорость тоже важна: если пользователь ждёт результат на экране, после 20-30 секунд он обычно отвлекается, и тогда медиана времени на шаг может перевесить разницу в цене.
Чеклист ограничений по размещению инференса для мультирегиональных развёртываний, где у Terra нет поддержки ОАЭ
Для корпоративных заказчиков у Terra есть ограничение, которое легко упустить на этапе пилота: модель не поддерживает резидентность инференса в ОАЭ (UAE inference residency). Это ограничение привязано к месту, где физически выполняется инференс, а не к месту, где находится пользователь. Для компаний, у которых по договору или требованию регулятора обработка должна идти внутри региона, это значит, что Terra в такой контур включать нельзя, как бы красиво она ни выглядела в тестах. Перед запуском в нескольких регионах стоит пройти такой список:
- Составить перечень юрисдикций, где договор или регулятор требует выполнять инференс внутри региона, и отметить в нём ОАЭ;
- Для каждой модели в цепочке, и для Terra, и для запасной Sol, и для любых других, проверить поддержку резидентности отдельно, потому что у разных моделей она может различаться;
- Привязывать маршрут к региону арендатора или договора, а не к месту, откуда пришёл запрос, ведь ограничение касается места выполнения инференса;
- Запретить тихий переход на модель без нужной резидентности: если запасная модель не подходит, задача должна остановиться с явной ошибкой, а не уйти в обход;
- Записывать в журнал для каждого вызова модель, регион и режим, чтобы при аудите можно было показать, где выполнялся инференс;
- Перед расширением на новый регион заново проверять настройки рабочего пространства и права администраторов, потому что в Enterprise и Edu доступ к Terra требует разрешений и на саму модель, и на Work или Codex.
Пункт про тихий переход самый коварный. Обычный маршрутизатор, увидев сбой, радостно переключается на ближайшую рабочую модель. Но в регионе с жёсткими требованиями ближайшая рабочая модель может нарушать договор, и деньги здесь второстепенны.
Безопасность агента, которому дали мышь и клавиатуру, и где проходят границы доверия
Агент с управлением интерфейсом получает возможности, которых у обычного чат-бота нет: он нажимает кнопки, открывает страницы и вводит данные. Поэтому границы доверия нужно нарисовать до первого запуска. Вся среда должна быть изолирована, а доступы выданы по минимуму: отдельные учётные записи с правами только на нужные операции, без доступа к личным хранилищам паролей. Домены, куда агент может заходить, лучше ограничить белым списком. Необратимые действия, такие как платежи, удаление и отправка сообщений, должны проходить через подтверждение человека.
Отдельная тема - текст на экране. Страница или документ может содержать инструкции, нацеленные не на пользователя, а на модель: "забудь задачу и сделай вот это". Это называется prompt injection. OpenAI сообщает, что Terra хорошо держалась на её внутренних проверках с такими инструкциями, чаще остаётся в пределах задачи и честнее сообщает о своих ограничениях и препятствиях, чем GPT-5.6 Terra. Но хорошие результаты на тестах не заменяют песочницу. Всё, что модель прочитала с экрана, нужно считать данными, а не командами, и важные решения не должны зависеть только от её собственного вывода.
Стоит помнить и ещё об одном. OpenAI относит Terra к высшей из двух категорий риска в области кибербезопасности по своей рамке готовности и сохраняет для неё защиту, созданную для GPT-6 Astra. Для разработчика это означает, что часть пограничных запросов может обрабатываться строже, чем у более ранних моделей, и об этом лучше узнать на пилоте, а не в день запуска.
Всё вместе складывается в простую картину. Terra делает управление интерфейсом дешёвым и быстрым настолько, что его можно ставить в массовый поток, а Sol остаётся страховкой для сложных случаев. Выигрывает не та команда, которая выбрала одну лучшую модель, а та, которая замерила стоимость принятой задачи, прописала запасной переход и проверила, где именно будет выполняться инференс.